Here is the one-page memo template I use to make build-vs-buy decisions defensible to a board. Not defensible as in politically safe — defensible as in intellectually honest, structurally sound, and reproducible under scrutiny six months later when something has gone wrong and everyone wants to know why you decided what you decided.
Most build-vs-buy analyses I encounter are not analyses. They are conclusions dressed up as analysis. The engineering team wants to build because building is interesting. The CFO wants to buy because CAPEX converts to OPEX. The CEO has a relationship with a vendor who pitched them at a conference. Everyone frames their preference as a reasoned position and hopes nobody asks too hard.
The memo structure below makes that kind of motivated reasoning difficult. It forces the decision-maker to answer specific questions with specific numbers — and to be explicit about the assumptions that would make the decision wrong.
Why Most Build-vs-Buy Decisions Are Made Badly
The root cause is a mismatch between who owns the decision and who has the information to make it. Engineering has the build cost data; they rarely have the full vendor contract picture. Procurement has the vendor pricing; they rarely have the integration complexity picture. Finance has the budget model; they rarely have the strategic roadmap picture.
The typical output of this fragmentation is a decision that optimises on the most visible cost (licence fee vs. build sprint estimate) while leaving the largest costs unexamined (integration, ongoing maintenance, organisational lock-in, switching costs).
The memo structure I use forces every relevant cost and assumption into a single document that can be reviewed by everyone in the room at the same time.
The question that almost always goes unasked
Build-vs-buy is actually three decisions nested together: whether to build or buy now, which vendor or approach to choose if buying, and what the exit strategy is if the decision turns out to be wrong. Most organisations only explicitly answer the first. The second and third are left implicit — which is exactly how you end up locked into a vendor that has tripled its pricing in year three.
The Memo Structure
The memo has six sections. Each has a hard constraint: no section exceeds one short paragraph plus a supporting number or table. If you cannot explain your position on a build-vs-buy dimension in a paragraph, you don't yet understand it well enough to make the decision.
Section 1: The Decision Statement
One sentence. "We are deciding whether to build [specific capability] in-house or purchase [specific product/capability category] from a third-party vendor."
The specificity matters. "We are deciding whether to build or buy our data platform" is not a decision statement — it is an area of concern. "We are deciding whether to build a real-time customer event ingestion pipeline in-house or purchase a managed streaming solution from Confluent, Redpanda, or AWS MSK" is a decision statement.
If you cannot write a specific decision statement, you are not yet ready to make the decision. Go back and scope it.
Section 2: Strategic Fit Assessment
Two questions, answered explicitly:
Is this capability core to our competitive differentiation? If yes, there is a strong presumption toward building — owning and evolving the capability is part of the value proposition. If no, the presumption shifts toward buying — you want to focus engineering investment on what makes you different, not what keeps the lights on.
Does this capability need to evolve with our unique business logic? Generic CRM, generic analytics, generic alerting — these almost never need bespoke evolution. Custom pricing engines, unique risk models, proprietary allocation logic — these often do.
The strategic fit assessment sets the direction. Everything after it is a stress test of that direction.
Section 3: Total Cost of Ownership Over 3 Years
This is where most build-vs-buy memos fail. They compare the licence fee against an engineering estimate, and call it TCO. That is not TCO.
Real TCO for a build decision includes: initial engineering cost (including product, QA, and documentation, not just developer time), ongoing maintenance (typically 20–30% of initial build cost per year), infrastructure cost, incident response overhead, and the opportunity cost of engineering capacity consumed — what does not get built because this gets built instead.
Real TCO for a buy decision includes: licence or SaaS fee (at realistic growth tiers, not the introductory rate), implementation and integration cost (routinely 0.5–2x the first year licence fee), internal engineering time for customisation and maintenance of the integration, data migration and transition cost, and the cost of switching if the vendor relationship ends.
| Cost Category | Build (3-Year Estimate) | Buy (3-Year Estimate) |
|---|---|---|
| Initial build / implementation | €[X] | €[integration cost] |
| Licence / SaaS fees (at growth tier) | — | €[Y × 3, with tier assumption] |
| Annual maintenance / integration upkeep | €[20–30% of build × 2 yrs] | €[Z per year × 2 yrs] |
| Infrastructure (compute, storage, egress) | €[A] | €[included / separate] |
| Engineering opportunity cost | [N sprints × €/sprint] | [M sprints × €/sprint] |
| Exit / migration cost (if wrong) | Medium | €[switching cost estimate] |
| 3-Year Total | €[Build Total] | €[Buy Total] |
Fill this table with real numbers. Ranges are acceptable; blank cells are not. If a cell is blank, it means you don't know — and not knowing is a risk that should be named explicitly.
Section 4: Risk Register
Four risks, maximum. Two for each option. Format: the risk, the probability (high/medium/low), the impact (high/medium/low), and the mitigation.
For build: the most common risks are underestimated complexity (medium-to-high probability, high impact — mitigated by a detailed technical spike and external code review before commitment), and engineer attrition creating a key-person dependency on the built system (medium probability, medium impact — mitigated by documentation requirements and pair development practices).
For buy: the most common risks are vendor pricing leverage increase at renewal (medium-to-high probability for SaaS in growth markets, medium-to-high impact — mitigated by contractual caps or multi-year pricing lock), and capability gaps that the vendor roadmap does not close in time (medium probability, high impact — mitigated by a detailed requirements validation with the vendor's engineering team before signing).
The risk nobody puts in the table
The risk that deserves its own row and almost never gets it: the risk of the decision being wrong and the cost of reversing it. What does it cost, in engineering time and operational disruption, to migrate off the built system onto a vendor product in 18 months? What does it cost to exit the vendor and build in-house after 18 months of the integration being live? These are the switching cost estimates. They belong in the risk register because they set the stakes of the decision.
Section 5: The Recommendation and the Assumption That Would Change It
One paragraph: the recommendation and the primary rationale. Then one sentence: "This recommendation would change if [specific assumption] turns out to be wrong."
The conditional is the most important sentence in the memo. It names the load-bearing assumption — the thing the whole analysis rests on — and makes it explicit so that everyone in the room knows what to monitor.
Examples of good conditionals:
- "This recommendation to buy would change if the vendor cannot demonstrate data residency compliance in the EU within Q3, since that is a hard requirement for our German enterprise pipeline."
- "This recommendation to build would change if the engineering estimate exceeds 8 sprints of capacity after the technical spike, since that would shift the 3-year TCO calculation materially in favour of a managed solution."
- "This recommendation holds unless we exceed 50,000 daily active users within 12 months, at which point the vendor's growth tier pricing makes the buy option cost-equivalent to the build option."
Section 6: The Decision Owner and the Review Date
Name one person who owns this decision and is accountable for monitoring the conditional assumption. Set a review date — typically 6 months out — at which the assumption is explicitly re-evaluated. This is not bureaucracy. This is the mechanism that prevents a build-vs-buy decision from calcifying into received wisdom long after the assumptions that justified it have changed.
How to Use the Memo in a Board or Exec Context
The memo is designed to be distributed 48 hours before the meeting, reviewed independently, and discussed for no more than 20 minutes. The first ten minutes are for questions on the TCO table — the numbers are where most meaningful scrutiny lands. The second ten minutes are for the risk register and the conditional.
If the memo is well-constructed, the board rarely needs to overturn the recommendation. They may ask for a specific assumption to be validated before final sign-off. They may expand the risk register with something you missed. They may flag that the strategic fit assessment needs revision given a business development conversation that engineering wasn't aware of. These are all good outcomes — the memo is working.
What it prevents is a 90-minute discussion that ends without a documented decision, or a decision that gets made based on the most persuasive presenter in the room rather than the most rigorous analysis.
| What the Memo Prevents | What the Memo Produces |
|---|---|
| Undisclosed assumption-shopping | Explicit load-bearing assumptions, visible to all |
| Licence-fee-only cost comparison | Full 3-year TCO including switching costs |
| Advocacy disguised as analysis | Three-year cost model with named uncertainty |
| Decision without an owner | Named decision owner and review date |
| Strategic drift on core capabilities | Explicit strategic fit test before cost analysis |
| Irreversible commitment by default | Named exit cost and reversal condition |
The Discipline Is the Point
The memo template is not magic. A team determined to reach a predetermined conclusion can fill it with biased numbers. What the structure does is make that bias legible — to the board, to the investors, and to your future self reviewing the decision in 18 months.
In my experience, the discipline of filling out the memo honestly changes the recommendation roughly one-third of the time. Teams that started convinced they should build discover that the opportunity cost makes buy clearly preferable. Teams that assumed they should buy discover that the integration complexity puts the total 3-year cost above the build option at their growth rate. That one-third reconsideration rate is worth every hour of work the memo requires.
The other two-thirds? Their decisions are now documented, reasoned, and defensible — which is the thing you need when the decision turns out to be harder than anyone expected.
If you're navigating a build-vs-buy decision that is either stuck or heading toward the board without a credible analysis behind it, let's talk. A 30-minute discovery call is enough to sharpen the frame and identify the numbers that will determine the decision.