Skip to module content
🧠AI Academy
0/91
Sign in
Module 04 · ~7 min

Build, Buy, or Partner

Why internal builds fail at twice the rate — and when to build anyway.

Reading progress
0/7 · 0%

The big idea

💡Key idea
This isn't a philosophical debate — MIT has a base rate. External partnerships with specialized vendors reached full deployment roughly 67% of the time. Internal builds reached it roughly 33% of the time. That's a 2:1 gap, and it goes unpriced in most 'we have engineers' conversations. The case to build anyway exists, but it's narrow: the workflow is your proprietary competitive edge (not table stakes), no vendor exists at the required depth, the data legally cannot leave your infrastructure, and a named internal owner is budgeted — not assumed — for year two. Everything else is a pride build.
Quick check
1 question · instant feedback
0/1
  1. MIT NANDA's headline deployment ratio:

Numbers that matter

~67% / ~33%
deployment rate: vendor partnerships vs internal builds
MIT NANDA
Quick check
1 question · instant feedback
0/1
  1. Best justification to build in-house?

How to run it

  1. Proprietary edge
    Buy: workflow is table stakes / commodity. Build: workflow IS the proprietary advantage.
  2. Vendor availability
    Buy: a vertical vendor exists at the required depth. Build: no vendor exists AND you'll do the work anyway.
  3. Data constraints
    Buy: vendor's residency/retention terms pass the risk register. Build/self-host: data can't leave, or terms fail — knowingly.
  4. Year-2 owner
    Buy: the vendor, contractually, with an exit path for the data. Build: a named internal owner or retained partner — budgeted, not assumed.
  5. Learning-asset ownership
    Buy: acceptable to accrue adaptation inside the vendor (price the lock-in). Build: corrections, evals, workflow data must stay client-owned.
Quick check
1 question · instant feedback
0/1
  1. The 'year-2 orphan' failure pattern is prevented by:

In the field

🔬Worked example
Half-page build/buy/partner memo per opportunity: (1) is the workflow your proprietary edge or table stakes? (2) does a vendor exist at the required depth? (3) can data leave your infra? (4) who owns it in year two? Cite the 67/33 base rate. This memo protects clients from pride builds, creates the paper trail if you're overruled, and positions your build work honestly as the thin-proprietary-layer exception.
🚫When not to reach for it
'We have engineers' is not, by itself, a business case for building — the 2× gap goes unpriced. Feature-matrix buying is the mirror failure: select on operational bake-offs with the client's own workflows and data, not checkbox counts. Never sign without data-export and evals-portability terms — the switching cost surfaces at renewal on the vendor's side of the table.

Pitfalls & takeaways

Failure modes

  • Pride builds. 'We have engineers' as the entire business case; the 2× deployment gap goes unpriced.
  • Feature-matrix buying. Selecting on checkbox counts instead of operational bake-offs on the client's own workflows.
  • Unpriced lock-in. No data-export and evals-portability terms at signature; switching cost surfaces at renewal.
  • Year-2 orphans. Builds scoped to launch with no maintenance owner — the quiet second cause of the internal-build failure rate.

Durable takeaways

  • Cite the 67/33 base rate in every build/buy conversation.
  • 'We have engineers' isn't a business case.
  • Data-export and evals-portability terms belong in the contract, not the postmortem.
  • Year-2 owner budgeted, not assumed.

Do the work

📦Artifact to produce
Build/buy/partner half-page memo per scored opportunity.

Sources

  • · MIT NANDA, The GenAI Divide (2025)