The Code-to-Evidence Ladder

The Integration Request

A solo founder runs a manual service that finds invoice exceptions for small construction firms. Each Monday, a bookkeeper exports invoices and purchase orders. The founder compares them in a spreadsheet and returns a short list: duplicate invoices, totals above the purchase order, missing job codes, and items that need approval.

Two firms ask for the report a second time. One asks, “Can this connect directly to our accounting system?”

The request sounds like permission to build. The founder can already see the work: OAuth, webhooks, background imports, a database, account mapping, retry logic, permissions, an exception dashboard, and alerts. Direct integration would certainly make the service more product-like.

But what would it make less uncertain?

It would not show that the exceptions are worth resolving. Repeated manual use is beginning to answer that. It would not show that the firms will pay; neither has been asked. It would not even remove the hardest work yet, because the founder still decides whether two differently named jobs are the same and whether an overage is harmless or needs review.

The request contains evidence, but not necessarily evidence for an integration. It says the weekly exchange of files is inconvenient. Before accepting a large technical commitment, the founder needs to know whether that inconvenience prevents continued use or merely makes the service feel unfinished.

This is the work of the code-to-evidence ladder: not avoiding code, but making each increase in implementation answer for itself.

A Ladder of Commitments

The familiar rungs run from conversation, sketch, and landing page through manual service, spreadsheet, no-code workflow, script, and internal tool; then through concierge and Wizard-of-Oz experiences to a single-feature coded MVP, a durable product, and eventually a scalable system.

They are not a release plan. Few products need every rung, and their order is not universal. A script may be cheaper than a no-code workflow for one founder. A spreadsheet using real customer data may produce stronger evidence than a polished interface filled with sample data. A landing page can test interest before a manual service, but it cannot sit “above” a conversation and make that conversation more true.

Treat the ladder as a map of commitments. Near the bottom, artifacts are cheap to discard and users must imagine more. Higher up, users can behave in a more realistic system, but the founder acquires code, data, vendors, support paths, security exposure, and promises of continuity. The useful direction is toward more realism, not toward more prestige.

The lowest group tests claims and shapes. Conversations reveal present pain, alternatives, urgency, authority, and the language people use. Sketches reveal whether the founder understands the objects and sequence of the work. Landing pages reveal whether a particular promise earns a credible next action from a reachable audience. None can demonstrate repeated product use.

The middle group puts real work behind a deliberately thin surface. A manual service can reveal whether an outcome matters. A spreadsheet can expose data shape, states, exceptions, and calculations. No-code workflows can connect repeated steps. Scripts can isolate transformations, imports, or integrations. Internal tools can help the founder deliver the service consistently. These forms often produce excellent workflow evidence, but founder judgment and effort may still be carrying the result.

Product-shaped experiments let the user encounter more of the proposed experience. In a concierge product, the human work is visible; in a Wizard-of-Oz product, some of it is hidden so the interaction can be observed with greater realism. A narrow coded MVP lets users perform one valuable behavior with real data and less founder mediation. These experiments can reveal adoption, trust, recovery needs, and repeat use, but they do not prove a broad product or an economical operation by themselves.

A durable product makes a stronger promise. Payment, onboarding, support, data stewardship, failure recovery, and continued use must hold together. A scalable system adds capacity and operating discipline only where actual growth, reliability, security, or performance demands it. Scale is evidence about the system’s ability to carry load. It is not retroactive evidence that the product deserved to exist.

Find the Missing Reality

Choosing a rung begins with a decision, not an artifact. “Should I build the integration?” is already too committed. A more useful question is, “What must I learn before I decide whether direct import deserves a place in this product?”

Work through five questions:

1. What decision will the evidence change?
2. What observed behavior or technical fact would make that decision less speculative?
3. Why can the current rung not produce it honestly?
4. What is the smallest addition of reality that can?
5. What obligations arrive with that addition?

The third question is the hinge. If the founder cannot say why the current test has run out of truth, climbing is usually an act of hope. “It will feel real” is not an evidence gap. “Bookkeepers abandon the weekly report because preparing the export takes forty minutes and requires administrator access” is one. So is “the matching rules fail on the range of invoice formats used by paying pilots.” Each names reality that a cheaper test can no longer supply.

Sometimes the missing reality belongs to the customer: payment, repeated use, permission to access data, trust in an output, or adoption by a second operator. Sometimes it belongs to the mechanism: whether an import is possible, whether a transformation is accurate enough for human review, or whether a workflow can recover from missing input. The next rung should expose that missing reality and as little else as possible.

Follow One Climb

The invoice-exception founder begins below the level of code. Conversations with bookkeepers reveal that the painful moment is not entering every invoice. It is the Monday review of items that cannot be approved cleanly. A sketch of the report changes the founder’s model: bookkeepers want exceptions grouped by job, with the relevant purchase order beside each invoice. The founder had expected a vendor-centered view.

The first manual reports answer a value question. Bookkeepers correct several job mappings, dismiss harmless overages, and send the remaining exceptions to project managers. Two request another report. This is useful behavior, but it says nothing about whether the founder can produce the report reliably across firms.

A spreadsheet is the right next commitment. It makes joins, thresholds, review states, and unresolved mappings visible without pretending the model is stable. After three weeks, the spreadsheet reveals that the repeated work is not the comparison itself. It is normalizing job identifiers across purchase-order and invoice exports.

Now a script has a specific job. It parses two known export formats, normalizes obvious identifier differences, and marks uncertain matches for review. The founder keeps the spreadsheet as the review surface. There is still no user-facing application.

The script earns its keep by reducing transcription errors and making failures inspectable. It also produces unwelcome evidence: one firm’s “CSV export” changes columns depending on which bookkeeper runs it, and another includes credit notes as positive invoices. The founder has learned something code was needed to reveal. Building a general accounting integration would not have made that learning cheaper.

When a third firm begins a paid pilot, scattered files and per-customer scripts become an operating risk. An internal tool now earns a place. It records import runs, preserves the source file, shows uncertain matches, and produces the same reviewable exception report. The founder is building for reliable delivery, not asking customers to self-serve.

Only after firms repeat the workflow, pay for it, and identify file preparation as the main barrier does direct import become a live product question. Even then, the smallest honest climb may be a scheduled upload from one storage location rather than a broad accounting integration. That narrower path can test whether automatic arrival changes weekly use while the founder still reviews uncertain matches.

If customers begin relying on the report without reminders, need another bookkeeper to review it, and expect access to prior decisions, a single-feature product has been earned. Authentication, roles, history, recovery, and support are no longer ornamental infrastructure. They are part of the evidence because their absence prevents honest use.

The sequence is not impressive. That is its strength. Every implementation exists because the previous one exposed a question it could not answer.

Do Not Borrow Proof from Another Rung

The ladder is most useful when it prevents category errors.

A conversation can establish pain and context; it cannot establish adoption. A landing-page response can establish interest in a promise; it cannot establish that the promised outcome works. A manual service can establish that an outcome is useful when a human delivers it; it cannot establish software margins. A script can establish that a transformation works on representative inputs; it cannot establish customer pull. A coded MVP can establish use of one product behavior; it cannot establish the need for a platform. A scalable system can survive more load; it cannot prove demand.

These limits do not make lower rungs weak. They make evidence legible. The invoice script is strong evidence about parsing and matching, even if no customer ever sees it. The paid manual reports are strong evidence about value, even if the founder cannot yet deliver them economically. Trouble begins when the founder combines those two facts and claims to have proved an automated business.

Name each result at the level where it occurred. This preserves the next uncertainty instead of burying it under progress language.

Climb When Behavior Needs More Reality

A higher rung is justified when users are being asked to imagine the part that matters. A sketch cannot reveal whether a bookkeeper will trust an exception produced from their own records. A sample report cannot reveal whether preparing the input breaks the weekly rhythm. A one-time manual delivery cannot reveal repeat use.

Climb when the behavior must occur across its natural interval, when trust depends on real permissions or data, when hidden manual judgment may be creating the outcome, when a technical constraint determines whether the promise is feasible, or when support and recovery have become part of the user’s decision to rely on the product.

The climb should be narrow. Add the permission, import, review step, persistence, or automation needed to close the evidence gap. Do not use one legitimate need for realism to smuggle in the imagined product around it.

There is also a point at which staying low becomes its own avoidance. More conversations will not reveal whether users return. Another spreadsheet will not reveal whether a self-serve workflow is comprehensible. Manual delivery cannot reveal sustainable founder burden if every customer receives private heroics. Frugality serves learning only while the cheaper artifact can still produce the required truth.

Descend When the Question Changes

Evidence can send the founder down as well as up.

Suppose the construction firms like the exception report but will not grant ongoing data access. The next question is not how to perfect OAuth. The founder needs to learn whether the refusal comes from trust, permissions, a weak economic case, or the wrong buyer. That work belongs in conversations, a security note, a revised offer, or another manual pilot.

Descend when users do not understand the promise, when the objects and workflow change after every customer, when payment resistance concerns urgency or authority, or when support reveals that every successful use depends on custom work. Descend, too, when a product test contradicts the segment or job that justified it.

Climbing down does not erase what has been built. It refuses to let existing code dictate the next question. The founder may keep an internal tool while returning to buyer discovery, or use a script during a new manual test. The ladder describes the cost of obtaining evidence, not a rule that every artifact must be discarded in reverse order.

Price the Commitment Before You Make It

The visible cost of a climb is build time. The more consequential cost is obligation.

A spreadsheet asks the founder to remember its assumptions. A no-code workflow adds vendor state and permissions. A script needs representative fixtures, failure handling, and someone who can understand it later. An internal tool begins to hold customer data. A product-facing integration creates expectations about continuity, recovery, security, and support. Once customers organize work around a system, changing it is no longer a private refactor.

Effort also creates attachment. After four weeks of building, ambiguous evidence becomes easier to explain away: the audience was wrong, the demo needs polish, one more feature will make the value clear. This is a normal consequence of sunk effort, which is why the trade should be written before the work begins.

Use a short climb note:

Decision
What will I decide after this test?

Evidence gap
What must happen in reality that the current artifact cannot reveal?

Smallest climb
What implementation adds only that missing reality?

New obligations
What code, data, vendors, promises, support, security, and recovery work arrive?

Interpretation
What result means climb, remain here, descend, change direction, or stop?

For the invoice product, “build an accounting integration” is too large to fit honestly in the note. “Test whether automatic arrival produces four consecutive weekly reviews without founder reminders for two paid firms” can be challenged. The founder can then ask whether a shared-folder import, forwarded email, scheduled export, or direct API connection is the cheapest credible test.

Before opening the editor, say what would be lost by staying at the current rung. If the answer is only polish, speed, or the feeling of progress, stay. If the missing realism prevents the user or system from behaving honestly, climb—but take only the next commitment.

The invoice founder does not reject the integration request. The founder makes it wait for a better question. Code arrives when it can turn uncertainty into evidence, and no earlier than that.