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
Custom software for Auckland businesses.
Customer portals, warehouse systems and the integrations between them. We start with the workflow you need to improve, compare it with your existing tools, and agree the scope before quoting a build.
- 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.
BEFORE YOU CHOOSE A BUILD
Buy a product, connect your tools, or build a system?
Start with the part of the business that needs to work differently. Custom development is one option; the right choice depends on how closely existing products fit, which records need to move between systems, and who will maintain the result.
Use an existing product
If a maintained product covers the workflow, check its setup, staff training, permissions and data export first. Compare its ongoing licence and support costs with the changes you would need. A process that already works does not need replacing simply because a custom build is possible.
Connect the tools you have
If the tools work but people keep re-entering the same information, an integration may be enough. Identify which system owns each record, what moves in each direction and how failures or duplicate requests are handled. Supported interfaces and access must be checked before promising a connection.
Build the missing workflow
Consider custom software when the gap is in the way people, stock, orders or approvals need to work together. Define the roles, customer boundaries and exceptions, then choose the smallest useful release. Include hosting, maintenance, migration and handover in the decision.
MegaFood is a concrete example of combining these approaches: a warehouse system and customer portal were built around its operations, while storage invoices connect to Xero and payment status syncs back. It first went live at one cold store. The case shows what was delivered; it does not establish the cost or results of your project.
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.
Start with the workflow you want to improve.
These four things help us compare options and define a quote. You do not need all the answers before making contact; a short description is enough to begin.
One job, from start to finish
Describe who starts it, what they need, where it gets stuck and what happens when the normal path does not work. An anonymised example is more useful than a long feature list.
People and record boundaries
List staff, customers and sites. Explain who may see or change each type of record, who approves an exception and what needs an audit trail.
Systems and information to keep
Name the current tools and the records that must be retained or migrated. For each connection, describe which information should move, in which direction and which system remains authoritative.
The first usable release
Choose the first team, site or workflow, and explain what must keep working during the change. Agree how that release will be accepted, who will support it and what later work can wait.
Before development, the written scope should identify deliverables, exclusions, assumptions, migration, integrations, acceptance checks and the support or hosting costs that sit outside the build price. Any separate scoping work is agreed before it starts.
- 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 send a first reply by email within 1 business day. If a short call would help, we will suggest a time. After agreeing the scope, you will receive a fixed price in writing before development starts; 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. For software, start with a short enquiry or the optional detailed project brief; users, workflows, integrations and migration determine the scope.
Plan a custom software budgetSee 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.
Tell us how work happens today, who is involved and what causes the most trouble. A few sentences are enough. We will send a first reply within 1 business day to discuss whether custom software is a fit and what to do next. A written quote follows once scope is agreed.