Build versus buy: when off-the-shelf ends up costing more
Off-the-shelf is cheaper until you count configuration, integration, and the processes you bend to fit it. A test for deciding which side a capability falls on.
The default answer is buy, and for most capabilities the default is correct. You should not build authentication, payroll, email delivery, or an accounting ledger. Those are solved problems where someone else's version is better than yours will be.
The default becomes wrong in a specific and predictable situation: when the capability is how your business is different from its competitors.
The test
One question separates most cases:
If this worked exactly like it works at your closest competitor, would you lose anything?
If the answer is no, buy. Expense reporting, HR onboarding, ticketing, and document storage all pass this test comfortably.
If the answer is yes, you are looking at the thing customers actually pay you for, and a product built for the average of your industry will make you average at it.
| Capability type | Default | Exception |
|---|---|---|
| Commodity back office | Buy | Almost never build |
| Industry-standard workflow | Buy and configure | Build only if configuration exceeds the build cost |
| Integration between bought systems | Build thin | Buying an iPaaS is fine; buying a black box is not |
| The thing you compete on | Build | Buy only to validate demand, with a planned exit |
| Regulated record of truth | Depends | Buy the engine, build the workflow around it |
The costs that make "buy" more expensive than it looks
Licence cost is the number in the comparison. It is rarely the largest number in the total.
Configuration is development without engineers. A platform configured across 200 screens by consultants is a codebase. It has no version control you trust, no test suite, no code review, and the people who understand it bill by the hour. It is often harder to change than the equivalent custom code.
Integration is yours regardless. Buying does not remove the integration work; it relocates it. And you are now integrating against someone else's model, on their release schedule, with their rate limits.
Process change is a real cost with no invoice. Adopting a product means adopting the process it encodes. When that process is better than yours, this is a benefit. When it is merely different, you pay for it in training, exceptions, and shadow spreadsheets that grow around the parts that do not fit.
Exit cost compounds quietly. Every year of data accumulating in a proprietary model raises the cost of leaving. Ask what an export contains before you sign, not when you want out.
The hybrid that usually wins
Most good answers are not build or buy. They are buy the engine, build the edge.
Someone else runs the hard, undifferentiated core: the payments processor, the identity provider, the data warehouse, the model API. You build the workflow, the domain rules, and the interface that make it specifically yours.
This keeps the build small and the differentiation in your hands. It has one requirement: the bought component must expose a real API. If it does not, you have bought a system you cannot build on, and every extension becomes screen automation or a support ticket.
Reversibility should decide close calls
When the analysis is genuinely balanced, pick the option that is cheaper to undo.
Buying is usually cheaper to reverse early and much more expensive to reverse late, as data and process accumulate. Building is expensive up front and stays roughly as reversible as it started, provided you kept the boundaries clean.
That asymmetry argues for buying to validate a need you are not sure about, with an explicit decision point at a year, and building once the need is proven and the requirements have stopped moving.
Getting the estimate right on the build side
If you land on build, the number depends on far more than the feature list. The factors that actually move it are in how to size the cost of custom software, and if you are replacing a system that must keep running, the sequencing is a strangler-fig migration.
We do this analysis at the start of most engineering engagements, and we have recommended buying often enough that it is a normal outcome rather than a polite one. How we work and what we protect is in our security practices.