“Build or buy” is one of the most expensive decisions a growing company makes — and it’s usually made on instinct, in a hurry, under pressure from a problem that’s already hurting.
Get it right and you spend the appropriate amount on a system that fits. Get it wrong in either direction and you pay for years: a custom build you didn’t need, or an off-the-shelf tool you have to fight every day.
The good news is it’s not a coin flip. There’s a way to reason about it.
The question behind the question
“Should we build or buy?” is usually standing in for a better question: how specific is this part of our business?
Off-the-shelf software is built for the average of its market. That’s a strength when your need is genuinely common — payroll, accounting, email. It’s a weakness when the thing you’re trying to support is exactly what makes you different from your competitors.
So before you compare price tags, get honest about what you’re actually deciding on.
When to buy
Buy when:
- The need is common and well-solved. Mature products exist and most companies use them the same way. (You don’t build your own email.)
- Your process isn’t a competitive advantage. If doing it the standard way costs you nothing, the standard tool is fine.
- The fit is close enough that you won’t be working around it daily. A few compromises are normal; a tool you fight constantly is not.
If those hold, buy it and move on. Building what you could have bought is one of the most common ways companies burn time and money.
When to build
Build when:
- The thing you’re supporting is core to how you compete — the workflow your customers actually feel, the operation that makes you good at what you do.
- Nothing off the shelf fits without forcing you to change how you work. When every product makes you bend your business to its assumptions, you pay twice: for the tool and for the workarounds.
- You’ve outgrown the packaged options and the “next tier up” just resets the clock (more on that in We’ve Outgrown Our Software).
A custom build isn’t about wanting something bespoke. It’s about removing the gap between how your business works and how your software works — so the software stops being friction and starts being leverage.
The option everyone forgets: don’t replace it at all
The build-vs-buy framing hides a third answer that’s often the right one: leave it alone, and connect it.
Maybe the tools you have are fine individually and the real problem is that they don’t talk to each other. Then the answer isn’t build or buy — it’s integrating what you’ve got so the data flows instead of being retyped. Cheaper than both, and often the actual fix.
The honest version of this decision always has three doors, not two: build, buy, or leave alone.
How to actually decide
A rough test you can run on any system:
- Is this common, or specific to us? Common → lean buy. Specific and core → lean build.
- Does a close-enough product exist? Yes → buy. No, everything forces a change → build.
- Is the real problem the tool, or the gaps between tools? Gaps → integrate, don’t replace.
- What does staying put actually cost? Put a number on the workarounds, the re-entry, the delays. That’s the budget you’re really comparing against.
Most bad build-vs-buy calls come from skipping step 4 — comparing a build’s price to a subscription’s price, instead of to the ongoing cost of the status quo.
Get an outside read before you commit
The expensive part isn’t building or buying. It’s deciding wrong and finding out eighteen months later.
That’s what our Systems Audit is for: a fixed-price, fixed-scope look at your operation that gives you a straight build, buy, or leave-alone recommendation for each piece — grounded in how you actually work and what the status quo is really costing you, not in what anyone’s trying to sell you.
If you’re staring down a build-vs-buy decision and want a clear-eyed second opinion, tell us what you’re weighing. You’ll hear back within 24 hours, often from James, our founder, directly.