Journal · Product · 7 min · 16 April 2026
When to Build Custom Software vs Use Off-the-Shelf Tools
Every growing business hits the moment SaaS stops fitting. Here is the framework we use with clients to decide whether to configure, extend or build.
There is a predictable moment in a growing company's life when its tooling breaks. Airtable can't hold the workflow, HubSpot cannot model the pipeline, the spreadsheet is now the business. The instinct is to build. Sometimes that is right. Often it is not. Here is how we help clients decide.
The three-question test
- Is this workflow a genuine source of competitive advantage, or is it plumbing?
- Have you configured your existing tools to their real limits — not just the defaults?
- Can you name three specific hours per week this software would save, and who they belong to?
If the answers are 'plumbing', 'no', and 'not really', do not build. Configure what you have or hire a systems specialist. Custom software is expensive to build and more expensive to own.
When custom is the right call
- The workflow IS the product (e.g. your operations team is your moat).
- You have hit hard limits in every reputable SaaS in the category.
- The integration between existing tools is more complex than the tool itself.
- Compliance, data residency or IP means SaaS is not viable.
The staircase we recommend
Move up one step at a time, only when the current step visibly breaks:
- 1. Best-in-class SaaS, well configured.
- 2. SaaS + low-code glue (Zapier, Make, n8n).
- 3. Internal tool on Retool / Airtable Interfaces / equivalent.
- 4. Custom web app on top of a proven stack.
- 5. Full bespoke platform, owned end-to-end.
Budget realities
A serious custom internal tool starts around £15–£30k and needs ongoing engineering to stay alive. A SaaS platform in the same space is typically £2–£10k per year all-in. The build-vs-buy maths only tips in favour of building once the SaaS bill, workarounds and lost productivity together exceed the true cost of ownership of software you write yourself.
How we approach the discovery
Before we quote a build, we run a discovery sprint: shadow the team, map the current workflow, identify what genuinely differentiates the business, and pressure-test whether existing tools have really been pushed to their limits. Often the outcome is a configured SaaS stack and a light custom layer — not a full build.
The takeaway
Custom software is a strategic choice, not a status symbol. Build when the workflow is the moat and the maths works, configure when it does not, and be honest about the total cost of ownership either way. Our Custom Software engagements always start with a discovery sprint so you know what you are committing to before a line of code is written.