Build vs Buy Analysis
Whether a capability is differentiating enough to build, tested against cost, fit, time and the cost of being wrong.
The decision is not primarily financial. It turns on one question — is this capability how we win? — and the money is a check on the answer rather than the answer itself.
The frame
| Dimension | Build | Buy | Which way it points here |
|---|---|---|---|
| Differentiation | Only worth it if customers choose us for this | Fine for parity capability | Buy — pricing is table stakes in our market |
| Fit to requirement | Exact | 70–90%, and you adapt | Build — but see workaround cost below |
| Time to value | 11 months | 6 weeks | Buy |
| Three-year TCO | ₹1 939 L | ₹838 L | Buy |
| Run burden | 2.4 FTE, ours forever | 0.3 FTE plus vendor management | Buy |
| Control over roadmap | Total | Vendor's priorities, not yours | Build |
| Switching cost later | High — we own it | High — proprietary model | Neutral |
| Regulatory fit | We prove everything ourselves | Vendor's certifications inherited | Buy |
| Cost of being wrong | 11 months and a team | 6 weeks and a subscription | Buy |
The 10–30% gap. The vendor does not cover multi-currency promotions or our tiered partner rates. Options: workaround in the ordering service (~6 weeks), vendor roadmap commitment (offered, Q3, uncontracted), or accept a manual process for the 4% of volume affected. Recommendation: workaround plus a contractual commitment, with the manual process as the interim.
Recommendation: buy, with an exit provision — data exportable in an open format, contract reviewed at 24 months, and the integration built behind our own interface so the vendor sits behind a boundary we control.
When you produce it
Whenever a capability is needed that a market exists for, which is most of them. Before any procurement conversation, so the requirement is not shaped by the first demo seen.
Who reads it
Executives making the call. Finance and procurement, who negotiate. Architects, who implement the boundary that makes a future change survivable.
What good looks like
- Differentiation is judged first, and honestly. Almost nothing is differentiating, and building non-differentiating capability is the most expensive habit in enterprise IT.
- The gap between the requirement and the product is quantified and its workaround costed, because that gap is where buy projects fail.
- Cost of being wrong is compared, not just cost of being right.
- An exit provision is part of the buy recommendation from the start.
- An anti-corruption boundary is designed in, so the vendor's model does not leak into yours.
Common mistakes
- Building because the product is 85% right, then spending more than the build to bridge the last 15%.
- Buying and then customising heavily, which is building with worse tools.
- Ignoring the run cost of building, which continues after the project ends.
- No exit plan, discovered at the third renewal when the price doubles.