Code-to-Evidence Ladder

Use the Ladder at a Decision Boundary

Open this tool when a result creates pressure to build: a customer asks for an integration, a manual pilot works, a script keeps breaking, or a coded test begins to attract real use. The question is not whether a higher rung would look more complete. It is whether the next decision requires reality that the current rung cannot provide.

Bring the evidence already collected, the decision it must inform, the behavior that would count, and the founder time available to build and support the test.

Scan the Rungs by What They Make Real

Start at the bottom. Stop at the first rung that can produce an honest answer.

1. Conversation makes the person’s present pain, language, alternatives, urgency, and authority available for examination. It cannot show use.
2. Sketch makes objects, sequence, and comprehension visible. It cannot show that the outcome is wanted.
3. Landing page places a promise in a real channel and can ask for a proportionate next step. It cannot show that the product delivers or retains.
4. Manual service delivers the outcome through founder effort. It can expose value and exceptions, but it can hide unsustainable labor.
5. Spreadsheet gives real inputs, calculations, states, and corrections an inspectable shape. It can also conceal fragile assumptions and manual error.
6. No-code workflow makes repeated handoffs and simple automation observable. Vendor state, permissions, and brittle connections arrive with it.
7. Script tests one transformation, import, integration, or repeated operation. It needs representative inputs, visible failures, and a recovery path.
8. Internal tool makes delivery more consistent for the founder. It proves operating leverage only; customer pull still needs its own evidence.
9. Concierge MVP lets customers use a product-shaped service while knowing that people perform some work. It reveals value and service intensity together.
10. Wizard-of-Oz MVP lets customers encounter a product-shaped surface while declared human or manual operations remain behind it. Do not use concealment to misrepresent privacy, safety, review, or capability.
11. Single-feature coded MVP makes one valuable behavior self-serve with real data, permissions, payment, or repeat use where those are part of the question. Its narrowness is a boundary, not an unfinished roadmap.
12. Durable product makes a continuing promise through onboarding, support, recovery, data stewardship, and reliable operation. Build it when reliance is part of the evidence.
13. Scalable system tests whether demonstrated demand can be carried at the required load and reliability. Capacity cannot supply missing demand.

The sequence is not a release plan. Skip rungs when they add no necessary evidence. A script may precede a no-code flow; a real spreadsheet may reveal more than a polished interface filled with sample data. The ladder orders commitment, not prestige.

Write the Climb Before You Build It

Copy this record into the experiment notes:

Decision this evidence will change:
Current rung and evidence already earned:
Missing reality the current rung cannot expose:

Cheapest credible next rung:
Behavior or technical result it will make observable:
Why a cheaper test would require imagination:
What this rung still cannot prove:

New code, data, vendor, security, support, and recovery obligations:
Founder interventions I will record:
Time, money, and customer boundary for this test:

If the result supports the belief, I will:
If it is ambiguous, I will:
If it contradicts the belief, I will descend, change direction, or stop by:

Stay, Climb, or Descend

If “missing reality” can only be filled with more polish, faster, or more product-like, stay where you are. If the participant must imagine the behavior that decides the question, climb only far enough to make that behavior real.

Descend when a higher-rung test reopens a lower-rung question. Refusal to grant data access may call for a trust conversation, not better integration code. Repeated custom work may call for a narrower problem or segment, not more automation. Existing code can remain useful without being allowed to choose the next experiment.

Price the Climb Against the Decision

Suppose two paid customers repeat a manually prepared weekly report and one asks for direct import. The present evidence supports the report’s value. It does not yet show that file preparation prevents continued use.

“Build an accounting integration” is too large to be a rung decision. A credible record might instead name the missing reality as whether automatic arrival changes weekly use. A shared-folder import for two customers over four cycles could answer that with less code, fewer permissions, and an easier exit than a general integration. The founder would still record manual corrections and would not claim evidence about broad demand, self-serve onboarding, or scale.

The record may also show that no climb is needed: if both customers will continue sending exports, ask about payment or repeat use before automating the inconvenience. Or it may show that the founder has stayed too low: if manual preparation causes missed deliveries and inconsistent results, an internal tool may be necessary for honest reliability evidence even though customers never see it.

Read the Result at the Rung Where It Occurred

Do not borrow proof from a more expensive form. Interest in a landing-page promise is not retention. Success delivered by founder judgment is not successful automation. A working transformation is not customer pull. More capacity is not more demand.

Name what the test established, what remains uncertain, and what decision now follows. Then use the MVP Experiment Card if the chosen rung has become a customer-facing MVP experiment. Climb again only when the next missing reality has a name.