What I've learned from 20+ digital builds in NZ: the common mistakes
Three mistakes show up in almost every struggling digital project: tools bought before questions asked, automation bolted onto messy processes, and launch treated as the finish line.
After 20-plus digital builds across New Zealand, from ecommerce stores to non-profit operations systems to multi-sided platforms, the same three mistakes explain most of the wreckage: tools bought before questions asked, automation bolted onto messy processes, and launch treated as the finish line. None of them are technical. That's the point.
Mistake one: buying the tool before asking the question
This is the one nobody writes about, and it's the most expensive habit in NZ small business.
It goes like this. Something feels broken, like sales, admin, or follow-up. A tool gets bought, because buying is decisive, and decisive feels like progress. The subscription is the gym membership of business software: the purchase delivers the feeling of improvement, so the actual improvement gets quietly deferred. Six months later the tool is half-configured, the team works around it, and the original problem is intact, now with a monthly fee attached.
I've walked into businesses running eight subscriptions that between them almost did the job of three, and nobody could tell me which question any of them was bought to answer. That's not a software problem. That's a sequencing problem.
The fix costs nothing: write the question down first. "Which channel is our ad money wasted on?" "Why do enquiries go quiet after the first reply?" Then, and only then, choose the smallest thing that answers it. Sometimes that's a tool. Surprisingly often it's a spreadsheet and a decision.
Mistake two: automating the mess
Once a tool is in hand, the next instinct is to point it at the most chaotic part of the business. It's exactly backwards.
Automation is an amplifier. Wire it to a clean process and it compounds the good. Wire it to a mess, like enquiries scattered across three inboxes or a quoting process that lives in someone's head, and it amplifies the mess, at speed, with a straight face. The failures get more sophisticated and harder to spot, which is worse than the manual version, because at least the manual version knew when it was confused.
Every build I've seen genuinely pay for itself did the unglamorous thing first: fixed the process, then automated it. Every expensive disappointment skipped that step. After twenty-odd builds I treat it as close to a law.
/ From the workshop · Outdoors retail · Queenstown
Small Planet: Online revenue from $30k to $300k+ inside 12 months.
Read the case study →
Mistake three: treating launch as the finish line
Most project budgets are shaped like a wedding: everything spent on the day, nothing for the marriage. The site goes live, the invoices are paid, everyone moves on, and the software starts decaying immediately. Not dramatically. Quietly. The market shifts, the workflow drifts, a dependency changes, and eighteen months later the "new system" is the legacy system and nobody can say when it happened.
Static software decays from day one. The builds that compound are the ones where someone keeps looking at them with intent, against a number that matters.
What the opposite looks like
The clearest counter-example I can offer is the KPI hub I built for the Himalayan Trust. It pulls the whole funding picture into one place: ActiveCampaign for the CRM, Xero for accounting, Raisely for donations, Stripe for payments, and Ezidebit, the legacy direct debit platform, all woven into a single dashboard showing the North Star metrics and progress against goals.
Here's the part that matters: my colleague and I review it monthly, and every single month we find something to improve about the dashboard itself. It has never once been finished, and that's not a flaw. That's the design.
This is what I've started calling software sovereignty. When you own the tool, like your own software and your own databases running on top of existing APIs, nothing stops you generating a better iteration every time you use it. The tool fits the business exactly, square peg, square hole, and it keeps fitting as the business changes. I think that's where SaaS is heading for small and medium businesses: away from renting one-size-fits-nobody products, toward owning small systems that learn the shape of your operation. The build costs that used to make this fantasy are gone.
/ From the workshop · MTB retail + hire · Queenstown
Bikeaholic: Revenue up 132% in two years on essentially flat ad spend.
Read the case study →
The takeaway
Twenty-plus builds reduce to one sentence: the question comes before the tool, the process comes before the automation, and the launch is the start of the work, not the end of it. Get the sequence right and the technology is the easy part. It always was.
Frequently asked questions
- What's the most common mistake NZ businesses make with digital projects?
- Buying the tool before defining the question. A subscription gets signed because the purchase feels like progress, then the business bends itself around what the tool happens to do. The fix is boring and cheap: write down the specific question or outcome first, then choose the smallest thing that answers it.
- What is software sovereignty?
- Owning your own software and your own data, built on top of existing APIs and services, instead of renting a one-size-fits-all product. Once you own the tool, nothing stops you improving it every time you use it. For small businesses this used to be unaffordable. With AI-era build costs it increasingly isn't, and it means tools that fit the business exactly: square peg, square hole.
- How do I stop a digital build decaying after launch?
- Give it a rhythm and an owner. A monthly review against a North Star metric, a small standing budget for iteration, and one person accountable for the numbers. Software decays when nobody is looking at it with intent. The maintenance isn't a cost overrun, it's the part of the build that compounds.
- Is custom software realistic for a small NZ business now?
- Increasingly, yes. An AI-era build process puts a working product in the $10,000 to $30,000 NZD range, and buying the commodity parts off the shelf keeps it there. The decision is no longer custom versus affordable. It's whether the workflow you'd be encoding is worth owning, and for the processes at the core of your business, it usually is.
- How does Garage 30 apply these lessons?
- Every engagement starts with the questions, not the tools: a scoped discovery that maps the business, a North Star metric, and a definition of done. Builds are scoped small, processes get fixed before they get automated, and every system ships with a plan for how it keeps improving after launch. Book a 30-minute call at cal.com/casey-hemingway/30min if that sounds like the build you've been trying to have.