# Build, Buy or Partner Analysis Decides whether a capability should be built, bought or obtained through a partner — against criteria the requester set, not criteria the analysis chose once it knew the answer. ## Deliverable One Markdown document, `build-buy-partner.md`, in the structure set out under **Output** below. It takes a scoped capability from **Product Discovery & Scoping**, and its recommendation is a decision worth preserving as a decision record. ## Required inputs - **The capability, scoped** — what it must do, for whom, and the outcome it serves. - **The criteria that decide it, with their weights**, set by the requester: cost, time, control, differentiation, risk, exit — whichever apply here. Without stated criteria, stop. An analysis that picks its own criteria after seeing the options is a justification, not a decision. ## Optional inputs - Candidate vendors or partners already under consideration - Internal capacity and the skills actually available, as stated by the requester - Pricing, quotes or contract terms the requester has obtained - Regulatory, data-residency or procurement constraints - What the capability costs today, if it exists in some form already Absent inputs are recorded as `unknown` against the option they affect. No figure is estimated on the requester's behalf. ## Execution **1 — Establish whether this is differentiating.** A capability customers choose you for is a candidate to build. One they expect to exist and never compare is a candidate to buy. Record which this is and the reasoning: it sets the weight of everything that follows. **2 — Define the three options concretely.** Not `build` but what would be built, by whom, to what scope. Not `buy` but which class of product, and which named candidates if the requester has any. An option that cannot be described cannot be compared. **3 — Cost each option over its life, not at purchase.** Building carries maintenance, support duty and the opportunity cost of the people doing it. Buying carries licence, integration and the price of growth. Partnering carries management overhead and margin. Every figure comes from the requester or a document they supplied; a cost nobody has provided is `unknown` and the option carries it as a risk, never as a number. **4 — Score against the stated criteria.** Use the requester's weights, not a fresh set. Where evidence is missing the cell is `unscored` and is reported as such; it is never filled with a judgement to complete the table. **5 — Cost the exit.** For each option, what leaving it would take: data portability, contract term, switching cost, the code or knowledge that would be lost. The cheapest option to enter is often the most expensive to leave, and that only becomes visible here. **6 — Name what would change the answer.** The specific fact that, if it were different, would flip the recommendation. If no such fact exists the decision is robust; if a small one flips it, the decision is close and is recorded as close. **7 — Recommend, with the case against it.** One recommendation, its reasoning, and the strongest argument against it stated fairly. A recommendation with no stated downside has not been tested. ## Output `build-buy-partner.md`, in this order: - **1. Capability and date** — what is being decided, for whom, and when - **2. Differentiation** — whether this is something to compete on, and the reasoning - **3. Options** — each described concretely enough to be costed - **4. Criteria and weights** — as supplied by the requester, with their source - **5. Cost over life** — per option, each figure with its source, `unknown` where none was supplied - **6. Scoring** — per option per criterion, with the `unscored` cells listed and what would score them - **7. Exit cost** — per option: what leaving would take - **8. Recommendation** — the option, the reasoning, and the strongest case against it - **9. What would change this** — the facts that would flip the recommendation - **10. Missing information** — what could not be established, and who can supply it ## Validation The analysis is ready when all of these hold: - Every criterion in section 4 carries a weight, and the weights came from the requester - Every cost figure in section 5 carries a source, or reads `unknown` - Every option has an exit cost in section 7, including the option to build - Section 8 states a case against its own recommendation - Section 9 is non-empty, or the recommendation is stated as insensitive to any single fact - No vendor, price or capability is asserted that the requester did not supply Fail the run if a figure appears with no source, or if the criteria were set after the options were known. ## Failure handling - **No criteria supplied** — stop. Report that the decision has no basis yet, and hand back the list of criteria the requester must weight. - **No pricing for a bought or partnered option** — score every other criterion, mark cost `unknown`, and state that the recommendation cannot be final until pricing exists. Never model a price. - **Only one option is genuinely available** — say so plainly, document why the others are closed, and record the decision as forced rather than presenting a comparison that was never real. - **The requester wants a particular answer** — run the analysis on the stated criteria regardless. Where the result contradicts the preference, record both, and let the decision record carry the difference. - **Partial material** — analyse what the material supports, mark the rest `INCOMPLETE — pending `, and deliver.