Custom software is sometimes exactly right and sometimes an expensive mistake. Here's how to decide honestly — including when the answer is to build nothing, and why the best answer is usually a bit of both.
- Before build or buy, ask whether the problem is worth solving at all — "do nothing" is a legitimate, underrated answer.
- Buy the common and undifferentiated; build only where your process is a genuine edge or nothing on the market fits.
- The strongest answer is usually hybrid — buy the commodity, build the thin layer that's truly yours — and both traps are about underestimating cost.
I build custom software for a living, so you should read what follows with a healthy suspicion, because I have an obvious incentive to tell you that you need some. I try hard not to give in to it, and not out of virtue. The fastest way to lose a client's trust — and the years of work that trust would have led to — is to sell them a build they didn't need and watch it disappoint them. A satisfied client who bought the right off-the-shelf tool on my advice comes back for the thing they genuinely can't buy. A client I talked into a needless build does not come back at all.
So this is a piece about how to make this decision honestly, written by someone whose bias runs the other way. The build-versus-buy call gets made badly all the time, and in both directions at once: companies build things they should have bought, sinking months into recreating a problem the market solved a decade ago — and companies twist themselves into knots around an ill-fitting tool when a modest custom piece would have paid for itself in a quarter. Here's the framework I actually use, traps included.
Before anything else: is this worth solving?
There's a question that comes before build or buy, and most people skip straight past it: is this problem actually worth solving right now, by any means at all? Sometimes the honest answer is no. The pain is real but minor, the workaround is annoying but tolerable, and the effort to fix it — however you fix it — is better spent on something that matters more.
"Do nothing" is a legitimate and badly underrated option. Every system you add is a system you then have to run, pay for, secure, and maintain, forever, whether or not it's earning its keep. If a problem isn't costing you enough to justify that permanent tax, the mature move is to leave it alone and revisit it when — or if — it grows. A consultant worth hiring will tell you this even though there's plainly no project in it for them, and how they handle exactly this moment tells you most of what you need to know about whether to trust the rest of their advice.
Assuming the problem clears that bar and is genuinely worth solving, the real fork appears: build or buy.
When to buy
Reach for buying when the problem is common and well-solved. If dozens of companies share your need, someone has almost certainly built a product for it, and that product quietly embodies years of refinement, edge cases, and support infrastructure you would otherwise have to discover and pay for yourself.
Buy, too, when the thing isn't a differentiator. Your accounting, your email, your helpdesk — these need to work well, but doing them in a bespoke way rarely gives you any edge over a competitor. Spend your build budget where it actually sets you apart, and buy the rest without agonising over it.
And buy when speed matters more than fit. An off-the-shelf tool you can adopt next week beats a perfect custom one you'll have in three months, when the timeline is the thing that actually counts.
When to build
Build when the process is genuinely, distinctively yours. If how you do something is a real differentiator — the thing that makes you faster, cheaper, or better than the competition — then off-the-shelf software, designed for the statistical average of your industry, will file down exactly the edge you were trying to keep. This is where custom software earns its cost: it lets you encode your advantage instead of surrendering it to a vendor's idea of normal.
Build when nothing on the market genuinely fits. Some needs are specific enough that no product addresses them, or the only options are sprawling enterprise suites that are overkill in every dimension except the single one you care about — and you'd be buying, hosting, and learning ninety percent of a system to use ten percent of it.
Build when the integration is the product. Sometimes the value isn't a new system at all but the connective tissue between systems you already own — and connective tissue is, by its nature, specific to your particular stack. That's custom work almost by definition; nobody sells the exact bridge between your unusual warehouse setup and your particular accounting package.
When we estimate a build, we estimate its life, not its birth. A client surprised by the ongoing cost is a client we've failed.
The trap in building is underestimating the whole cost, and it's a deep one. The build is the beginning, not the end. Custom software has to be hosted, monitored, patched, maintained, and evolved as the business changes around it — for as long as you use it. The upfront quote is the visible tip; the running cost is the mass under the water. Count both before you decide, or you'll make the decision on half the number.
The best answer is usually a bit of both
The real world isn't binary, and the strongest answer to build-versus-buy is very often yes — buy the commodity parts and build only the thin layer that's genuinely yours.
Buy the CRM; build the specific automation that makes it fit the way your sales team actually works. Buy the e-commerce platform; build only the connection to your unusual fulfilment process. Done this way, you get years of someone else's refinement effectively for free on the common parts, and you spend your limited, precious build budget only where it creates real, defensible value that a competitor can't simply purchase.
Most of the custom work I do is exactly this shape. Not "replace everything with bespoke software" — that's the expensive fantasy — but "connect and extend what you already have so it fits how you actually operate." It's cheaper, faster, and markedly less risky than a from-scratch build, and it aims the effort precisely at the spot where effort pays. The mental model worth carrying is a simple one:
- Commodity, and not your edge → buy it, and stop thinking about it.
- Common, but needs to fit you → buy the base, build the thin custom layer on top.
- Genuinely yours, a real differentiator → build it, and build it well.
- Not actually costing you much → do nothing, and revisit later.
Five questions that cut through it
When you're facing this decision, most of the fog lifts once you can answer these honestly:
- 01Is this problem costing us enough to justify solving it at all — or are we solving it because it's annoying, not because it's expensive?
- 02Is the way we do this a genuine differentiator, or just something that needs to work reliably?
- 03Does an existing product fit fundamentally, or only cosmetically once you look past the demo?
- 04Have we counted the full ongoing cost of whichever path we choose, not just the upfront one?
- 05Could we buy the common part and build only the sliver that's truly ours?
Answer those five honestly and the right path is usually obvious within an afternoon. The framework isn't complicated. What's hard is resisting the pull toward the answer you already wanted — the exciting custom build, or the reassuringly cheap off-the-shelf tool — long enough to notice which one the problem in front of you actually calls for.