Build / Buy / Bake
Build, buy or adapt? The decision framework for evaluating every product capability without wasting budget or energy.
Description
The Build / Buy / Bake framework is a decision-making tool that structures the trade-off between three options for developing a product or technical capability: building it in-house (Build), purchasing a market solution (Buy), or adopting and customizing an open-source base or existing standard (Bake). Its purpose: move beyond the instinctive "we build everything ourselves" debate to make an explicit, documented, and defensible choice. Without a shared framework, the build vs. buy decision is made on gut feeling, influenced by the last opinion heard or the budget at hand. The tech team pushes to build for stack control, the CPO wants to buy for speed, and the Bake option (adopting an open-source foundation and "cooking it your way") remains invisible because it is never named. Geoffrey Moore established the foundational principle in Core vs Context: only capabilities that constitute a direct competitive advantage justify a Build investment. Everything else can and should be bought or adapted. Like a chef who does not mill their own flour when their advantage lies in the recipe, the product team must focus its energy where it creates irreplaceable value. Total cost of ownership (TCO) over 3 to 5 years, delivery speed, level of differentiation, and internal maintenance capacity are the four levers that tip the decision. ThoughtWorks formalized this type of framework in its consulting practices: teams that apply it systematically reduce decision debt and concentrate their resources on their core business.
Objectives
- Identify problems
- Prioritize work
- Structure development
- Ensure strategic alignment
- Ensure strategic alignment
Used by
- -Amazon (documented Build decisions on core capabilities like the recommendation engine, Buy on peripheral services)
- -Netflix (Build on the recommendation algorithm and player, Bake on infrastructure with open-source foundations like Cassandra and Kafka)
- -Spotify (explicit Build vs Buy decisions on data and monetization publicly documented in their engineering blogs)
Advantages
- Traceable and defensible decisions. Each choice rests on explicit criteria: no more "we have always done it this way" in front of the board or investors.
- Focus on the core business. By systematically identifying what truly differentiates, teams stop spending engineering energy on commodities.
- Reduced decision debt. Build vs buy choices made ad hoc without a framework accumulate into costly architectural inconsistencies. This framework enforces a shared logic.
- Bake as an underestimated accelerator. Adopting and customizing a mature open-source foundation reduces time to market by 40 to 60% on non-differentiating capabilities, without vendor lock-in.
Limitations
- Requires an honest TCO analysis. If teams underestimate the maintenance cost of a Build to defend their preferred option, the framework produces bad decisions.
- Difficult to apply under time pressure. In urgent or fast-pivot mode, this framework slows things down. Reserve it for structural decisions with a minimum 12-month horizon.
- Biased by team culture. A strong engineering team will tend to overvalue Build. A SaaS-oriented CPO will overweight Buy. Bring in an external third party to challenge scoring on critical decisions.
- The Bake option requires real open-source expertise. Bake is not free: customizing Keycloak or setting up a Kubernetes cluster demands specific skills.
How to apply Build / Buy / Bake
- 1
Name the capability precisely
Describe the capability in one sentence: "user authentication," "recommendation engine," "data pipeline." The vaguer the definition, the more the decision will be contested. Output: 1 capability statement validated by the team.
- 2
Assess the differentiating character (Core vs Context)
Ask the question: if a competitor bought exactly the same solution, would you lose a competitive advantage? If not, the capability is contextual. Only core business capabilities justify a systematic Build. Output: Core or Context classification.
- 3
Calculate the TCO over 3 to 5 years for each option
Estimate initial costs, maintenance, integrations, upgrades, and opportunity cost (engineering time allocated). A Build underestimated at 6 months can weigh 3 years of hidden costs. Output: comparative TCO table with 3 columns (Build / Buy / Bake).
- 4
Identify available Buy options
Identify 2 to 4 SaaS solutions or vendors that cover the need. Evaluate: functional coverage, vendor lock-in, API integration, public roadmap. Output: Buy shortlist with scoring.
- 5
Identify available Bake options
Identify open source foundations, community standards, or configurable platforms that cover 60 to 80% of the need. Evaluate maturity, community, and customization effort. Examples: PostgreSQL, Kubernetes, Keycloak. Output: Bake shortlist with estimated effort.
- 6
Score the three options on 4 criteria
Rate Build, Buy, and Bake on: competitive differentiation (1-5), time to market (1-5), 3-year TCO (1-5, inverted), internal maintenance capability (1-5). Weight according to the company's context. Output: a 3-row scoring matrix, decision oriented.
- 7
Validate with technical and business stakeholders
Present the matrix to the CTO, CPO, and impacted teams. The goal is not consensus but transparency of assumptions. Document disagreements and review conditions. Output: formalized decision with assumptions and review conditions.
- 8
Plan implementation and contract exits
For a Buy or Bake, anticipate exit clauses, data exports, and migration scenarios. For a Build, define validation milestones before scaling the investment. Output: transition plan with milestones and reversibility conditions.