The spreadsheet stopped being true
It is accurate first thing in the morning and wrong by ten. Everyone knows it is wrong, so everyone keeps a private copy, and now there are six versions of the truth.
CUSTOM SOFTWARE · AUCKLAND, NZ
Turn operational messinto a system that runs.
Warehouse and operations platforms, customer portals, B2B ordering, and the internal tools between them. Senior engineers do the work; scope, price, and risk are written down before anyone writes code.
- Go, React and PostgreSQL — no low-code lock-in
- Customer accounts, data, ownership and handover defined in writing
- Bilingual is part of the architecture, not a translation layer
- Prove one site first, then expand with confidence
MegaFoodOne live, trustworthy inventory record across more than 1,400 pallet positions.
Live in productionThe point where a business outgrows its spreadsheets
Every operations system we have built started the same way. The business was running fine, and then it wasn't — not because anything broke, but because the number of things people had to hold in their heads passed what a spreadsheet and a group chat can carry.
Every customer question interrupts someone
Your customers have no way to look anything up, so they ring. Each call pulls a person off the job they were doing. The information exists — it just lives somewhere only staff can reach.
Month-end is reconstructed from memory
Invoices get pieced together from paperwork, notes and what people remember. Some charges are missed entirely, and the ones that do go out get queried.
Nobody can show what happened
The numbers changed, and there is no record of who changed them, when, or why. When a customer disagrees, you have nothing to put in front of them.
What we build
Four shapes cover most of the work. They are rarely separate projects — one system usually contains two or three of them.
Operations platforms
Warehouse management, inventory, dispatch, job tracking. The system that knows where things are, who owns them, and what happened to them — built around the thing your business actually moves and bills for.
Customer portals
Give your customers a login and the phone stops ringing. They see their own data and only their own data — stock, orders, jobs, invoices — with permissions scoped so tightly that showing the wrong customer the wrong record is structurally impossible.
B2B ordering and trade platforms
Wholesale catalogues with thousands of SKUs, bulk and repeat ordering, account pricing, credit terms. The workflows standard e-commerce does not handle, on infrastructure that does.
Internal tools and integrations
The admin screens, approval flows and reports that sit between your people and the system — plus the connections to Xero, your ERP, your payment provider, and whatever else already runs the business.
Systems delivered by our team
Operational systems, public-service platforms and trade ordering tools our team has led and delivered, with client names withheld where appropriate.
How an engagement runs
Software projects fail in the gap between what was asked for and what was needed. We close that gap before the build, and we do not ask you to commit to anything until the number is on paper.
- 01
A thirty-minute call
Free · no commitment
You describe how the business runs today — usually a spreadsheet, a group chat and someone’s memory. We tell you what scale of project this is, and whether custom software is even the right answer. Sometimes it is not, and we will say so.
- 02
Scope and a fixed price
Free for most projects
We write down what the system does, what it does not do, and what it costs. For a platform large enough that we need time on your floor to understand the workflow properly, we agree that scoping work separately before it starts — and it comes off the build price if you go ahead.
- 03
First release
Twelve weeks typically
We build the narrowest version that is genuinely useful and put it in front of real users. Not a prototype and not a demo — the thing your team starts working in, with the data that matters already in it.
- 04
Proving ground and handover
Ongoing · documented handover
One site, one team, one workflow first. We watch it run, fix what the real world surfaces, and only then widen it. Customer data and the agreed custom deliverables are documented for handover under the project agreement — most clients keep us on to extend the system, but that is a choice rather than a dependency.
How we price systems
Narrow-scope MVPs start at NZ$20,000+GST. Operational platforms commonly require NZ$30,000–60,000+GST, with discovery confirming the reliable range before build work begins.
Custom software has a public investment threshold. Each system is scoped and quoted around the real workflow.
Every operations system is different, so an instant price would be misleading. Tell us how your business works today and what you want to improve. We will review your answers and reply by email within two business days. If a short call would help, we will suggest a time. You will receive a fixed price in writing before development starts, and it only changes if the agreed work changes.
Fixed-scope website and e-commerce packages have public starting prices. Tailored website and commerce work uses the custom-build estimator; software starts with a project brief because users, workflows, integrations and migration must be scoped first.
See website pricingHow it is built, and why that matters to you
Three decisions we make on every system, and the reasoning behind each.
Boring technology, deliberately
Go, React, PostgreSQL, AWS. None of it is fashionable and all of it will still be maintainable in five years. We do not build on low-code platforms that only we can extend, and we do not pick a framework because it was interesting this quarter.
Bilingual as architecture, not translation
Every screen works in English and Chinese because the system was designed that way, not because a translation layer was bolted on afterwards. For a floor team and a customer base that work in both, this is the difference between software people use and software people avoid.
Clear ownership, in writing
Your business data and customer accounts remain under your control. Rights to custom project deliverables, repository access, infrastructure and handover are defined in the project agreement; YuNet pre-existing tools and third-party licences retain their existing terms.
Why a small studio rather than a larger firm
Because the senior engineer who designs your system is the one who builds it. There is no account layer, no handoff to a junior team, and no context lost between the person who understood your business and the person writing the code. The tradeoff is honest: we take on a small number of system builds at a time, and if we are full we will say so rather than queue you behind work we cannot start.
Questions businesses ask before committing
The things that come up in almost every first conversation, answered properly.
Tell us what your business runs on now.
Usually it is a spreadsheet, a group chat and someone’s memory. Tell us how the work happens today, who is involved and what causes the most trouble. We will review it and tell you honestly whether custom software is the answer and what to do next.