Every enterprise CTO faces some version of the same question every quarter: should we build this ourselves, license something off the shelf, or outsource the build to a partner? Most decision frameworks treat this as a 2×2 matrix. Reality is messier — and the wrong answer can cost you 18 months of timeline and seven figures of budget.
This whitepaper covers the framework we use with our clients to evaluate a build/buy/outsource decision in 90 minutes. It works because it forces you to answer four questions in order instead of jumping to commercial models first.
The four questions, in order
1. Is this system a source of competitive advantage?
If the answer is no, you should not build it. The right answer is to license — even if the license is expensive. Engineers are scarce, and engineering capacity is best spent on differentiating systems, not commoditized ones.
The trap: most companies overestimate how differentiating their internal systems are. A warehouse management system, even one that's “a little bit custom,” is rarely a competitive advantage. A pricing engine, on the other hand, often is. Be honest.
2. Does the off-the-shelf option fit your operating model?
If you've answered yes to question 1 (license it) — but the off-the-shelf option requires you to change how your business operates, you need to revisit. The cost of bending your operations to fit a software package is almost always higher than the cost of building.
Off-the-shelf software has a hidden line item: the operational change required to fit it. It rarely shows up in the procurement business case.
3. Do you have the engineering depth to build this internally?
Even when build is the right answer, internal build is not always the right path. Three scenarios should push you toward outsourcing or partnering:
- Domain depth gap. If your engineers haven't shipped in this domain before, the first 3–6 months are ramp time you're paying for.
- Capacity ceiling. If hiring 8 engineers in 90 days isn't realistic, you don't have the option to build internally on your timeline.
- Strategic focus. Even if you have capacity, putting it on this system might starve a more important initiative.
4. What's the right engagement structure?
Once you've decided to outsource, the engagement structure matters more than the partner selection. The wrong structure with the right partner usually fails; the right structure with a competent partner usually succeeds.
Three structures work. Fixed-scope projects when you know exactly what to build. Dedicated engineering teams when scope evolves. Full-cycle delivery when you want a single accountable partner from kickoff through year-three operations.
The 2-page version of the framework
- Map your software landscape into “differentiating” and “commodity” quadrants.
- For commodity systems: license the best fit. Resist the urge to customize.
- For differentiating systems: assess internal depth, capacity, and strategic focus.
- If any one is missing, outsource — and pick the engagement structure that matches your scope clarity.
Where this framework breaks
It breaks when there's a hidden agenda — usually political. The most common pattern: an engineering leader wants to build because building grows their org. A CIO wants to buy because buying simplifies the audit trail. The framework above assumes a good-faith evaluation. If you're not in good faith with yourself, no framework will save you.
This is an excerpt from a longer working paper we share with qualified clients during engagement scoping. The full version includes a vendor evaluation rubric, a TCO model spreadsheet, and three worked examples from past engagements.