Build vs. Buy

Sooner or later, every growing business reaches this fork. It needs a system to do something, such as manage stock, handle bookings or run a customer portal, and it has to decide whether to buy something off the shelf or build something bespoke. It feels like a technical decision. It isn’t, really. It’s a business decision that happens to involve technology, and it’s made under pressure far more often than with a clear head.

Most businesses get it wrong at least once. Not through carelessness, but because the pull in each direction is strong, and the wrong choice often looks entirely reasonable at the time.

Why “buy” feels safe, and sometimes isn’t

Buying is the default instinct, and for good reason. It’s fast, it’s proven, and someone else has done the hard work of building and maintaining it. For a huge range of needs, such as accounting, email and project management, buying is simply right. There’s no advantage in building your own version of something that already exists and works well.

But buying quietly stops being the safe option in a few situations:

• The tool almost fits, but not quite. You end up working around its limits rather than with them: extra manual steps, workarounds, spreadsheets bolted on to cover the gaps.
• What you need is core to how you compete. If the process is what genuinely sets the business apart, a generic tool built for everyone will treat it as generic too.
• The pricing doesn’t match how you’ll use it. Per-seat or per-transaction pricing that looks fine today can become a serious cost at scale.
• You’re stitching several bought tools together to make one coherent process. At that point you’re already building, just informally and without the benefits of doing it properly.

Why “build” feels ambitious, and can be a trap

Building feels like the in-control choice: no compromises, exactly what you need, nothing you don’t. For capability that genuinely differentiates the business, that instinct is often right. But the costs are easy to underestimate, particularly without an established technical team:

• It’s never just the build. Every custom system needs maintenance, security updates and someone who understands it well enough to change it. Over time, the initial build is often the smallest part of the cost.
• You inherit all the dull problems too. Login, permissions, backups and uptime have usually been solved thoroughly by a mature product. Build your own and you solve them yourself, even though they add nothing unique.
• Key-person risk arrives on day one. If one developer or one agency built it, they’re often the only ones who really understand it.
• Scope grows. “We just need a simple booking system” becomes a much larger project once every edge case and integration surfaces mid-build.

The question that actually matters

Build versus buy is usually framed as a cost comparison: which is cheaper up front? I think that’s the wrong place to start. The better question is whether this capability differentiates the business or supports it.

If it differentiates, if it’s what customers notice and where the real edge lies, it’s usually worth building and owning properly. If it supports, necessary but not what sets you apart, buying is almost always the better use of time and money, even with some compromise.

Most businesses get this backwards at least once: building something generic that should have been bought, or buying something core that they should have owned. Both mistakes are expensive, just in different ways and on different timelines.

The middle ground that gets overlooked

The choice isn’t always binary. Some of the best outcomes I’ve seen come from a hybrid: buy the well-solved, generic parts of a problem, then build or configure the parts that really matter, and connect them properly. That’s often cheaper and faster than a full custom build, while avoiding the workaround-on-workaround trap of forcing a generic tool to do something it wasn’t designed for.

Getting it right means looking at the decision from above: what is genuinely core, what does each path cost over several years rather than at launch, and how does each option affect your ability to change course later? That’s a different exercise from comparing two vendor quotes or two developer estimates, and it’s exactly where an architectural view earns its place.

Getting it right more often

Nobody gets every build-or-buy call right. The balance shifts with team size, budget and what’s strategic at a given stage. But businesses that treat it as a deliberate decision, and revisit it as circumstances change, make far fewer expensive mistakes than those that default to whichever option feels quickest in the moment.