The question is not build or buy — it is fit
Most software decisions are framed as a budget question: a subscription looks cheaper than a development project, so the subscription wins. In practice the real cost of off-the-shelf software is rarely the licence fee. It is the workarounds — spreadsheets that sit beside the system, manual re-keying between tools, and processes bent to suit a product that was designed for someone else's business.
The more useful question is how closely your operating model matches the product's assumptions. Where the match is close, buy. Where your workflow is a genuine point of difference, or your data lives across systems the product cannot see, the economics shift quickly toward building something purpose-designed.
When off-the-shelf is the right answer
Commodity capabilities should almost always be bought, not built. We steer clients toward existing products when:
- The process is standard across your industry (accounting, payroll, email, document storage).
- Your differentiation is elsewhere and the tool only needs to be adequate.
- You have fewer than a handful of integrations and the product's API covers them.
- The vendor's roadmap aligns with where your business is heading.
When custom software pays for itself
Purpose-built software earns its keep when the workflow is the product — when how you operate is why customers choose you. Typical signals:
- Staff maintain parallel spreadsheets or 'shadow systems' because the tool cannot model your process.
- You are paying per-seat for a large product while using a small fraction of it.
- Data needed for decisions is split across three or more systems with no single view.
- You want to offer the capability to your own customers as a product — a SaaS of your own.
- Compliance or data-residency requirements rule out the available vendors.
What a well-run custom build looks like
A custom build does not have to mean a large, risky programme. The projects that succeed share a shape: a short discovery to define the operational problem in plain language, a written scope with options and trade-offs, working software demonstrated every week, and a clear plan for who operates it afterwards.
Modern platforms — multi-tenant architectures, managed cloud databases, subscription billing, AI-assisted features — mean a focused team can deliver a production SaaS in months rather than years. The discipline is in deciding what not to build.
Questions to ask before you commit either way
- What does the workaround cost us today in hours per week?
- Which of our processes would we refuse to change to fit a product?
- Who owns the data, and can we take it with us?
- If we build, who runs it in year two — and is that in the estimate?
- Could this capability become revenue if we productised it?