Every growing business reaches the point where its software doesn’t quite fit. A vendor says their product does everything you need. A developer says they could build exactly what you want. Both might be right. The mistake is deciding on gut feel, or on the upfront price alone.

Here is how we help owners make the call.

Start by assuming you’ll buy

Off-the-shelf software should be the default. Someone else pays for the development, the security patches, the hosting and the new features, and spreads that cost across all of their customers. For accounting, payroll, email and most of the back office, buying is almost always right. Your accounting process isn’t what makes you different, and you want it to work the way your accountant expects.

Buying is the right answer when:

  • The process is standard across your industry, and doing it the usual way loses you nothing.
  • A mature product covers most of what you need, and the gaps are workarounds you can live with.
  • The vendor handles New Zealand properly, including GST, local payroll rules and support in your time zone.
  • You’d happily change how you work to fit the product.

The trap is judging products by their demo. A demo follows the vendor’s script, not your process. Test a shortlist against how your business actually runs, including the awkward exceptions your team handles without thinking.

When building makes sense

Custom software earns its place in a few specific situations.

The process is your edge. If the way you quote, schedule, price or serve customers is genuinely why people choose you, forcing it into generic software can flatten what makes you good.

You’re gluing too many systems together. When four products are held together by spreadsheets and re-keying, a small custom layer that connects them and fills the gap can cost less than another subscription and the staff time spent bridging it.

Per-seat pricing stops making sense. Paying a monthly fee per user for a large field team that only needs one screen adds up quickly. A simple purpose-built app can be cheaper over a few years.

The rules are local or unusual. Global products often treat New Zealand requirements, or the specific rules of your industry, as an afterthought. If your compliance work lives in spreadsheets because no product handles it, that’s a signal.

No product holds your data the way you think about it. Sometimes the core idea in your business, such as a job, a site, a contract or an asset, simply doesn’t exist in any off-the-shelf system.

The costs people forget

The build cost is the visible part. Owning software costs more than writing it:

  • Hosting, plus test environments so changes can be tried safely.
  • Security updates. Frameworks and libraries need regular patching. An app nobody has touched for two years becomes a liability.
  • Support. Someone has to fix it when it breaks at 7am on a Monday.
  • Change. Your business will change, and the software will need to change with it.
  • Key-person risk. If one developer is the only person who understands it, you have a problem waiting to happen.

Budget for ongoing care every year, not just the build. Then compare honestly with the bought option over the same period, including the cost of its workarounds: double entry, errors, and the hours your team spends fighting the tool.

The middle path is often the right one

The choice is rarely all or nothing. For most businesses we work with, the best answer is to buy the commodity systems, connect them properly, and build only the thin layer that’s genuinely yours.

That might mean keeping Xero, your payroll system and your CRM, integrating them so data flows between them, and building a quoting tool, a customer portal or an operations dashboard on top. The custom part stays small, which keeps it cheaper to own and easier to change. Getting the connections right matters as much as the custom code: decide which system owns each piece of data, make every sync safe to repeat, and log what happens so failures don’t go unnoticed.

If you build, make sure you own it

Custom software you don’t control is a risk, not an asset. Whoever builds it, insist on these from day one:

  • Your tenant. It runs in your own Microsoft and Azure account, on your billing, not the developer’s.
  • Your repository. The source code lives in your own GitHub or Azure DevOps organisation, and the contract says the intellectual property is yours.
  • Documentation. How it’s built, how it’s deployed and how to restore it from backup, written so another developer could pick it up.
  • Automated tests and deployment, so changes can be made safely without heroics.
  • Proper security. Staff sign in with their existing Microsoft 365 accounts, secrets are kept in a vault rather than in the code, and access is based on roles.

That’s how we deliver our own work. If a supplier can’t agree to these points, treat it as a warning sign.

A decision checklist

Before you commit either way, work through these steps:

  1. Write down the process the software must support, including the exceptions.
  2. Shortlist two or three products and test each against that process, not the demo script.
  3. List the gaps and decide which are workarounds you can live with and which are deal-breakers.
  4. Price both options over five years: subscriptions and workarounds on one side, build, hosting, support and updates on the other.
  5. Ask whether the process is really your edge, or just how you’ve always done it.
  6. Decide who will own, support and update custom software, and what happens if that person leaves.
  7. Consider the middle path: buy the core systems, connect them, and build only the thin layer that’s unique.
  8. If you build, put ownership in the contract: your tenant, your repository, your documentation.

Most of the time the answer is to buy. When it isn’t, building something small, well and in your own name is usually better than building something big.

This is general information, not legal advice.

Where to start

If you’re weighing up a new system, start with step one and write the process down before you look at any software. If you’d like help testing products against it, or scoping something custom, see our product engineering work, or our fractional CTO service for an independent view. Get in touch and we’ll talk it through.