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
- The code, infrastructure and data are yours from day one
- 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 we have shipped
Each one is a full case study with the architecture decisions and what changed for the business.
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 · no lock-in
One site, one team, one workflow first. We watch it run, fix what the real world surfaces, and only then widen it. Repository, infrastructure and documentation are yours throughout — most clients keep us on to extend the system, but that is a choice rather than a dependency.
How we price systems
Priced by delivery week and agreed before any code is written. These are the bands real projects land in, not marketing numbers.
Websites are priced publicly. Systems are quoted per project.
Every operations system has a different shape, and publishing one number helps nobody — it frightens off the small build and puts a ceiling on the large one. So we do not publish one. Start with a thirty-minute call and we will tell you what scale of project this is, whether it is worth doing at all, and what the next step costs. You get a fixed price in writing before any code is written, and it does not move unless the scope does.
Marketing sites, e-commerce storefronts and other website work are a different thing, and those we do price publicly — by delivery week, with the bands on the page and a calculator you can run yourself.
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.
Yours, completely
The repository, the cloud accounts, the database and the data are in your name from the first commit. There is no licence fee, no per-seat platform tax, and no scenario in which leaving us means losing the system.
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. Thirty minutes on a call and we will tell you honestly whether custom software is the answer, what scale of project it would be, and what the next step costs. No obligation and no proposal deck.