Build vs Buy: When Custom Software Is the Wrong Answer

Build vs Buy: When Custom Software Is the Wrong Answer

There is an obvious conflict of interest in a software studio writing this. We will be direct about it: we make money building things, and we still turn down a meaningful share of what we are asked to quote. Building something a company did not need is a bad outcome for them and, eventually, for us — unhappy clients do not refer anyone.

So here is the reasoning we actually use.

Start by assuming you should buy

For most business problems, someone has already built a product, sold it to thousands of companies, and spent years fixing the edge cases you have not thought of yet. That product has support, a security team, a roadmap and documentation. You will never match that with a custom build, and you should not try.

The default should be: buy, unless there is a specific reason not to.

The most expensive projects we have seen were not the ones with big budgets. They were the ones that rebuilt something available off the shelf, badly, and then had to maintain it forever.

The 80% test

Take your requirements. Be honest about which are genuine requirements and which are preferences.

If an existing product covers roughly 80% of them, buy it and change your process for the other 20%. The cost of adapting how you work is almost always lower than the cost of building and then maintaining custom software indefinitely.

Two caveats worth being precise about:

• Which 20% matters more than how big it is. If the missing fifth is your actual competitive advantage, that changes the answer entirely.
• "We do it differently" is not automatically a requirement. Sometimes it is genuine differentiation. Often it is an accident of history that nobody has questioned in nine years.

When building is genuinely the right call

Custom software earns its cost when at least one of these is clearly true:

It is the thing you compete on. If the workflow *is* your business — the pricing engine, the matching algorithm, the thing customers actually pay for — you should own it. Buying it means renting your differentiation.

Nothing on the market fits the shape of the problem. Not "nothing is perfect" — nothing fits. Genuinely unusual workflows exist, particularly in regulated and industrial settings.

Integration is the whole problem. Sometimes the answer is not a system at all, but a layer connecting the five you already have. No vendor sells that, because it is specific to you.

The licensing maths has turned. Per-seat pricing that was fine at 20 people can be indefensible at 400. At that point a build can pay for itself — though be careful: you are comparing the licence against build *plus maintenance*, not build alone.

You need to own the data and the rules. Regulatory, contractual or strategic reasons why this cannot live in someone else's system.

The cost people forget

Build cost is the part everyone estimates and the smaller part of the total.

What follows it: hosting, monitoring, dependency updates, security patches, browser and OS changes, the person who understands it leaving, and every future change costing money that a SaaS subscription would have absorbed for you.

A reasonable planning assumption is 15–20% of the original build cost per year to keep custom software healthy. Software that is not maintained does not stay still; it decays.

The middle options people skip

Build-versus-buy is usually presented as binary. It is not.

• Buy and integrate. Use products for what they are good at, and build only the connective tissue.
• Buy and extend. Many platforms have APIs and extension points. Building a module inside something is far cheaper than replacing it.
• Build thin, buy thick. Custom interface over bought infrastructure — your workflow, someone else's plumbing, auth, and compliance.
• Buy now, build later. Buy to learn what you actually need. In two years you will specify a far better system than you could today, if you still need one.

That last one is underrated. A lot of custom software is built to a specification written by people who did not yet understand the problem.

Questions worth answering before you commit

• If we buy the closest product, what specifically breaks?
• Is that gap our differentiator, or a habit?
• Who maintains this in three years, and is that budgeted?
• What does this cost over five years, including maintenance, against the licence?
• Could we integrate rather than replace?
• What happens if the person who builds this leaves?

If a vendor cannot engage with these, that tells you something useful about the vendor.

### FAQ

Q: Do you really turn down work? A: Yes. The most common reason is that an off-the-shelf product covers the need and the client had not looked properly. That conversation takes twenty minutes and saves them a great deal of money.

Q: What if we are somewhere in the middle? A: Then integration is usually the answer. Most companies do not need another system; they need the ones they already have to work together.

Q: How do we know a vendor is being honest about this? A: Ask what the off-the-shelf alternative would be and why it does not fit. Anyone who cannot name the alternative has not considered it.

If you have worked through this and concluded you do genuinely need to build, what we build and how an engagement runs is set out in full, including when not to hire us. What things cost is published up front. And if you are still unsure, describe the problem rather than the solution — talking you out of a build is a legitimate outcome.