What each choice actually commits you to
Buying commits you to a relationship: a vendor's roadmap, pricing power at renewal, and the discipline of adapting your process to a product built for many customers. Building commits you to an institution: a team, a backlog, an on-call rota and a maintenance obligation that outlives every sponsor who approved the business case. The build estimate that reaches the steering committee is almost always the cost of version one. The cost that matters is the decade of versions after it, and that number rarely appears on the slide.
The genuine case for buying
For any capability where your requirements resemble everyone else's, a product amortises engineering across hundreds of customers, and you get security patching, compliance updates and feature development you never have to staff. Time-to-value is measured in months, not roadmap quarters. The vendor has already made the mistakes your team would make first, and its product reflects requirements from organisations further down the road than you. Buying also keeps your scarce engineers pointed at problems that are actually yours, which is a strategic argument disguised as a resourcing one.
The genuine case for building
When a capability is the business, owning it is the point. A system that encodes your differentiating process, your data advantage or your customer experience is worth building precisely because no vendor will prioritise it the way you will, and because putting it inside a product would eventually share your edge with your competitors, feature by feature. Building also buys freedom of movement: no licence metering shaping your architecture, no renewal negotiation with a supplier who knows you cannot leave, and the option to change direction at the speed of your own decisions.
The trade-offs at a glance
| Dimension |
Build |
Buy |
| Time to first value |
Quarters to years |
Weeks to months |
| Fit to your process |
Exact, by definition |
Approximate; you adapt to the product |
| Ongoing obligation |
A permanent team and backlog |
Subscription, renewal risk, roadmap dependence |
| Differentiation |
Can encode real advantage |
Available to every competitor who pays |
| Cost visibility |
Underestimated at approval, discovered later |
Priced upfront, escalated at renewal |
| Security and compliance |
Your responsibility, forever |
Largely carried by the vendor |
| Exit |
You own everything, including the burden |
Contract exit plus data migration |
When each route clearly wins
Buy when the capability is commodity infrastructure, when speed matters more than fit, or when the honest audit of your engineering organisation says it cannot carry another permanent system. Build when the capability is inseparable from how you win, when no product on the market fits without contortions that destroy the value, or when what the system encodes is so commercially sensitive that placing it with a vendor who also serves your competitors is itself a risk. Neither answer is permanent: capabilities commoditise, and a justified build can become an unjustified one within five years.
The options between build and buy
- Buy the platform, build the edge: a configurable product carries the standard workflow while your team builds only the differentiating layer on top.
- Open-source core with paid support: ownership economics closer to build, with a community carrying part of the maintenance burden.
- Buy now, build later: take the product to learn the real requirements, and revisit building once you know which features actually earn their keep.
- Build with a partner, on a contract that transfers the code, the documentation and the knowledge, so the asset does not live in someone else's repository.
Questions that settle it for your case
- Would a competitor using the same product lose anything? If not, why are we building it?
- What is the fully loaded cost of the team this system needs in year five, and who has budgeted it?
- Which of our requirements are genuinely unusual, and which are preferences wearing the word "requirement"?
- If the vendor doubled the price at renewal, what would our position be?
- Who maintains this when the engineers who built it move on, and is that person real or hypothetical?
