Build vs buy: a decision framework for custom software

Most build-versus-buy debates go wrong in the first five minutes, because they start with a product demo or a developer's enthusiasm. The shape of the problem comes later, if at all. The question that matters is whether this capability makes you different, and what owning it will cost you over five years.

We advise on this decision often. We also build software for a living, so take our bias into account. That bias is tempered by experience, though. Some of the least useful projects we've ever been asked to quote for were re-implementations of things a £30-a-seat SaaS product does perfectly well.

When buying is the right answer

Off-the-shelf software wins when the capability is a commodity. Every business in your sector needs it, does it in broadly the same way, and being 10% better at it wins nobody a customer. Payroll, accounting, email, video calls, generic CRM, document signing, helpdesk ticketing. Nobody chooses a supplier because its expenses tool is unusual.

The signals that point to buying:

• Your process is standard, or could reasonably become standard. If you cannot say why your way of doing it is materially better than the industry norm, adopt the norm.
• You would rather someone else worried about compliance updates, security patches and integrations. The vendor's roadmap is doing work for you.
• The user population is small or the workflow is infrequent; custom software amortises badly over a dozen occasional users.
• Time matters more than fit. A 70% fit available next week often beats a 95% fit available in nine months.

One caution. "We'll configure it" hides a lot of cost. A serious ERP or CRM implementation can run to six to eighteen months of consultancy, and what comes out the other end is often a heavily customised system that is neither standard nor yours. If you are planning more than a few weeks of configuration, you are already building. You are just doing it inside someone else's product with a worse toolchain.

When building is the right answer

Custom software earns its keep when the capability is the business, or close to it. The signals:

• The workflow is what sets you apart: your dispatch logic, pricing engine, underwriting rules or clinical pathway is why customers choose you, and you want to keep improving it faster than a vendor's release cycle allows.
• The off-the-shelf product forces you into a shape that costs money. Picture a distributor whose SaaS order system cannot model its consignment terms, so staff re-key 400 orders a week into spreadsheets to get round it. That is a design mismatch, and a workaround on that scale can cost more per year than the custom replacement would.
• Integration is the hard part. When the value lies in tying five existing systems together with your own rules, a bought product rarely fits, because the vendor has never seen your systems.
• You have to own the data and be able to take it with you. Regulated sectors, and businesses that expect to be acquired, often need to hold their data and logic in a form they fully control.
• The licensing arithmetic breaks. Per-seat pricing across 800 warehouse staff, or per-transaction pricing at volume, can exceed the cost of building and running a purpose-built system inside two years.

Building does not mean building everything, which brings us to the pattern that settles most of these arguments.

The usual answer is a mix of both

Nearly every system we build sits on a foundation of purchased components. Authentication (Auth0, Clerk, Entra), payments (Stripe, GoCardless), email delivery, document storage, maps, observability, hosting. Nobody sensible writes their own card-processing stack in 2025.

The work is in deciding where the boundary goes. Some capabilities are fine being ordinary, and there a vendor's scale gives you security and reliability you could not match on your own. Then there is the 20% of the system that encodes how your business operates. Build that part and integrate the rest. Keep the integration layer thin and well tested, so a vendor can be swapped without a rewrite.

A useful test for any component is to ask how bad the next twelve months would be if this vendor tripled its prices tomorrow, or was acquired and shut down. If the answer is "annoying, but a fortnight's work", buy. If the answer is "existential", build it, or at the very least own the data model and keep an exit path.

Total cost of ownership over five years

Compare like with like. The build side usually gets costed properly, because a quote is a quote. The buy side gets costed at the sticker price. Put both on the same five-year footing.

As a worked example, take a field-services business with 220 users comparing a vertical SaaS product at £48 per user per month against a custom scheduling and job-management application. The SaaS route comes to roughly £127k a year in licences, rising to about £160k by year five, plus £40k of implementation and an estimated £35k a year in workaround labour. Call it £900k over five years. The custom route is £280k to build over seven months and £45k a year to run and evolve. Roughly £460k over five years, for a system that matches their process and that they own outright. The figures are illustrative, but the shape of the comparison is typical.

That arithmetic does not always favour building. Halve the user count, put the differentiation at zero, and the same comparison flips. The point is to run it with realistic numbers before deciding.

Questions to ask before you decide

1. If we bought, which parts of our process would we have to change to fit the product, and what does each change cost us in labour, errors or lost customers?
2. If we built, what is the smallest version that replaces the painful part, and could it be live inside four months?
3. Who owns this system in three years, and do they have the appetite for a vendor relationship, or for a codebase?
4. What data will live in it, and how do we get it out?
5. What happens at three times current volume?
6. Which parts are commodity and which are ours? Draw the line on a whiteboard.

Common mistakes

Building for pride. A capable internal team wants to write the thing. Wanting to is not a business case, however good the team is.

Buying for speed, then customising for years. The 70% fit becomes a permanent programme of consultancy invoices. Notice when configuration has turned into development.

Forgetting the running costs of custom. Software is never finished. Budget for someone to own it and keep patching and improving it, or it decays into the next legacy system.

Treating it as binary. Almost every good answer is a hybrid. The decision worth spending time on is which parts you own.

Deciding without a prototype. For anything above roughly £100k of spend either way, a short discovery phase that produces a clickable prototype and an integration map is cheap insurance against picking the wrong side.

Where to start

Write down the three workflows that make your business better than its competitors, then list every system that currently touches them. Anything on that list which is not one of the three, you can probably buy. The systems behind those three are the ones worth owning. If you would like a second opinion on where the line falls, or a costed comparison for a specific system, our discovery process is built for that, and custom software development is what happens on the far side of it when building turns out to be the right call.