Custom software for growing businesses: when to build, buy or stabilise

The decision is commercial before it is technical

Build, buy and stabilise are not engineering choices. They are three different bets on where your business is going, and they are usually made by people looking at a feature comparison rather than a P&L.

There is a simple way to cut through it: separate the workflow from the tool. Ask whether the workflow is common to every business in your category, specific to how you compete, or already built and simply not performing. Those three answers map cleanly onto buy, build and stabilise.

When a custom build earns its cost

A custom build is justified when the workflow is the competitive position. That usually looks like one of these:

• A core workflow that customers choose you for
• Supply and demand logic that no off-the-shelf product models correctly
• A proprietary internal tool that has become load-bearing
• An AI product trained on data only you hold

What gets underestimated is not the build. It is the ownership. Custom software has to be maintained, secured, tested and updated for as long as it runs, and that is a multi-year commitment that reliably exceeds the original estimate. Price a build as an ongoing obligation, not a one-off project.

The same discipline applies to AI agents. They suit repeatable, well-bounded work, support triage, lead prospecting, onboarding, where a human handoff is clearly defined. They are not staff replacements, and treating them as such is how agent projects end up cancelled. Australia's national guidance on responsible AI adoption is a sensible starting point for anyone scoping this.

When buying off the shelf is the smarter call

Accounting, email, payroll, CRM, scheduling, reporting, these are solved. Building them is spending your scarcest capital on a workflow that gives you no advantage.

The trap on this side is a cheap subscription that does not quite fit. Teams reshape their processes around a rigid tool because the licence was affordable, and the cost of that distortion never appears on an invoice. Buy the common layers. Build only where you are genuinely different.

The third option nobody scopes: stabilise

There is a pattern we see constantly. Six figures already spent with developers. Unclear ownership of the code. Systems that do not talk to each other. Performance that varies for reasons nobody can explain. And now an AI bill climbing every month.

The instinct is to rebuild. Usually that is wrong, and always it is premature. Diagnose first: architecture, infrastructure, integrations, performance, security, and the commercial goal the product is supposed to serve. Only then decide what gets rebuilt. Our ScaleReady approach exists for exactly this, moving a fragile product to something fundable without throwing away the parts that work.

Choosing without guessing

If you are earlier than this, an idea rather than a product, the build decision is not yet the one that matters. Shaping the problem and the commercial model is. That is what our Accelerate Program is for.

Common questions

How do we know whether to rebuild or stabilise?

Diagnosis tells you. Architecture, cost and ownership problems are usually fixable in place. A data model that cannot represent your business, or a platform choice that caps your ceiling, may not be. The distinction is knowable before you commit.

Is custom always more expensive?

More expensive upfront, always. Over a longer horizon it depends entirely on whether the thing you built gives you an advantage. If it does not, you have bought a maintenance obligation.

Where are AI agents actually safe to deploy?

On repeatable workflows, with reliable data and a human in the loop. Not on unmonitored legal or financial decisions.