Build vs buy: when custom software makes sense.

It sounds simple: buy if something off-the-shelf does the job, build if nothing fits. In practice both carry costs that never appear in the quote, and both bills grow. Most businesses get it wrong at least once: a maintenance burden outlasting the problem, or an operation bent to someone else's assumptions.

The appeal of bespoke

Custom software has real appeal: exactly what you need, no compromises forced by someone else's product decisions. It pulls strongest when off-the-shelf has burned you. Three project management tools tried, none fitting. A CRM doing 80% of what you need, where the missing 20% creates daily friction.

What each one actually costs

Build, and it is yours for as long as you run it. Maintenance is constant, so you keep a developer on retainer or scramble when something breaks. Knowledge sits with whoever built it in ways documentation rarely captures, leaving you dependent on their goodwill and slow to replace. Every hour maintaining it is an hour not spent elsewhere, which matters most to a small team: the system that saved you time becomes the thing consuming it. Every change your business needs costs time, money and someone who understands it well enough to make it safely. The burden scales with scope: a focused tool needs little attention, a central system needs sustained investment.

Buy, and the vendor handles updates, security patches, compatibility, documentation and support, which is worth real money. But buying does not hold still either. Tools are priced per seat, so the bill multiplies twice over, by headcount and by tools: ten people across six subscriptions is sixty payments a month, none individually worth an argument. Then they have to talk to each other, and every integration is glue somebody owns that breaks whenever either end changes a field. Around that sits what nobody counts. Data spread across systems never meant to be read together, so asking what a customer costs to win and keep needs three exports. Prices rising on somebody else's schedule. An account to provision, revoke and renew for every person on every tool.

Neither curve is flat. The honest question is which rises faster for your business.

What AI changed, and what it did not

Writing a feature is quicker and cheaper than it was, and that moves the line towards building.

It moves one line only. Writing software got cheaper; owning it did not. Security patches, dependency upgrades and hosting are unchanged, and the knowledge still has to live somewhere, so ownership is a larger share of the total now, not a smaller one. The new way to get this wrong is building more than you can maintain: four small systems now take roughly what one used to, and keeping four running is exactly as hard as it always was.

When buying wins

Most of the time buying is right: the conditions justifying a build are rarer than people assume. Project management, invoicing, CRM and email marketing are solved ground, and the gap between good and perfect rarely justifies building. Friction often comes from preserving a process that doesn't need preserving, and adapting to well-designed software is usually easier than bending it around your habits, especially when the tool embodies practices worth adopting. You can start today, where custom takes months, and with no developers in-house the maintenance stays somebody else's.

When building wins

The genuine cases are narrower. If your process is your advantage, a generic tool erodes what makes you effective: a logistics firm with proprietary routing, a manufacturer with distinctive quality control. If the alternatives are bloated and your team spends longer navigating features they don't need than working, a focused tool is simpler and cheaper. Sometimes nothing adequate exists, in niche industries or where several domains meet and no product covers the territory. Sometimes integration is the core problem: middleware helps, but complex cases need bespoke work for your logic.

Consolidation is the case most often missed: four tools, four bills and three integrations replaced by one system doing the whole job. It holds only if the four genuinely overlap rather than each doing something you need. And sometimes you outgrow what you bought: what suited a team of five may not suit fifty.

Questions to ask before you commit

Ask what happens if the person who built it leaves, and whether documentation or outside support covers it. Ask the ongoing cost of either route across a year, not just the upfront one; a supplier who can't answer has answered you. Ask whether you have genuinely tried the alternatives, because glancing at a few isn't due diligence. Ask whether the frustration fits the spend, since a £50,000 build to recover two hours of admin a week is poor value. And ask what your exit is, from a build nobody can maintain or a vendor whose price you don't control.

The decision is about trade-offs

Custom gives you control and focus, and demands investment proportionate to what you create. Buying gives you convenience and shared maintenance costs, and asks you to compromise on how things work and to keep paying while you do. The worst outcomes come from building without evaluating the alternatives, or buying after underestimating what you need. Neither option wins by default, and what matters is deciding deliberately, with a clear view of which cost you are taking on.

So do the arithmetic before the meeting. Price the buy side properly: per seat, across every tool the job touches, for three years, with the integrations included. Price the build side the same way, with a year of maintenance in it. Most people have never put those two numbers side by side, and the comparison settles more cases than any argument about principle.

We build custom software, so it is worth being specific about where we think it wins: when the process is genuinely your advantage, when consolidation retires more tools than the build adds, and when somebody will own the result. Where those are not true we say so, because a system you cannot maintain is worse than the subscriptions it replaced.