build-buy-partner

When to use

• A capability gap exists and the question is whether to build internally, buy a vendor / acquisition, or partner.
• An "obviously build" choice has crept in by default; the question is whether it survives a deliberate compare.
• A vendor / partner relationship is up for renewal; the question is whether to keep buying, switch, or insource.
• An acquisition has been floated; the question is whether the integration cost justifies the speed-to-capability.

Do NOT use for vendor selection within a "buy" decision (different skill), market-entry beachhead choice (route to market-entry-analysis (P2)), or scenario-shape comparison (route to scenario-modeling (O4); P1 consumes O4's bundle).

Cognition cluster

• Mental model 28 — Inversion. "What would force us to undo this choice in 18 months?" Inversion surfaces the dependency-risk and integration-cost that the forward case understates. See mental-models.md § 28.
• Mental model 21 — Second-order thinking. Each option chains: build → ongoing maintenance + opportunity cost; buy → integration + lock-in; partner → dependency + boundary management. Single-order "build is cheaper" fails on the second-order. See mental-models.md § 21.
• Mental model 26 — Optionality. Read each option by which choices it preserves (switch costs, re-build optionality, re-negotiation power) vs forecloses. The option with bounded foreclosure usually wins. See mental-models.md § 26.
• Context-spine — org-stage + product + customer-segment. Read org-stage for capacity (pre-seed should buy almost everything non-core; growth-stage can build deeper). Read product for whether the capability is core-differentiation (build) or commodity (buy). Read customer-segment for whether enterprise-segment buyers require a build-it-yourself story.

Procedure

Step 0: Frame the capability as core vs commodity

Two questions:

1. Is this capability a differentiator for our customers? If yes → build-bias. If no → buy-bias.
2. Does it sit on the critical path of our product? If yes + differentiator → build. If yes + commodity → buy. If no → partner.

The matrix is the starting frame, not the answer. Override is allowed but requires writing the override reason.

Step 1: Inventory the three options concretely

Do not compare abstractions. Each option = a concrete plan:

1. Build — named team, named timeline, named ongoing-maintenance cost. "Squad of 3 engineers for 6 months + 1 FTE ongoing" not "we'd build it".
2. Buy — named vendor (or vendor shortlist), named pricing band, named integration scope. "Vendor X at $80k ARR + 4-week integration" not "we'd find a vendor".
3. Partner — named partner, named scope of dependency, named exit clause. "Partner Y owns the X interface with 90-day exit" not "we'd partner".

Un-named options compare to nothing.

Step 1.5: Inspect the differentiator claim

Before locking the matrix from Step 0, inspect the claim that this is or isn't a differentiator. Two questions: "would a customer leave us if a competitor had a better version of this capability?" and "is the current build advantage replicable by a vendor with one quarter of focused work?" Both yes answers → the capability is less of a differentiator than the frame suggested; bias back to buy.

Step 2: Compute integration cost honestly

Integration cost is the most under-counted number. For each option:

1. Build — engineering time + management overhead + opportunity cost (what's the team not building?).
2. Buy — vendor integration (weeks to first value) + ongoing change-management cost + lock-in (cost to switch off).
3. Partner — boundary management + divergence cost (what happens when partner changes their roadmap?).

A buy decision with 2-week integration is rare; industry-typical ranges (public integration benchmarks — not a prediction of your timeline, per direct-answers § no duration estimates) run 4–8 weeks for non-trivial integrations and 3–6 months for enterprise-grade ones.

Step 3: Inversion — name the failure mode for each option

For each option, write the 18-month failure mode:

1. Build fails — "team built the wrong thing because requirements shifted under them" / "team left and knowledge walked".
2. Buy fails — "vendor changed pricing 3×" / "vendor acquired and roadmap diverged" / "vendor sunset the product line".
3. Partner fails — "partner's incentive misaligned" / "partner's customer became our competitor".

If one option's failure mode is "can't think of one", the analysis is incomplete; sit with it longer.

Step 4: Read optionality

For each option:

1. Preserved options — what future choices remain (switch vendor, re-build, deepen the build, expand the partnership).
2. Foreclosed options — what future choices are off the table (re-build after 2 years of vendor lock-in; re-vendor after a build commitment; competing against a former partner).

The decision is rarely about today's cost; it's about which option preserves the choices we'll need in 18 months.

Step 5: Decide and emit the ADR

Pick one. Emit a build-buy-partner ADR via the adr-create skill, citing this skill's output. The ADR is the durable record; the artifacts here are the cognition that justify it.

Related Skills

WHEN to use this

• Insource-vs-outsource-vs-acquire decisions on a capability gap.
• Vendor renewal / re-evaluation where re-building or switching is on the table.

WHEN NOT to use this

• Vendor selection within a locked buy decision — different skill (not in this roadmap).
• Market-entry beachhead choice — route to market-entry-analysis (P2).
• Scenario shape comparison — route to scenario-modeling (O4); P1 consumes O4's scenario-bundle.md.
• Org-shape changes (reorg, team-split) — route to org-design (Q1); P1 composes Q1 for the "build" option's team shape.
• Decision-record authoring mechanics — route to adr-create; P1 emits an ADR via that skill.
• A generic multi-option choice on custom user-weighted criteria (not build/buy/partner-shaped) — route to decision-record § Weighted-matrix mode; this skill stays the domain-specific instance.

When the agent should load this

• "Should we build this or buy a vendor?"
• "Make-vs-buy on capability X."
• "Should we partner with Y or build in-house?"
• "Renew vendor Z or insource?"
• "Bauen wir das selber oder kaufen?"

Output

1. build-buy-partner-frame.md — capability framing (core / commodity, critical-path / not), three concrete options named, integration-cost table per option.
2. failure-modes.md — 18-month inversion per option; named failure paths.
3. optionality-map.md — preserved / foreclosed options per choice; recommended option with reasoning.
4. ADR (via adr-create) — the durable decision record; this skill produces the cognition, adr-create produces the file.

Gotcha

• "Build" defaults are the most common silent choice. Engineers' bias is to build; the absence of a buy / partner option in the inventory is the bug, not a feature.
• Integration cost is under-counted by 2–4× in buy decisions. Always budget the high-end of the band.
• "We'd lose strategic capability" is sometimes true and sometimes a rationalisation. Test against Step 0's differentiator question.
• Acquisitions that look cheap on price are expensive on integration. The integration cost is rarely less than the acquisition cost over 18 months.

Do NOT

• Do NOT compare abstractions; each option must be concrete (named team / vendor / partner).
• Do NOT skip the inversion step — un-stressed options always look attractive.
• Do NOT collapse the three options into "build vs buy" — partner is a distinct option with distinct optionality.

Runnable example

Series-A SaaS, capability gap: real-time data pipeline.

• Step 0 — differentiator (no, every SaaS has one), critical-path (yes). Matrix says buy.
• Step 1 — Build: 3 eng × 6 mo + 1 FTE ongoing ≈ $1.2M / yr. Buy: Confluent at $180k ARR + 4-week integration. Partner: customer's existing pipeline with 90-day exit — but no incentive alignment with our segment.
• Step 1.5 — would customers leave if competitor's pipeline was better? Probably not (commodity layer). Vendor-replicable in one quarter? Yes. Confirms buy-bias.
• Step 2 — Build integration: 6 mo to first value + 3 mo to scale. Buy: 4 weeks to first value, 12 weeks for enterprise-segment readiness ≈ 4 months total. Partner: 2 weeks, but divergence cost unknown.
• Step 3 — Build fails: team-knowledge walks. Buy fails: Confluent re-prices on usage (mitigation: 2-year contract). Partner fails: partner's roadmap diverges (mitigation: thin exit clause).
• Step 4 — Build preserves deep integration optionality (foreclosed by buy). Buy preserves capital optionality (foreclosed by build). Partner preserves nothing of consequence.
• Step 5 — Decide buy. Emit ADR via adr-create citing the matrix verdict + integration-cost band + Confluent-specific lock-in mitigation.