Build vs Buy Decision Framework: A Weighted Matrix You Can Copy

Part 2 put a real three- and five-year number on each path, and the number is worth having. But cost decides nothing on its own. A build that runs $2M and a buy that runs $800k are not comparable until you know whether the cheaper one actually does the job you compete on — and a cheap path you outgrow in eighteen months is the most expensive one on the table. Cost is a single input. Fit is the rest, and fit is what this part scores.

The problem is that “fit” is exactly where most build-vs-buy analysis collapses into a prose list of factors to consider. A list doesn’t decide. It lets everyone read their preferred answer into the same paragraph. A build vs buy decision framework replaces the argument with a scored comparison — one that makes the trade-offs explicit, forces you to say what matters and by how much, and leaves a record of why the winner won that you can defend to a board or revisit in a year.

The matrix: ten criteria, weighted to 100

Here is the template. Copy it, adjust the criteria to your situation, and fill the score columns. Weight each criterion by how much it matters to you — the weights must sum to 100 — then score build, buy, and modernize from 1 (poor) to 5 (excellent) on each. Multiply weight by score for every cell, total the columns, and the highest total is your leading candidate.

Criterion	Weight	Build	Buy	Modernize
Strategic differentiation (core vs context)	20
Fit to your actual workflow	15
Time-to-value	15
Total 3-year cost	15
Preserves existing business logic / data	10
Control & data ownership	8
Security & compliance fit (SOC 2, ISO 27001, GDPR/HIPAA)	7
Integration with your stack	5
Reversibility / low lock-in	3
Team capacity to run it	2
Weighted total (÷100)	100

The weights above are a starting distribution, not gospel. They encode a common bias — that differentiation, fit, speed, and cost dominate, and everything else is a tie-breaker — but yours will differ. A regulated insurer weights security and data ownership far higher. A pre-product-market-fit startup weights time-to-value and reversibility over three-year cost, because it cannot see three years out. Recalibrate deliberately, then hold the line, because the moment you start adjusting weights to chase a result the whole exercise turns into theater.

One weight is deliberately low and it matters: reversibility sits at 3. Not because unwinding a wrong choice is cheap — it is often the most expensive thing in the whole decision — but because a static snapshot genuinely can’t score it. Undo-cost is a function of time and how deep the path grows into your business, which a one-shot matrix has no way to see. It gets a token line here and its own treatment in Part 4. Don’t mistake the small number for a small stake.

Weight before you score — the one rule that saves the matrix

The single most common way a decision matrix gets rigged is silent: you score the paths first, notice your preferred option is behind, and then discover that cost “really should” be worth 25 instead of 15 — the exact column your favorite already wins. Now the math endorses the answer you walked in with, dressed as rigor.

Kill this by ordering the steps. Set the weights against strategy, with the scores still blank. Say each weight out loud and defend it — “differentiation is worth 20 because this is the thing customers actually pay us more for” — to someone who will push back. Freeze the weights. Then score. If a frozen weight looks wrong once real scores are in, that’s a signal worth examining — but you change it in the open, with a stated reason, not by quietly nudging until the total flips.

How to score each path 1–5

Scores are judgments, but they should be judgments anchored to something, not vibes. A workable anchor:

• 5 — clearly the best available option on this criterion; hard to beat.
• 4 — strong, with a known, acceptable gap.
• 3 — adequate; does the job with real compromises.
• 2 — weak; a material problem you’d have to actively manage.
• 1 — disqualifying-adjacent on this dimension alone.

Score against evidence you can point to, not intuition. “Buy scores 2 on workflow fit” should trace to a specific demo where the product couldn’t model your approval chain, not a feeling. Where you’re guessing, mark it as a guess and go get the evidence before you commit — a matrix full of confident-looking numbers you invented is more dangerous than no matrix, because it launders a hunch into a decision.

Criterion by criterion: what each row measures, and how the paths typically fare

The rows are not interchangeable, and the tendencies below hold often enough to be a useful prior — but they are a starting point for your own scoring, not a verdict. Score your actual situation; the value is in knowing what the row is really asking before you put a number in it.

Strategic differentiation — core vs context (weight 20). The question underneath every other row: is this capability something your business genuinely competes on, or plumbing everyone in your industry runs? Get this one wrong and the rest of the matrix is precise about the wrong thing. Build and modernize tend to score high on true core because they keep the differentiating logic under your control; buy structurally caps out here, because a product built to sell to your whole industry cannot, by design, encode what makes you different from the rest of it. The trap is inflation — most of what teams call “core” is context wearing a coat of paint. Pressure-test it: if a competitor bought the exact same product, would customers notice? If not, it’s context, and you should be buying.

Fit to your actual workflow (weight 15). Not “does the product have the feature” but “does it match how your people actually work, without bending either the tool or the team past breaking.” Modernize usually wins this by construction — it already fits, because it grew up inside your workflow. Build can score high if you scope it honestly. Buy is where this row bites: a demo always fits; the question is what the product does with your edge cases, your approval chains, your exceptions. Score buy on the gaps you found in a real trial, not the happy path in the sales deck. A low score here on a differentiated function is frequently the whole decision.

Time-to-value (weight 15). How long until the capability is delivering, not delivered. Buy typically leads — a maintained product is live in weeks, not quarters — which is exactly why it’s the right default for context you just need working. Build almost always trails, and teams almost always underestimate by how much. Modernize, done incrementally, can score surprisingly well: proven slices ship every few weeks against a running system, so value arrives continuously rather than at a distant big-bang finish line. Beware scoring build’s time-to-value on the optimistic plan; score it on your team’s actual delivery history.

Total 3-year cost (weight 15). This is the row Part 2 exists to fill — don’t guess it here. Use the TCO worksheet: build’s cost hides in the maintenance tail and opportunity cost; buy’s hides in seat growth, integration, and implementation; modernize’s is incremental spend against an asset you already own. Buy wins this decisively for commodity capability and the gap widens at year five; build only catches up when the capability grows revenue or a bought product needs so much customization its economics collapse. Import the number, don’t invent it — a fabricated cost score corrupts a weight-15 row.

Preserves existing business logic / data (weight 10). Does the path carry forward the accumulated, often-undocumented rules the current system already encodes — every edge case and exception refined over years — or does it force you to rediscover and re-implement them? This is the row that most cleanly separates modernize (which preserves the logic by definition, scoring 5) from build and buy (which both start over and typically score 1–2 for a logic-heavy system). For a genuinely new capability with no existing logic, this row is near-irrelevant and should be weighted down or cut. For a decades-old core system, it is often the row that decides — and the row build-vs-buy analysis most often forgets to include, which is exactly why those projects fail in production.

Control & data ownership (weight 8). How much of your destiny stays in your hands — your code, your data, your ability to change direction without asking permission. Build and modernize score high; it’s your system. Buy scores lower and drops further the deeper the product becomes your system of record. Weight this up in regulated industries and anywhere data residency, auditability, or a hard exit clause is non-negotiable.

Security & compliance fit (weight 7). Whether the path meets your real obligations — SOC 2, ISO 27001, GDPR, HIPAA, sector rules — without a heroic effort. Counterintuitively, buy often scores well here: a mature vendor amortizes a compliance apparatus most in-house teams can’t match or keep current, and ships the certifications with the product. Build carries the full, permanent cost of doing this yourself. Modernize inherits both the strengths and the sins of the existing system, so score it on the system’s actual posture, not its age.

Integration with your stack (weight 5). How cleanly the path connects to everything around it — identity, data, events, the systems it must talk to. Modernize usually integrates best because it’s already wired in. Buy varies enormously: a product with a real API and documented boundaries scores well; a closed one that becomes an integration project of its own scores badly, and that cost belongs partly in the cost row too. Watch for double-counting.

Reversibility / low lock-in (weight 3). How hard the path is to walk back if it’s wrong. Deliberately low-weighted here — not because undo-cost is small, but because a static snapshot genuinely can’t measure it; it’s a function of time and depth that a one-shot score flattens. Give it a placeholder here and let Part 4 price it properly. Modernize done in flag-guarded slices tends to be the most reversible; buy is reversible only if you protected the exit up front; build is reversible in principle but you rarely undo one — you let it rot or absorb it.

Team capacity to run it (weight 2). Can the people you actually have operate and evolve this, or does the choice assume a team you’d need to hire? Buy asks the least; build and modernize both assume durable in-house capability. A low score here doesn’t kill a path, but it does flag a hiring or partner dependency the plan has to name out loud rather than wish away.

Score one function at a time, not the estate

The largest mistake in build-vs-buy isn’t a bad score — it’s running the matrix once for a whole system. A “system” is a bundle of functions, and they are almost never uniformly core or uniformly commodity. Force one verdict on the bundle and you’ll either buy something that can’t do your differentiated part or build something that reinvents your commodity parts. Both are expensive, and both were avoidable.

The distinction that decides which way each function leans is core versus context, Geoffrey Moore’s framing: core is what your business genuinely competes on — the work that, done differently, wins or loses customers. Context is everything else the business needs but nobody wins on: the plumbing every company in your industry runs. You buy context — a maintained product beats bespoke code for undifferentiated work every time. You build or modernize core — because that’s the work you can’t afford to hand to a vendor’s roadmap, and often the work a running system already encodes better than anything you’d start fresh.

So decompose. List the functions of the system — quoting, billing, underwriting, notifications, reporting, identity, whatever they are — and run a short matrix per function. The pattern that emerges is almost always a blend rather than a single answer:

Function              Core / Context    Leaning
──────────────────    ──────────────    ───────────────────
Identity & auth       Context           Buy
Notifications         Context           Buy
Reporting / BI        Context           Buy (or low-code)
Billing               Context-ish       Buy, watch customization
Quoting / pricing     Core              Modernize (logic is the asset)
Underwriting rules    Core              Modernize or build
Customer portal       Context + edge    Buy-then-extend

Drawing that line — function by function, deliberately — is the work. It’s also what turns “we need to replace the system” into a plan that keeps what’s valuable and stops paying to maintain what isn’t.

Notice what the decomposition produces: not one verdict but a portfolio verdict. Buy the commodity edges, build or partner on the genuinely new, modernize the differentiated core — and the seams between them become the integration boundaries of the target architecture. That estate-level blend is almost always stronger than any single path applied wholesale, and it’s the answer you can only reach at the grain of the function. Where the functions map to a known platform or risk profile, the modernization guides turn this blend into a concrete sequence — which slice moves first, which stays, which gets bought around.

When to split the decision instead of forcing one answer

Sometimes even a single function refuses to resolve cleanly, and the honest move is to split it rather than declare a winner by a rounding error. Watch for three tells:

• Two paths tie within the noise. If build and buy land within a few points, the matrix isn’t telling you they’re equal — it’s telling you your criteria don’t distinguish them, or the real deciding factor isn’t in the table (usually reversibility, which is Part 4). Don’t break the tie by adding decimal places. Find the missing criterion.
• The function is 80% commodity, 20% differentiator. This is the classic buy-then-extend shape: license the maintained base for the commodity majority, then build your differentiating slice on its APIs and SDKs, on your side of the boundary. You get the vendor’s upkeep and keep the competitive logic as your own code. The discipline is refusing to bury that logic inside the vendor’s customization layer, where it becomes un-portable.
• Core logic trapped in a dead platform. When the rules are the asset but the platform is a liability, “build” and “buy” both quietly propose throwing the rules away and rediscovering them in production. The split here is to separate the two decisions: modernize by migrating the behavior forward — carrying the encoded logic onto a supportable stack — rather than betting a rebuild can re-earn twenty years of edge cases from scratch.

Splitting isn’t indecision. It’s recognizing that “build vs buy” was the wrong grain, and the right answer lives one level down.

Keep it honest: five rules that stop the matrix rationalizing

A weighted matrix looks objective, which is exactly what makes it dangerous. The numbers can be steered, and a steered matrix is worse than no matrix because it hands a foregone conclusion the authority of arithmetic. Five rules keep it honest:

1. Weight before you score. Covered above, and first because it’s the one that’s violated most and costs the most.
2. A low score on a heavy criterion can be disqualifying on its own. The matrix’s job is to surface a fatal weakness, not average it away. If workflow fit scores a 2 for “buy” and workflow is your differentiator, no cost advantage in the other rows saves it — the total is misleading you. Read the cells, not just the column sum. A 2 on a weight-20 line is a veto to investigate, not a deduction to net out.
3. Assign someone to argue the losing path. Before you commit, have a person whose job is to make the strongest possible case for the option that lost. If the case is easy to make, your scores were soft. This is the cheapest insurance in the whole exercise.
4. Write down the answer you expected — before you run the numbers. Record your prior. If the matrix confirms it, good — but you now can’t tell whether the matrix reasoned or just echoed you, so probe the close calls. If it contradicts you, that’s the high-value outcome: either your instinct was wrong, or a weight is. Both are worth knowing, and neither survives if you never wrote the prior down.
5. Cut criteria that score the same across all paths. A row where build, buy, and modernize all get a 3 changes no total — it only adds the illusion of thoroughness and dilutes the criteria that actually decide. If a line can’t move the answer, it doesn’t belong in the matrix.

None of these are properties the matrix has. They’re disciplines you impose on it. The tool is a structured way to think, not a machine that thinks for you — and its entire value is destroyed the moment it’s used to ratify instead of decide.

Three worked scores, three different answers

The strongest way to see why you score function by function is to watch the same company, on the same afternoon, reach three different right answers for three functions of one system. All figures are illustrative — the point is the shape, not the third decimal. Take the mid-market insurer from the decomposition above and score three of its functions.

Function 1 — the quoting-and-pricing engine (modernize wins)

Pricing logic refined over a decade, a genuine competitive edge, buried in an aging platform. Weights recalibrated to lift preserves existing logic to 12 and trim reversibility to 2, because for this function the encoded rules are the whole game:

Criterion	Weight	Build	Buy	Modernize
Strategic differentiation	20	5	2	5
Fit to your actual workflow	15	4	2	5
Time-to-value	15	2	4	4
Total 3-year cost	15	2	4	3
Preserves existing business logic / data	12	1	1	5
Control & data ownership	8	5	2	5
Security & compliance fit	6	3	4	4
Integration with your stack	5	4	3	5
Reversibility / low lock-in	2	2	3	4
Team capacity to run it	2	2	4	3
Weighted total (÷100)	100	3.09	2.66	4.42

Read the shape. Buy loses not on cost — where it’s strongest — but on the two heavy differentiation rows, because a product built for everyone can’t encode the pricing logic this insurer wins on. Build scores respectably on differentiation and control, then gets gutted by the preserves existing logic row: a rebuild starts from a blank page and has to re-derive a decade of edge cases in production, which is exactly where these projects fail. Modernize wins because it’s the only path that keeps the asset — the encoded rules — while still delivering fit, speed, and control. That’s a result you can take to a board: not “we felt modernize was right,” but “here’s the scored comparison, here’s what each path is strong and weak at, and here’s the row that decided it.”

Function 2 — identity and authentication (buy wins)

Login, SSO, MFA, session management. Nobody has ever bought insurance because a carrier’s auth was special. This is pure context, so the weights shift hard: differentiation and preserves existing logic drop, security and time-to-value rise:

Criterion	Weight	Build	Buy	Modernize
Strategic differentiation	8	2	4	2
Fit to your actual workflow	12	4	4	3
Time-to-value	18	2	5	3
Total 3-year cost	18	2	5	3
Preserves existing business logic / data	3	2	3	4
Control & data ownership	8	5	3	4
Security & compliance fit	20	2	5	3
Integration with your stack	8	3	4	3
Reversibility / low lock-in	3	3	3	3
Team capacity to run it	2	2	5	3
Weighted total (÷100)	100	2.58	4.49	3.03

Buy wins in a walk, and the two heavy rows tell you why: a mature identity vendor ships SOC 2, SSO, and a decade of hardened edge cases you would spend years and a permanent team reproducing. Build here means reinventing commodity infrastructure that mature products do better, cheaper, and more securely, then owning the compliance treadmill forever. Note the differentiation row even tips toward buy: a good identity product is genuinely more capable than what this team would build. Same matrix, same company, opposite verdict — because the function is context, not core.

Function 3 — a real-time fraud-scoring feature (build or partner wins)

A genuinely new capability the insurer wants to compete on: scoring claims for fraud in real time, using signals no product on the market combines the way this team’s actuaries can. There’s no existing system to preserve and no off-the-shelf product that does the specific thing, so differentiation dominates and preserves existing logic is nearly moot:

Criterion	Weight	Build	Buy	Modernize
Strategic differentiation	28	5	2	1
Fit to your actual workflow	15	5	2	1
Time-to-value	12	3	4	1
Total 3-year cost	12	3	3	1
Preserves existing business logic / data	2	3	2	2
Control & data ownership	12	5	2	2
Security & compliance fit	8	3	4	2
Integration with your stack	6	4	3	2
Reversibility / low lock-in	3	3	3	2
Team capacity to run it	2	2	4	2
Weighted total (÷100)	100	4.14	2.61	1.35

Build wins, and modernize correctly craters — there’s nothing to modernize, so it’s the wrong path however you score it, which is itself a useful thing for the matrix to say out loud. The interesting tension is build vs buy: buy leads on time-to-value and team capacity, but gets buried by the weight-28 differentiation row, because a bought fraud product gives you the same edge every competitor can license. If the team can’t staff the build fast enough, this is precisely the score that argues for partner / co-development — keep the differentiating requirements and the ownership, rent the velocity — rather than surrendering the edge to a product just to ship sooner.

Three functions, one system, one afternoon: modernize, buy, build. Force a single estate-wide verdict and at least two of these three come out wrong. That is the entire argument for scoring at the grain of the function.

Where this leads

The matrix scores today’s snapshot — what each path is worth right now, on evidence you can see. What it can’t score is the cost of being wrong: how hard a path is to walk back once you’ve grown into it, and how much optionality each choice quietly spends. That’s a different axis entirely, and it’s the one that turns a good decision into a safe one. Part 4, Build vs Buy: Pricing Reversibility, puts a number on the undo.