Cost & Budgeting
Cost & Budgeting3 min read
Build vs buy: the test that actually settles it
Most build-versus-buy debates are decided by whoever argues hardest. There is a simpler test, and it has nothing to do with feature comparison.
Working on something like this?
Get an estimateThe short version
- Build only where the process is your competitive advantage. Buy everywhere else, including places it feels inefficient.
- The real cost of buying is integration and workarounds, not licence fees.
- The real cost of building is year three, not year one.
- “It's 80% right” is the most expensive sentence in software procurement.
The debate usually runs on the wrong axis. Somebody builds a feature matrix, the off-the-shelf tool wins on count, and the decision gets made on a spreadsheet that never mentions the thing that will actually determine the outcome.
Here is a shorter route to the same answer.
The test
Is this process something we do differently from our competitors, and does doing it differently make us money?
Nobody wins by having bespoke payroll. Plenty of companies win by having a bespoke pricing engine, a bespoke dispatch algorithm, or a bespoke underwriting flow. Both are internal software. Only one of them is worth owning.
The corollary is uncomfortable: if your process is not differentiated, the right answer is to change your process to fit the tool, not to build a tool that fits your process. Teams resist this, and it is usually correct anyway.
What buying actually costs
Licence cost is the visible number and rarely the largest one.
- Integration. Getting the tool talking to your other systems, in both directions, with reconciliation when they disagree.
- Configuration drift. Two years of settings changes that nobody documented and one person understands.
- The workaround tax. The spreadsheet that exists because the tool cannot do one thing. It never goes away and it is never in the business case.
- Per-seat growth. Priced comfortably at 30 users, uncomfortably at 300.
- Exit cost. Getting your data out in a usable shape, when the export is CSV and the relationships live in the UI.
What building actually costs
The build is the cheap part. Ownership is the expensive part, and it arrives after the excitement has gone.
1471160455–4942239500%
of build cost, every year, to keep it supported
Year36933
when unowned software becomes a rewrite
Custom software needs a named owner for as long as it runs. Not a team that built it once. Someone whose job includes it next year. Most build-versus-buy business cases quietly assume this person is free. Where there is nobody internal to be that owner, maintenance and support is the line item that keeps the assumption honest, and what custom software actually costs puts a number on it.
The middle path most teams miss
Build-or-buy is a false binary. The strongest pattern is usually to buy the commodity and build the seam.
1
Buy the system of record
ERP, CRM, accounting, payroll, identity. These are solved, regulated, and boring. Owning them is a liability with no upside.
2
Build the layer your business actually runs on
The pricing logic, the routing rules, the customer-facing experience, the thing your operators use forty times a day. This is where the differentiation is and where off-the-shelf will always be 80% right.
3
Own the integration between them
Documented APIs, tested syncs, reconciliation when systems disagree. This is unglamorous and it is where most of the value leaks in a bought-everything estate — a carrier running three vendor portals was losing four to six days per order to exactly this seam. It is the core of what system integration work buys you.
A decision table
Before you commit either way
Five things to establish first
- Who owns this software in year three, by name and job title
- What the exit looks like, from the vendor or from the codebase
- Which integrations are required, and whether anyone has tested them
- What the workaround tax is today, in hours per week
- Whether the process is genuinely differentiated, or just familiar
That last one is the hard question, and it is worth answering honestly. Familiarity feels like differentiation from the inside. It usually is not.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
Build where the process is genuinely differentiated and that differentiation makes money: pricing engines, routing algorithms, core customer experience. Buy everywhere else, including commodity areas where buying feels clumsy: payroll, accounting, CRM, identity. If a competitor could copy your process from a job advert, it is not differentiation and you should buy.
Licence fees are usually the smallest line. The larger costs are integration with your other systems, undocumented configuration drift, the workaround tax of spreadsheets built to cover gaps, per-seat pricing that scales badly, and exit cost when the export is a flat CSV and the relationships only exist in the interface.
The build is the visible cost; ownership is the larger one. Budget 15–20% of build cost annually for maintenance, and identify by name the person responsible for the software in year three. Most build-versus-buy business cases assume that owner exists and is free. Software without a named owner becomes a rewrite around year three.
Yes, and it is usually the strongest. Buy the systems of record (ERP, CRM, accounting, identity), then build only the layer your business actually competes on, and own the integration between them. This keeps commodity functions cheap and supported while putting engineering effort where it produces advantage.