Score build vs buy on evidence you can show.

The debate starts before the evidence

Someone says build. Someone else says buy. A third person wants a hybrid that is really buy with a custom shell. The meeting ends with a feeling and a next step that looks like research. Nobody left with a shared list of what must be true for either path to work.

The feeling is usually about control, speed, or cost. Those matter. They are not the decision. The decision is whether a named job can run in production with an owner for the ordinary path and an owner for the failure. Vendors demo the ordinary path. Internal teams sketch the ordinary path. The worksheet exists so the failure path gets a line before anyone commits calendar or capital.

This note is the TWIMCO Build-vs-Buy Decision Worksheet: one page for one job, filled from evidence you can point at, not from a preference you already held walking in. There is no published generator for this sheet. Copy the fields. Fill them in the room with the people who will live with the answer.

Prefer a service conversation over a forced case-study aside. If the job is a durable application someone has to operate—not a slide—start with web applications. The worksheet is the brief you bring to that conversation, whether the answer turns out to be buy, build, or a bounded mix.

Bring one real job. Not a platform tour. Not "our CRM." A job with a trigger, a record that must be true afterward, and a person who notices when it is wrong. If you cannot name that job in a sentence, you are not ready to score build versus buy. You are ready to argue about slogans.

What the worksheet forces you to name

Fill one worksheet per job. A product with twenty jobs does not get one vague sheet. Start with the job that hurts when it fails quietly.

Job. Name it in operator language: create a fulfillment, verify a disclosure, issue a refund approval, sync a status. If two teams use different names, write both.

System of record. Which store is allowed to say the job finished? A green banner is not the record. The worksheet names the record an operator opens when trust breaks.

Must-be-true after success. The facts that have to exist when the job is done: identifiers, states, side effects that are in scope. Leave side effects that are out of scope on a separate line. A buy that protects the row and not the email is still a partial answer.

Must-not-happen. The doubles, silent merges, and unauthorized writes that make this job expensive. Do not invent rates. Write the failure modes you already know from operations, or write "not yet observed, but unacceptable if it happens."

Buy evidence. What the vendor can show for this job: a walkthrough on your data shape, a replay, an audit of who acted, a recovery path. "Roadmap" is not evidence. "Similar customer" is not evidence unless you saw the same job.

Build evidence. What you would own: the people who design, ship, and on-call the job; the systems it touches; the time to a first honest production path. Do not invent a delivery date. Write the ownership you actually have, or "ownership not assigned."

Failure owner. The role who may decide the job failed, who may compensate, and who may change the rule next time. Same role on both paths, or an explicit split with a handoff. "We'll figure it out" fails the line.

Exit or change rule. For buy: how you leave or narrow scope if the vendor cannot show the job. For build: what would make you stop building and buy instead. Without that line, every preference hardens into a sunk cost.

That field set is the TWIMCO Build-vs-Buy Decision Worksheet. Another studio can tell you to weigh total cost of ownership. They do not have this field set, your filled lines, or the evidence rule below.

Score evidence, not preference

Score four lines 0, 1, or 2. This is a planning default for a decision meeting, not a certification and not a measured quality score.

Job clarity. 0 means the job is a slogan. 1 means it is named and the record is fuzzy. 2 means trigger, record, must-be-true, and must-not-happen are written and agreed by the people who operate it.

Buy evidence shown. 0 means a deck. 1 means a demo on a pristine tenant. 2 means the named job walked on data shaped like yours, including one failure or recovery the vendor did not script first.

Build ownership shown. 0 means "engineering will handle it." 1 means a team is named and capacity is assumed. 2 means named people, named systems, and an on-call or recovery duty that already exists or is funded before the build starts.

Failure owner shown. 0 means chat. 1 means a queue without authority. 2 means a role who can see the bad state and is allowed to compensate or reverse without inventing policy in the moment.

Pass rule. Pass only when no line is 0, Job clarity is 2, and Failure owner is 2. Conditional means no zeros but Build or Buy evidence is still a 1: a dated follow-up owned by a named buyer or builder. Fail means any zero. Do not average a charming demo over a missing failure owner. If leadership wants a total, sum the four lines and still refuse a zero.

Prefer two scorers: one who will operate the job, one who will pay for the path. Where they disagree, keep the lower score until the evidence is replayed. "We always build core" is not a 2. "Everyone buys this category" is not a 2. A preference dressed as strategy still needs the failure owner line.

Where build-vs-buy usually breaks

Most bad decisions are unfinished sentences, not exotic strategy failures.

The job was never one job. "Replace the portal" hid create, approve, notify, and reconcile. The worksheet split would have shown that buy covered create and notify while approve stayed with a person who had no queue.

The vendor showed a different tenant. Your statuses, permissions, and exception paths were waved away as configuration. Buy evidence stayed at 1 until someone walked the job you actually run.

The build plan named a squad and not a recovery duty. The product would ship. The 2 a.m. owner would not. Build ownership stayed incomplete on purpose until that line was funded.

The hybrid was buy plus "just a thin layer," and the thin layer became the system of record. Nobody wrote which store wins when the vendor and the layer disagree. The failure owner line is where that fight belongs—before the layer is charming.

When you fill these from a sitting, mark evidence: a recording, a ticket, a named owner, or "not shown." Do not upgrade "not shown" because the roadmap slide was confident. These patterns are delivery-shaped composites from buying and building work, not client telemetry and not a claim about any vendor's defect rate. Use them to recognize a story. Do not publish them as measurements.

Put this into practice

1. Pick one job that must not fail quietly. Put that name at the top of the TWIMCO Build-vs-Buy Decision Worksheet.
2. Fill record, must-be-true, must-not-happen, buy evidence, build evidence, failure owner, and exit rule. Unknown stays unknown.
3. Score the four lines the same day. Apply the pass rule before anyone books a kickoff.
4. Keep the worksheet with the decision memo. Re-open it when a vendor release or an internal milestone claims the job changed.
5. If the gap is a durable application someone has to operate—with clear ownership and recovery—bring the sheet into a scoping conversation for web applications.

A preference is cheap. A production job with no failure owner is not.

Related work: Sutton|Place.