Should we build or buy this software capability?

{
  "_meta": {
    "schema": "https://www.drawdecisiontree.com/decision-dag.schema.json",
    "source": "https://www.drawdecisiontree.com",
    "description": "DrawDecisionTree.com is a free tool for building, sharing, and embedding interactive decision trees. This file is the machine-readable export of a published decision tree. The `dsl` field contains the original source in the Decision DAG DSL; the `dag` schema is documented at the URL in `schema` above.",
    "links": {
      "interactive": "https://www.drawdecisiontree.com/t/drawdecisiontree/engineering-build-vs-buy.html",
      "embed": "https://www.drawdecisiontree.com/embed/path/drawdecisiontree/engineering-build-vs-buy",
      "dsl_reference": "https://www.drawdecisiontree.com/decision-tree-dsl-reference.html",
      "guides": "https://www.drawdecisiontree.com/guides",
      "schema_docs": "https://www.drawdecisiontree.com/decision-dag.schema.json",
      "author_trees": "https://www.drawdecisiontree.com/trees/drawdecisiontree"
    },
    "generated_at": "2026-05-29T12:05:39.282Z"
  },
  "author": {
    "handle": "drawdecisiontree",
    "first_name": "Andrew",
    "last_name": null,
    "avatar_url": "1d32d828-b6ca-40ec-bdd7-771fe7b9c36a/avatar-1778531481027.svg",
    "display_name": "Andrew"
  },
  "file": {
    "id": "cc4c641d-2f0f-4080-a5bb-ca252d949946",
    "name": "Should we build or buy this software capability?",
    "public_slug": "engineering-build-vs-buy",
    "updated_at": "2026-05-12T16:53:43.587978+00:00",
    "url": "https://www.drawdecisiontree.com/t/drawdecisiontree/engineering-build-vs-buy.html",
    "json_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/engineering-build-vs-buy/tree.json",
    "dsl_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/engineering-build-vs-buy/tree.dag"
  },
  "meta": {
    "description": "Deciding whether to build a capability in-house, purchase a commercial product, adopt an open-source solution, or outsource can define a product's trajectory for years. This tree guides engineering and product leaders through the key trade-offs—competitive differentiation, budget, team capacity, time-to-market, and vendor lock-in—to arrive at a defensible, context-appropriate recommendation.",
    "mode": "decision",
    "entry": "Q1",
    "tags": [
      "engineering",
      "build vs buy",
      "architecture",
      "software strategy"
    ],
    "image": "https://images.unsplash.com/photo-1537432376769-00f5c2f4c8d2?w=1200&q=80"
  },
  "questions": [
    {
      "id": "Q1",
      "text": "Is this capability a core competitive differentiator for your product?"
    },
    {
      "id": "Q2",
      "text": "Does your team have the capacity and expertise to build and maintain this in-house?"
    },
    {
      "id": "Q3",
      "text": "Is there an adequate open-source solution that meets your requirements?"
    },
    {
      "id": "Q4",
      "text": "Is vendor lock-in or long-term control over the roadmap a significant concern?"
    },
    {
      "id": "Q5",
      "text": "Is your time-to-market window shorter than a realistic in-house build would take?"
    },
    {
      "id": "Q6",
      "text": "Is there sufficient budget for an ongoing commercial licence or subscription?"
    }
  ],
  "outcomes": [
    {
      "id": "BUILD",
      "label": "Build In-House"
    },
    {
      "id": "BUY",
      "label": "Buy Commercial Product"
    },
    {
      "id": "OPEN_SOURCE",
      "label": "Adopt Open Source"
    },
    {
      "id": "OUTSOURCE",
      "label": "Outsource to Agency"
    },
    {
      "id": "HYBRID",
      "label": "Hybrid (Buy + Customise)"
    }
  ],
  "dsl": "dag: Should we build or buy this software capability?\nversion: 1.0.0\nimage: https://images.unsplash.com/photo-1537432376769-00f5c2f4c8d2?w=1200&q=80\ndescription: Deciding whether to build a capability in-house, purchase a commercial product, adopt an open-source solution, or outsource can define a product's trajectory for years. This tree guides engineering and product leaders through the key trade-offs—competitive differentiation, budget, team capacity, time-to-market, and vendor lock-in—to arrive at a defensible, context-appropriate recommendation.\ntags: engineering, build vs buy, architecture, software strategy\nentry: Q1\n\nQ1: Is this capability a core competitive differentiator for your product?\n  hint: Ask whether customers choose you *because* of this capability, or whether it is simply table-stakes infrastructure. Differentiated capabilities (proprietary algorithms, unique UX, domain-specific logic) are usually worth owning. Generic plumbing (email delivery, authentication, payments) almost never is—no matter how tempting it is to roll your own. If a competitor could buy the same off-the-shelf solution and match you immediately, the capability is likely not a differentiator.\n  yes -> Q2\n  no  -> Q3\n\nQ2: Does your team have the capacity and expertise to build and maintain this in-house?\n  hint: Consider both current headcount and the ongoing maintenance burden—building is the first cost, not the last. If you would need to hire specialists, account for ramp-up time and the compounding cost of context-switching existing engineers. A capability that requires deep expertise your team does not have (e.g., ML infrastructure, cryptography, real-time systems) carries hidden risk even when strategic intent is clear. Factor in the post-launch on-call burden and the cost of keeping the capability current as the ecosystem evolves.\n  yes -> Q3\n  no  -> [OUTSOURCE]\n\nQ3: Is there an adequate open-source solution that meets your requirements?\n  hint: \"Adequate\" means actively maintained, well-documented, with an acceptable licence for your commercial context, and genuinely covering at least 80 % of your requirements without requiring a fork. Check issue tracker activity, last release date, and number of active contributors as proxies for project health. Factor in the cost of patching or extending: a project that needs significant modification may be more expensive over three years than it first appears.\n  yes -> Q4\n  no  -> Q5\n\nQ4: Is vendor lock-in or long-term control over the roadmap a significant concern?\n  hint: Lock-in matters most when the capability sits on a critical path, switching costs are high, or the vendor's interests may diverge from yours over time. Open-source gives you the source and the right to fork; commercial products give you SLAs and polished support but constrain your ability to adapt the roadmap to your needs. Consider your organisation's risk appetite, the maturity of the vendor ecosystem, and whether your data would be stored in a proprietary format that is difficult to export.\n  yes -> [OPEN_SOURCE]\n  no  -> Q5\n\nQ5: Is your time-to-market window shorter than a realistic in-house build would take?\n  hint: Be honest about your team's delivery history—internal estimates are routinely optimistic. Compare the fastest credible build timeline against the time needed to evaluate, procure, and integrate a commercial or open-source alternative. If you are trying to hit a market window, a committed customer date, or a compliance deadline, the calculus often favours buying even when building would eventually be preferable. Delaying to build something you could buy is a strategic risk in fast-moving markets.\n  yes -> Q6\n  no  -> [BUILD]\n\nQ6: Is there sufficient budget for an ongoing commercial licence or subscription?\n  hint: Model total cost of ownership over three years, not just the first invoice. Include integration work, training, support tiers, and likely price increases at renewal. Compare this against the fully-loaded engineering cost (salary, overhead, and opportunity cost) of building and maintaining the equivalent capability. Also consider whether per-seat or usage-based pricing will become punitive as you scale, and negotiate data portability and exit clauses before signing.\n  yes -> [BUY]\n  no  -> [HYBRID]\n\n[BUILD]: Build In-House\n  color: #2563eb\n  description: Building in-house is the right call when the capability genuinely differentiates your product, your team has the expertise, and the timeline allows it. Establish clear ownership with a named tech lead and document the architectural decisions in an ADR from day one. Define explicit maintenance contracts—who on-calls this, who reviews PRs, what the upgrade path looks like—before you write the first line of code. Resist scope creep: build the minimum that proves the differentiator, ship it, and iterate based on real usage data. Set a six-month review point to reassess whether continued investment is delivering the expected competitive return.\n  code: ENG_BBY_BUILD\n\n[BUY]: Buy Commercial Product\n  color: #16a34a\n  description: Purchasing a commercial product accelerates time-to-market and transfers operational risk to a vendor with deep domain expertise in that capability area. Negotiate beyond the headline price: SLAs, data portability clauses, exit provisions, and API rate limits are often as important as the feature set. Run a structured proof-of-concept against your actual workload—not the vendor's demo environment—before signing any multi-year agreement. Assign an internal integration owner who will manage the vendor relationship, monitor usage against contractual limits, and own the renewal decision. Schedule a vendor health review annually to confirm the product continues to meet your requirements and the company remains financially viable.\n  code: ENG_BBY_BUY\n\n[OPEN_SOURCE]: Adopt Open Source\n  color: #7c3aed\n  description: Open-source adoption gives you full roadmap control and eliminates recurring licence fees, but you absorb the full operational burden of running and maintaining the software. Perform a licence audit before committing—GPL, AGPL, and SSPL carry commercial obligations that may conflict with your business model; MIT and Apache 2.0 are generally safe. Pin to a stable release and establish an internal process for evaluating and applying upstream patches on a regular cadence. Designate a maintainer who monitors the upstream project's health and participates in the community where practical—upstream contributions often yield early access to bug fixes that matter to you. Budget explicitly for the engineering time required to maintain your integration layer and stay current with major releases.\n  code: ENG_BBY_OSS\n\n[OUTSOURCE]: Outsource to Agency\n  color: #ea580c\n  description: Outsourcing is appropriate when the capability is not differentiating and your team lacks both capacity and the relevant expertise to build it efficiently in-house. Select an agency with a demonstrable track record in the specific technical domain—not just general software development—and insist on references from clients with comparable workloads and complexity. Define acceptance criteria, intellectual property ownership, and knowledge-transfer obligations in the contract before any work begins. Plan for a formal handover sprint in which agency engineers pair with your team; code that cannot be maintained internally creates a dependency that will cost you disproportionately later. Establish a 90-day post-handover support SLA to catch issues that only emerge under real production load.\n  code: ENG_BBY_OUT\n\n[HYBRID]: Hybrid (Buy + Customise)\n  color: #0891b2\n  description: A hybrid approach—purchasing a commercial or open-source foundation and layering custom development on top—often delivers the best balance of speed and control when neither pure build nor pure buy is optimal. Start with the vendor or community solution as-is and resist the urge to customise before you have validated what your users actually need from the differentiating layer. Contain customisation to a thin adapter or plugin layer so that upstream upgrades do not break your changes; avoid forking core internals unless absolutely necessary. Document every deviation from the standard distribution as technical debt with a named owner and a target resolution date. Reassess the make/buy split annually: as your needs evolve, the right balance between commercial capability and bespoke logic will shift.\n  code: ENG_BBY_HYB\n"
}