A Build-Versus-Buy Decision Sheet You Can Defend

A defensible build-versus-buy decision has five parts: a stated period, weights set before scoring, a score with a written reason in every cell, cost totals from your own sheets, and a dated record naming the trigger for review. Everything else is a conversation that will be repeated in three months with different participants and no memory of the first one.

The sheet below does not tell you what to choose. It makes the choice locatable, which is the achievable goal. When somebody disagrees, they should be able to point at a cell, name the input they would change, and see the verdict move or not move. That is the difference between a decision and an argument.

Why a sheet rather than a discussion

Discussions about building are unusually prone to drift, because both sides are arguing about different things. One person is talking about capability, another about cost, a third about control, and the words used are the same. A sheet forces each concern into its own row, where its weight becomes visible and arguable.

The second reason is durability. Six months later nobody remembers which assumptions carried the decision, so nobody notices when one of them stops being true. A record with inputs printed on it is the only mechanism that catches an expired assumption, and expired assumptions are how sensible decisions become indefensible policies.

The nine criteria

These cover the dimensions that genuinely separate the two routes. Cut any that does not apply to your situation rather than scoring it zero, and add at most one or two that are specific to you. A sheet with twenty rows produces false precision.

• Time to first useful run. How long until the thing is operating with limits, logs and a stop switch, not how long until it works once.
• Total cost over the period. Both sheets, same period, same hourly rate applied to hours on both sides.
• Control over behaviour. Whether you need to change sequencing, sizing or timing in ways a hosted option does not expose.
• Operational load. Hours per month of ownership, including the ones that arrive unscheduled.
• Coverage. The venues and cases you need supported now, plus the ones you can foresee needing.
• Evidence quality. What record each route leaves that you can check independently afterwards.
• Continuity. What happens when the person who understands it is unavailable, or when a vendor changes terms.
• Disclosure. Whether your approach can be described to a third party at all.
• Reversibility. The cost and time of undoing this choice if it turns out wrong.

Choosing weights before scoring

Weights total one hundred and are set before either column is scored. This sequence is not bureaucratic fussiness; it is the entire integrity of the method. Weights chosen after the scores are visible are a conclusion wearing the costume of an input, and everyone reading the sheet later can tell.

Weight setting is also where the real disagreement lives, and it is better to have that argument explicitly. If one person weights control at thirty and another at five, no amount of careful scoring will reconcile them, and discovering that in ten minutes is cheaper than discovering it after a build.

A useful discipline is to write one sentence justifying any weight above fifteen. High weights are claims about what matters most, and a claim that cannot be defended in a sentence is usually a preference that has been promoted quietly.

The scoring matrix

Score each route from one to five per criterion, where five is better. Write a one-line reason in every cell. The reasons are what make the sheet reviewable, and a cell with a score and no reason should be treated as blank.

A worked example with placeholder scores

Everything in this example is illustrative. The weights and scores are placeholders chosen to demonstrate the arithmetic, and they describe no real team, product or situation. Replace every figure before drawing any conclusion.

Test the result before trusting it. Raise the control weight from 10 to 30 and reduce cost to 10, which is what a team building a proprietary approach would legitimately do, and the two totals move much closer. A verdict that survives reasonable weight changes is robust; a verdict that flips on a five-point change was never really produced by the sheet.

Cost is a gate, not a criterion

Cost appears as a row above, which is a compromise for simplicity. In practice it works better as a gate applied before scoring: if one route costs more than the budget over the period, it is out, and the sheet decides between the remaining options on everything else.

The reason is that cost is measured while everything else is judged. A weighted score mixes an arithmetic total with nine subjective ratings and lets the ratings dilute the measurement. Gating first keeps the measured thing decisive and leaves the sheet to do what it is good at, which is comparing things that cannot be added up.

Either way, both totals come from your own sheets rather than from anywhere else. The recurring side comes from your monthly bill and your tracked hours; the rented side comes from the actual charge for the configuration you would actually use. Sizing that configuration properly is its own question, and understanding how much volume a token needs is what stops you pricing a campaign twice the size of the one you intend to run.

Running the sheet

The whole exercise takes an afternoon if the cost sheets already exist and a week if they do not. The sequence matters more than the speed.

1. State the requirement and the period. One sentence for what it must do, one number for how many months. Everything downstream depends on the period.
2. Set the weights. Total one hundred, agreed before any score is written, with a sentence justifying every weight above fifteen.
3. Total both cost sheets. Same period, same rate, hours included on both sides.
4. Score every cell with a reason. Both columns, one to five, one line of justification each.
5. Multiply and total. Then stress the result by changing the two highest weights and seeing whether the verdict holds.
6. Write the record. Inputs, date, verdict, review trigger, stored where the next person will actually find it.

The decision record template

The record is the deliverable. It is short by design, because a long one does not get read and an unread record cannot catch an expired assumption.

DECISION: build or buy
DATE:
REQUIREMENT: one sentence
RUN PERIOD: months
INPUTS USED
  engineer day rate:
  build days to first useful run:
  monthly infrastructure total:
  maintenance hours per month:
  attention hours per month:
  hourly rate applied:
  rented monthly charge:
WEIGHTS: nine criteria, totalling 100
TOTALS: build weighted / buy weighted
VERDICT: chosen route, one sentence why
BLIND SPOTS: what this sheet did not evaluate
REVIEW TRIGGER: named event or date
OWNER: who watches for the trigger

Two fields carry most of the value. Blind spots forces you to name what the sheet ignored, which is where the next surprise will come from. Owner turns the review trigger from an intention into somebody's responsibility, and a trigger without an owner has never once fired on time.

Presenting it to somebody who was not there

Lead with the period and the weights, not with the verdict. Anyone hearing a conclusion first spends the rest of the conversation looking for the flaw that produced it. Anyone hearing the priorities first is usually arguing about weights within a minute, which is exactly the argument worth having.

Expect the objection to be about a single cell, and treat that as success. Change the cell in front of them, recalculate, and show whether the verdict moves. A sheet that survives that treatment is more persuasive than any amount of narrative, and a sheet that collapses under it has told you something useful for free.

Where a criterion depends on a claim about a product rather than about your own team, say so explicitly and score it as unverified until you have run it. Reading the documented behaviour of the platform underneath, such as the reference material at the Solana documentation site, tells you what is protocol-level and true regardless of tooling, which is a useful way to separate a product claim from a chain fact.

The review triggers

Set them at the moment of the decision, because afterwards nobody has the context to know what would matter. Four are worth writing on almost every sheet, plus a calendar date as a backstop in case none of them fires and everybody forgets.

One trigger is external to your team entirely: the platform underneath both routes keeps moving, and it does so on a public schedule. Operational notes such as the Anza operator documentation exist because that surface changes, and a change there can quietly alter the operational load score on the build column without anybody deciding anything.

• The run period changes, in either direction, by more than a third.
• The recurring bill moves materially, including quietly through added line items.
• The person who carries maintenance becomes unavailable or announces they are leaving.
• The capability gap closes or widens, on either side, in a way that would change a score.
• A backstop date, typically two quarters out, at which the sheet is re-run regardless.

The operational side of the decision needs its own periodic look too. Whether the route you chose is still doing what you expected is a measurement question rather than a strategy one, and comparing your own records against what a professional Solana volume bot reports for the same period is a practical way to check that the assumption underneath your verdict still holds.

How these sheets get gamed

Three patterns account for nearly all of it, and all three are detectable by reading the sheet rather than by attending the meeting. Knowing them is what makes a sheet worth producing at all, because a framework that cannot be audited is just a slower opinion.

The first is weights set after scoring, which shows up as a suspiciously decisive result with weights that have no written justification. The second is criteria chosen to favour a route already selected, visible as rows that are unusually specific to one side. The third is scoring a route nobody has run, which is the most common and the easiest to fix: run a small trial and replace the guess with an observation.

Preferring the reversible route

When the totals are close, reversibility decides. Renting first and building later is a cheap sequence: the trial costs a period of charges, produces observed inputs for every guessed cell, and leaves nothing stranded if the answer turns out to be build. The reverse sequence wastes the build and arrives at the same knowledge later.

This is not an argument for renting in general. It is an argument about order under uncertainty, and it stops applying the moment you have real numbers. Once your cost sheets are populated from observation rather than estimate, run the matrix again and follow it wherever it goes, including back to the route the first pass rejected.

The last discipline is the hardest: publish the verdict with its assumptions attached, and revisit it when the trigger fires rather than when somebody complains. A decision that is reviewed on schedule stays a decision. One that is defended past its expiry becomes an identity, and identities are considerably more expensive than either building or buying.

Questions this sheet gets asked