Build, Buy, or Partner?
Decision trees, risk trade‑offs, and a reusable template for any org
“Firms that select their growth modes based on the circumstances they face, tend to perform better and to survive than firms which specialize in one mode.” - Laurence Capron, coauthor of Build, Borrow, or Buy. (Thinkers50)
Every quarter, somewhere, an executive team asks the deceptively simple question: Should we build this capability ourselves, buy software, or partner? Most organizations answer from habit-“we’re a build shop,” or “we buy whenever possible.” That’s risky. The right choice depends on your strategy, time constraints, capability maturity, risk posture, and the evolution stage of the capability itself.
Below, you’ll find a practical decision tree, an evidence‑based look at the real risks and costs, and a one‑page templateyou can reuse in any organization to make the call (and defend it).
Start with the strategy, not the tool
Capron and Mitchell’s “Resource Pathways” framework offers a timeless starting point: Build when you have a relevant base of internal resources, Borrow/Partner when you can obtain resources effectively through contracts or alliances, and Buy when you need deep control and integration that markets can’t reliably provide. (O’Reilly Media)
This isn’t just theory. In practice, teams ship faster and avoid rework when they map the capability’s strategic importance and maturity. Wardley‑style thinking says: buy commodities, build differentiators, and be explicit about boundaries so you don’t end up with a monolithic vendor “owning” your architecture. Thoughtworks calls this Bounded Buy-only select vendor products that can be contained within a clear bounded context to avoid the Vendor Kinganti‑pattern. (Thoughtworks)
A quick decision tree you can run in an hour
Use this as a working session with product, engineering, security, finance, and legal.
1) Is this capability a core differentiator?
├─ No → Treat as commodity → go to 2
└─ Yes → go to 3
2) How urgent is time-to-impact?
├─ <3 months → Bias to BUY (bounded) or PARTNER
└─ ≥3-6 months → BUY (bounded) or assemble with low-code; revisit in 6 months
3) Do we have relevant in-house expertise and bandwidth NOW?
├─ Yes → go to 4
└─ No → PARTNER (near-term) while we incubate BUILD path; reassess in 1-2 quarters
4) What integration complexity and data gravity are we facing?
├─ High coupling / sensitive data / many systems → BUILD or PARTNER with co-dev
└─ Moderate / well-defined APIs → BUY (bounded) or BUILD small thin layer
5) What risks dominate (security, compliance, availability, IP)?
├─ Heavy regulated (e.g., SOC 2/PII/financial) → favor vendors with certs; or BUILD if data residency/control is critical
└─ Typical SaaS risk → weigh TCO & exit plan
6) Exit & evolvability:
├─ If buying/partnering, can we exit in <90 days with portable data & minimal code change?
└─ If building, can we support 24x7 and scale without starving product roadmap?
Decision:
- If (core differentiator + in-house capability + high integration risk) → BUILD
- If (commodity + urgent) → BUY (Bounded)
- If (market access or co-creation needed) → PARTNER
Two guardrails:
“You can’t buy integration.” Even with modern iPaaS and prebuilt connectors, stitching systems together is engineering work you must plan and own. (martinfowler.com)
Conway’s Law applies. “An organization… will stamp out an image of itself in every design it produces.” If you build, design teams and communication paths will be reflected in the software’s shape; plan your org to fit the system you need.
The risk reality check (with data)
Big IT projects are risky. A McKinsey/Oxford study of 5,400+ IT projects found that large ones run 45% over budget, 7% over time, and deliver 56% less value than expected; 17% go so badly they threaten the company. This is why “build” needs ruthless scoping and staged bets. (McKinsey & Company)
Fat‑tail risk is real. In an analysis of 1,471 IT projects, Flyvbjerg & Budzier found one in six became “Black Swans,” with ~200% cost overrun and ~70% schedule overrun-averages hide the danger. (arXiv)
Alliances aren’t a free lunch. HBR reports alliance success rates “hover near 50%,” and joint ventures often last only 5–7 years-partnerships require active governance and clear exit ramps. (Harvard Business Review)
Buying shifts risk, doesn’t erase it. You’ll still carry integration and lock‑in risks (APIs, data model drift, roadmap mismatch). And don’t forget egress fees (charges for moving data out of clouds)-plan them into your exit and analytics costs (see AWS S3 pricing for examples). (Amazon Web Services, Inc.)
Compliance has a price tag. If you build and operate the capability, expect ongoing security and compliance spend. Vendor estimates put SOC 2 costs (readiness, testing, audit, maintenance) from tens of thousands to low hundreds of thousands depending on scope and maturity. (Secureframe)
The trade‑offs at a glance
BUILD (custom)
Pros: Fit to your strategy; control over roadmap & data; easier to embed unique workflows.
Risks: Delivery risk and maintenance burden; talent and opportunity costs (what product bets are you delaying?); schedule risk (remember Brooks’s Law: “Adding manpower to a late software project makes it later.”) (Wikipedia)
Watch‑outs: Org design (Conway’s Law); ongoing 24x7 ownership; recruiting & retention.
BUY (bounded)
Pros: Fastest time‑to‑impact; vendor carries non‑differentiated R&D; leverages existing certifications and SLAs.
Risks: Lock‑in; mismatched data model; customization creep; “last 10% tax” for edge cases; egress costs.
Watch‑outs: Enforce Bounded Buy-keep the vendor within one capability boundary; don’t let a tool become the architecture. (Thoughtworks)
PARTNER (ally/borrow)
Pros: Access partner’s capabilities, channels, or data; risk sharing; co‑innovation.
Risks: Governance overhead; IP and branding complexity; alliance failure rates around 50% mean you need stage gates and clear unwind clauses. (Harvard Business Review)
Watch‑outs: Joint roadmapping; clear operating model; agreed success metrics and milestones.
SLA reality: 99.9% uptime ≈ 8.76 hours downtime/year; 99.99% ≈ 52.56 minutes. Your tolerance for those gaps should influence build/buy/partner choices for customer‑facing systems.
A simple TCO model you can trust
When you compare options, model five years (shorter for hypergrowth teams), and include both cash and capacity costs:
Build TCO = Engineering (new + maintenance) + Cloud/infra + Sec/Compliance (audits, pen tests) + Support/ops + Opportunity cost of FTEs shifted from core roadmap + Refresh/rewrite cycle.
Buy TCO = Subscription + Implementation (internal & SI) + Customization/edge work + Integration build & run (remember: you can’t buy integration) + Egress/overage + Vendor price escalators + Exit/migration cost. (martinfowler.com)
Partner TCO = Revenue share/fees + Joint GTM cost + Integration & co‑dev + Governance + Exit/unwind cost.
Pro tip: run a sensitivity analysis-how does the decision change if usage doubles, vendor raises price 15%, or you must meet a new compliance bar?
The reusable one‑page template (copy/paste)
Build–Buy–Partner Canvas (Version 1.0)
Use for any capability. Keep it to one page; attach a TCO model as an appendix.
1) Outcome & metric
Business outcome we’re buying/building (e.g., “reduce onboarding time by 40%”).
KPI(s) and target date.
2) Capability classification
☐ Core differentiator ☐ Supporting ☐ Commodity
Notes on Wardley stage (Genesis → Custom → Product → Commodity). Decision implication: buy commodities, build differentiators. (Thoughtworks)
3) Time‑to‑impact need
Must be in customers’ hands by: _____ (If < 3 months, bias to BUY/PARTNER.)
4) Constraints
Data sensitivity & residency: _____
Compliance required: ☐ SOC 2 ☐ ISO 27001 ☐ HIPAA ☐ PCI ☐ Other: ___ (call out cost/lead time). (Secureframe)
5) Option scoring (0–5 per criterion; weight in parentheses)
Strategic differentiation (25%)
Time‑to‑impact (20%)
In‑house capability & bandwidth (15%)
Integration complexity (15%)
Total cost of ownership over 3–5 years (15%)
Risk & compliance posture (10%)
Scores
BUILD: ___ / 100 - Rationale: ____
BUY (bounded): ___ / 100 - Vendor shortlist: ____ | Boundary: ____ (Thoughtworks)
PARTNER: ___ / 100 - Potential partners & value exchange: ____
6) Risk register (top 5)
Risk, Preventative control, Owner, Trigger, Plan B.
7) Exit plan
For BUY/PARTNER: Data export format, re‑platform path, egress costs, target D+90 exit readiness. (Amazon Web Services, Inc.)
For BUILD: Bus factor, runbook, on‑call coverage, deprecation plan.
8) Decision & guardrails
Decision: Build | Buy (bounded) | Partner
Guardrails (examples): keep vendor within domain boundary; no private APIs; require data export; 90‑day proof‑of‑concept with kill switch; quarterly alliance review.
(Paste this section into your internal doc, fill it in with the cross‑functional team, and attach a sheet with the cost model and sensitivity analysis.)
Practical patterns that work
Bounded Buy + thin integration layer. When speed matters and the capability is not your differentiator, buy-but bound it. Require open, documented APIs. Keep a thin anti‑corruption layer so your domain model isn’t swallowed by the vendor’s. (Thoughtworks)
Partner‑to‑build transition. When you lack expertise, partner for six months with set milestones and a co‑development plan; transfer knowledge to your team, then decide whether to insource. Remember alliance half‑life: design for success and for graceful exit. (Harvard Business Review)
Strangler fig for legacy. If BUILD is the end state but risk is high, carve a narrow slice (one user journey, one market) and ship. Reduce scope until a single, pizza‑sized team can deliver. Resist throwing more people at the schedule-Brooks’s Law still bites. (Wikipedia)
SLA‑backed buy for reliability. If your SLOs can’t tolerate the downtime implied by your in‑house ops maturity, buy a service with the SLA (and credits) you need. (As a reminder: 99.9% ≈ 8.76 hours/year; 99.99% ≈ 52.56 minutes.)
Common failure modes (and how to avoid them)
The Vendor King trap. One suite sprawls across domains and dictates your processes. Antidote: Bounded Buy, capability‑based architecture, and exit clauses. (Thoughtworks)
Customizing a commodity to death. You buy fast, then re‑implement your old world inside the tool. Antidote:Adopt the standard where it’s “good enough,” and isolate your true differentiators for custom build.
Ignoring integration as a first‑class workstream. Tools connect “on paper,” but the domain semantics don’t. Antidote: Own the integration contracts and translators. (martinfowler.com)
Alliance drift. Goals diverge, governance lags, value erodes. Antidote: Quarterly joint reviews with metrics and pre‑agreed exit triggers; JV life is finite. (Harvard Business Review)
Putting it all together in 30 days
Kickoff (1 day): Fill the Canvas with cross‑functional leads.
Market scan (1 week): Demo top vendors; do a rapid risk screening with security & legal.
Proof‑of‑Concept (2 weeks): For BUY/PARTNER, run a bounded PoC; for BUILD, ship the smallest vertical slice.
TCO & sensitivity (2–3 days): Model 3–5 years, stress test with price/usage changes. Include compliance and egress. (Amazon Web Services, Inc.)
Decision & guardrails (1 day): Choose, set exit criteria, and commit.
Final word
You’re not choosing a religion; you’re choosing a risk‑adjusted path to outcomes. Use the decision tree to narrow options, the trade‑offs to illuminate risk, and the one‑page Canvas to make a transparent, defensible call. Then, instrument the decision: measure the outcome you promised, and revisit it. Capabilities evolve; your choice should, too.
If you want, I can tailor the Canvas for your specific domain and plug in example scores based on your constraints and roadmap.