Build versus buy is usually argued as a cost question and then decided on instinct. Both halves of that are avoidable. The cost comparison people run is the wrong one, and the instinct is usually a proxy for a strategic question nobody has asked out loud.
Start with the only question that reliably settles it
Is this capability a differentiator or a utility?
A utility is something your customers assume works and would never choose you for. Payroll. Email. Accounting. General ledger. Applicant tracking. If you build a utility, you have spent scarce engineering capacity reaching parity with something you could have bought on a card, and you now maintain it forever.
A differentiator is a process that is part of why customers choose you, or part of why your unit economics beat a competitor's. A dispatch algorithm at a logistics firm. A pricing engine at a specialist insurer. An underwriting workflow that closes in a day when the industry takes a week. Buying a differentiator means buying the same capability your competitors can buy, and accepting the vendor's pace of change on the thing you compete on.
Run the five-year comparison, not the licence comparison
Buying looks cheaper because the visible number is small and the invisible numbers are deferred. Build looks expensive because the entire cost arrives up front. A five-year total, with both columns filled in honestly, is a different picture.
| Cost line | Buy | Build |
|---|---|---|
| Year one visible | Licence plus implementation | Full build cost |
| Configuration and consultants | Frequently 1x to 3x the first-year licence | Included in the build |
| Integration with your other systems | Yours to pay for either way | Yours to pay for either way |
| Growth | Per-seat or per-transaction, scales with your success | Roughly flat, plus hosting |
| Change requests | Vendor roadmap, or expensive customisation | Your backlog, your priority |
| Maintenance | Included, but so is forced migration | 15 to 25 percent of build cost annually |
| Exit | Data extraction, retraining, re-integration | You own it, so no exit event |
Two lines deserve specific attention because they are where the surprises live.
The first is per-seat pricing. A platform at $90 a seat is inexpensive at forty people and is $86,400 a year at eighty. If the tool is tied to headcount and your plan is to double headcount, you have signed up for a cost that scales with your success rather than with the value the tool delivers. Model it at your three-year plan, not at today's count.
The second is maintenance on the build side, which teams routinely omit. Custom software is not free once shipped. Budget 15 to 25 percent of the build cost annually for dependency updates, small changes, and the occasional integration break. A build comparison that leaves this out is not honest, and it is usually the line that makes buying correct for genuine utilities.
The signals that you have already outgrown buying
Some situations announce themselves. If several of these are true, the platform is no longer serving you.
- You employ someone whose main job is configuring and working around the tool.
- Your team maintains spreadsheets to do the part the platform cannot.
- The annual bill has grown faster than your use of it, because it tracks headcount.
- You have requested the same feature for two years and it remains on a roadmap.
- A meaningful share of your customer-facing process is shaped by what the tool allows rather than what you would choose.
- Migration is discussed and abandoned because nobody knows how to get the data out.
The last one is worth pausing on. If you cannot describe how you would leave, you are not a customer with options, and your renewal negotiation reflects that.
The customisation trap
The worst outcome in this whole decision is neither building nor buying. It is buying a platform and then customising it heavily to fit a process it was not designed for.
You now pay licence fees for software you have effectively rebuilt. Every vendor upgrade risks breaking your customisations. The consultants who understand your configuration are external and expensive. And you still cannot change the parts that matter most, because they are core to the vendor's product.
A reasonable rule: if implementation and configuration cost more than roughly twice the first-year licence, stop and price the build. You are already paying build-level money for a system you will not own.
The third option most teams skip
Build versus buy is a false binary in most real situations. The strongest answer is frequently to buy the commodity substrate and build only the thin layer that makes you different.
Buy the CRM, build the quoting logic that is genuinely yours and write results back. Buy the accounting system, build the margin analysis your industry has no standard tool for. Buy the warehouse platform, build the dispatch optimisation that is the reason customers pick you.
This is more work to design than either pure option, because it requires knowing exactly where your differentiation sits. That is the same knowledge the first question in this article demands, which is why the question is worth answering carefully rather than quickly.
A defensible decision process
- Write down the process as it actually runs today, including the workarounds. Most build-versus-buy debates are held over an idealised process nobody follows.
- Classify it: differentiator or utility. Get the leadership team to agree in writing, because this is the strategic call and it is not an IT decision.
- For utilities, shortlist two or three platforms and price five years at your three-year headcount, including implementation and integration.
- For differentiators, price a first build phase against the same five-year window, including annual maintenance at 20 percent.
- Ask what changes if you are wrong. Buying wrongly costs a migration. Building wrongly costs a write-off. Weight accordingly.
- Decide, write down why, and put a review date on it. Circumstances change and a documented decision is one you can revisit without relitigating from scratch.
The point of writing down the reasoning is not process for its own sake. It is that in two years someone will ask why you chose this, and the answer should be a document rather than a memory.