The Question Every SMB Gets Wrong at Least Once

At some point, every growing SMB hits this fork in the road: you need a system to do something — manage inventory, handle bookings, run a customer portal — and you have 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 be about technology, and it’s one that gets made under pressure more often than it gets made with a clear head.

Most businesses get it wrong at least once — not because they’re careless, but because the pull in each direction is genuinely strong, and the wrong choice often looks completely reasonable at the time.

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

Buying an existing tool is the default instinct, and for good reason. It’s fast, it’s proven, and someone else has already done the hard work of building and maintaining it. For a huge number of business needs — accounting, email, project management — buying is simply the right answer. There’s no commercial upside to building your own version of something that already exists and works well.

But “buy” quietly stops being the safe option in a few specific situations:

• When the tool almost fits, but not quite. 
  • You end up working around its limitations rather than through them — extra manual steps, workarounds, spreadsheets bolted on to cover the gap.
• When the thing you need is actually core to your competitive advantage. 
  • If the process you’re trying to support is genuinely what differentiates your business, a generic tool built for everyone will, by definition, treat it as generic too.
• When the pricing model doesn’t match how you’ll actually use it. 
  • Per-seat or per-transaction pricing that looked fine at your current size can become a serious cost at scale, for a tool that isn’t actually built around your specific volume or workflow.
• When you’re stitching together several “buy” tools to replicate one coherent process. 
  • At that point, you may already be doing informal, unplanned building — just without the benefits of doing it properly.

Why “build” feels ambitious, and sometimes is a trap

Building feels like the grown-up, in-control choice — no compromises, exactly what you need, nothing you don’t. For genuinely core, differentiating capability, that instinct is often right. But building carries costs that are easy to underestimate, especially for a business without an existing technical team:

• It’s never just the build. 
  • Every custom system needs ongoing maintenance, security updates, and someone who understands it well enough to change it later. The build cost is often the smallest part of the total cost over time.
• You inherit all the boring problems too. 
  • Login, permissions, backups, uptime — a mature off-the-shelf tool has usually solved these thoroughly. Building bespoke means solving them yourself, even though they add no unique value to your business.
• Key-person risk is built in from day one. 
  • If one developer (or one agency) built it, that’s often also the only person who deeply understands it — a single point of failure baked into your foundation.
• The scope tends to grow. 
  • “We just need a simple booking system” quietly becomes a much larger project once every edge case and integration need surfaces mid-build.

The question that actually matters

The build-vs-buy decision usually gets framed as a cost comparison — which is cheaper, up front. That’s the wrong starting point. The better question is: 

Is this capability something that differentiates the business, or something that supports it?

If it’s genuinely differentiating — the thing customers notice, the process that’s actually your edge — it’s usually worth the investment to build and own it properly. If it’s supporting infrastructure — necessary, but not what sets you apart — buying is almost always the better use of time and money, even if it means accepting some compromise.

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

A middle ground that’s often overlooked

The choice isn’t always binary. Some of the best outcomes come from a hybrid: buying the well-solved, generic parts of a problem, and building — or configuring — the specific parts that actually matter to your business, connected together properly. This is often cheaper and faster than a full custom build, while avoiding the workaround-on-workaround problem of forcing a generic tool to do something it wasn’t designed for.

Getting this right requires looking at the decision from above — understanding what’s actually core to the business, what the total cost of each path looks like over several years rather than at launch, and how each option affects 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 outside architectural view earns its keep.

Getting it right more consistently

Founders rarely get every build-vs-buy call correct — the calculus genuinely does shift with team size, budget, and what’s actually strategic at a given stage. But businesses that treat it as a deliberate decision, revisited as circumstances change, make far fewer expensive mistakes than those that default to whichever option feels fastest in the moment.

---

Ashdown Systems helps UK startups and SMBs make build-vs-buy decisions with a clear view of the real, long-term cost — not just the price tag on day one. If any of this sounds familiar, get in touch.