The Prototype Gap

There is a quiet violence we do to early ideas. We civilize them too early.

An idea often begins in a fragile, half-formed state, surfacing in conversation when someone notices a workflow that feels unnecessarily complex, a decision that could be improved, or a tool that seems to be missing. Before it has been shaped or tested in any concrete way, it is already asked to justify itself, to become clear, structured, and respectable.

We ask for a slide,

then an intake form,

then a business case, stakeholder alignment, an estimate, a roadmap, a set of requirements and a place in a backlog.

Each step demands more precision from an idea that no one has made tangible yet. The process creates the appearance of alignment while each person is still agreeing to a different version in their own head.

Eventually, perhaps months later, a first tangible version appears. Someone tries it and immediately says, “Oh. That is not what I meant.”

That moment is usually treated as a change in requirements. More often, it is the first time the team’s requirements have encountered reality. The distance travelled before that reaction is the prototype gap.

Figure 1. The prototype gap is the distance travelled before anyone has something tangible enough to challenge.

Some of the activity in that gap is necessary once an organization decides to build and operate a real system. Production software deserves serious attention to security, data, architecture, integration, reliability and ownership.

The mistake is one of timing. We apply production-level seriousness while we are still trying to discover what the thing should be. We have made an expensive phase out of deciding whether something deserves to become expensive.

A prototype is a way of thinking

We treat a prototype as an early product, which makes it sound like a delivery activity requiring designers, developers, environments, funding and complete requirements. By the time a team receives permission to create one, much of the uncertainty has already hardened into commitments.

Figure 2. “Prototype to Decide,” from the Stanford d.school Design Thinking Bootleg Deck (2018). Illustration by Kim West.

Design researchers use prototypes as generative objects that help people explore a design space. Stanford’s d.school frames prototyping as a way to move from “I wonder” toward “I know.” The purpose is to make something that exposes what the team may be missing.

A learning prototype can contain one workflow, three screens and a fake backend. It can use sample data. Buttons may lead nowhere. Rules can be simulated by a person. A data pipeline might be a small script and a few prepared outputs.

Its job is to provoke an informed reaction.

An idea can feel complete while it remains private, because its missing parts stay invisible. “The user should be able to submit an integration request” sounds clear until someone has to design the form, at which point the team has to answer specific questions:

• Which user?
• What do they know at that point?
• What must come from the instrument owner, the data team or the site?
• Can they save an incomplete request?
• What happens when the instrument is not in the catalog?
• Who decides whether the request is technically feasible?

The prototype may not answer those questions, but it puts them where the uncertainty is discussable. Delaying the prototype therefore delays part of the thinking. We spend weeks improving the description of an idea when we could spend an afternoon discovering where the idea is wrong.

The first artifact has become cheap

For most of software history, the prototype gap had an economic explanation. Turning an idea into software required scarce technical capacity, and even a rough interface might need a designer, a developer, a configured environment and several days of coordination. Words were cheaper, so organizations used them until they were confident enough to pay for code.

That cost structure has changed.

A person who understands a workflow can now use a chat product, a UI generator, a coding agent or a local development environment to produce a clickable interface, a simulated workflow, a sample report or a small working application. The artifact may be incomplete and technically naive. It can still be enough for a user to react to the shape of the idea.

DORA’s 2025 survey of nearly 5,000 technology professionals found that 90 percent were using AI at work and more than 80 percent believed it had increased their productivity. The same research described AI as an amplifier of the surrounding organizational system rather than an independent source of better outcomes. Coding agents lower the activation energy required to begin. Complex work in a mature system still demands context, judgment, verification and integration.

So the first prototype no longer needs to be treated as a small software project. It can be a temporary instrument for learning: approved tools, synthetic or non-sensitive data, deliberately narrow scope, cheap enough to discard.

Its value is not the code it contains. It is the assumptions it exposes.

Requirements are written after contact

Traditional requirements work asks users to translate tacit, contextual and often messy work into precise statements about a system they have never used. They may understand the work deeply without being able to predict every interaction, exception and dependency in an interface that exists only as a conversation.

Requirements also do not pass directly from a stakeholder’s head into a document, because the people conducting the interview help create them. In one study of 30 requirements interviews with a fictional customer, only 30 to 38 percent of the resulting user stories could be fully traced to the customer’s initial ideas. The participants were constructing the requirements, not recording them.

A prototype makes that construction visible by giving everyone the same object to challenge. Instead of asking a stakeholder “should the system support configurable approval routing?”, we show a proposed handoff and watch what happens.

Figure 3. Sharing the prototype gives users somewhere precise to correct the proposed workflow.

The user may say that approvals are rare, that two groups must review in parallel, that the apparent approval is really a technical assessment, or that the decision depends on data the requester does not have.

Researchers studying collaboration across professional groups use the term boundary object for an artifact adaptable to several viewpoints while retaining enough identity to coordinate work. A prototype can play that role between domain experts, users, designers, engineers, data teams and architects. Everyone challenges the same object rather than defending a private interpretation of a document.

This also changes what alignment means. Teams usually try to align before building. A lightweight prototype lets them build just enough for alignment to be grounded in something. People can disagree about something visible. They can locate the precise point of disagreement, compare alternatives, and watch a user perform the task. That is better than unanimous approval of a sentence broad enough to support five interpretations.

In the late 2000s, Eric Ries gave teams a durable model for operating under uncertainty: Build, Measure, Learn. Many large organizations never enter that loop. They remain in an unofficial stage that comes before Build: permission. They explain, align, estimate, prioritize and fund. They try to remove uncertainty before making the object that would reveal it.

The document-first sequence:

Idea → deck → alignment → estimate → funding → backlog → build → first meaningful reaction

The learning-first sequence:

Idea → learning question → rough prototype → reaction → revised workflow → requirements → engineered product

The prototype gap is the missing prequel to Build, Measure, Learn. It is the hesitation before the learning loop begins. Lean Startup taught us to learn faster once building starts. GenAI lets more people start learning before a formal delivery project exists.

The learning question has to stay explicit, or rapid prototyping becomes another form of theatre. A prototype designed to impress accumulates polish. A prototype designed to teach focuses on the smallest uncertain decision.

What are we trying to learn?

• Can the user complete this workflow without asking for help?
• Does this view contain enough information to make the decision?
• Are these categories meaningful to the people who produce the data?
• Will the handoff work inside the real process?

Requirements written after that contact will not be perfect. Perfect requirements do not exist. They will be materially less fictional. They can describe what users tried, where they hesitated, what information was unavailable, which exceptions changed the workflow and which assumptions survived contact with the people doing the work.

Requirements become a record of learning rather than a wish list.

Cheap to try, expensive to trust

A convincing prototype creates its own risk.

Because the interface looks real, people assume the system is nearly finished. A functioning button can conceal missing authorization, incomplete business rules, hard-coded data, absent error handling and an integration that has never been attempted. That misunderstanding has become more common as AI-generated interfaces improve.

There are two versions of this risk, and the second one is why the permission gate exists in the first place.

The technical version is familiar. A production system carries obligations that a learning prototype does not: identity, data contracts, business logic, security, performance, observability, failure recovery, deployment, support and long-term maintenance. It has to work beyond the narrow path used in the demonstration. DORA calls this a workflow gap. AI makes the initial prototype arrive quickly, while precision, edge cases, verification and integration consume most of the remaining effort. Higher adoption can raise throughput and instability at the same time when the surrounding engineering practices are weak.

The political version is harder. A senior stakeholder sees a working demo on Tuesday and asks why it cannot ship on Monday. Nothing in the demo communicates the difference between the happy path and the system. Now the engineering team is negotiating against a screenshot, and the honest answer, that most of the work is still ahead, sounds like resistance.

Organizations built intake forms, business cases and funding gates partly to prevent exactly this. Those controls are a reasonable response to a real failure mode. The argument here is not that they are useless. It is that they are aimed at the wrong stage, and that they are cheaper to apply after first contact than before it.

Which means the practice only works if the prototype’s status is legible in the artifact itself, not just in the presenter’s caveats. Visible watermark. Obvious fake data. A stated expiry. A one-line summary of what has been tested, what is simulated, and what is unknown.

Figure 4. An engineer can test the risky assumptions while the prototype’s visible choices are still easy to change.

The prototype reduces product ambiguity. It does not remove technical complexity. That is why this approach does not diminish the role of engineers. It gives them a better starting point. Domain experts make the desired experience tangible, users validate the workflow, product teams identify which decisions matter, and engineers concentrate on whether the idea can operate safely and reliably in the real environment. They still have to write the difficult logic, connect the backend, model the exceptions, choose the architecture and make the system maintainable. They just begin from requirements shaped by contact rather than speculation.

Engineers should also enter early wherever technical feasibility is itself the risky assumption, before the prototype’s visible choices harden into accidental architecture.

The form of the prototype should match the uncertainty. A visual interface works when the risk concerns interaction or workflow. For a data-heavy product, the first artifact might be a sample data contract, a simulated pipeline or a set of expected outputs. For a service or operating process, a storyboard or a role-play. For an AI system, a small evaluation set and a manually operated version of the experience. Polished screens are useless when the real uncertainty sits in data availability, model behavior or system integration.

Where this does not apply

The learning-first sequence assumes you can put a rough thing in front of a real user this week. In some environments you cannot, and it is worth being honest about which.

If the workflow touches regulated records, validated systems or patient, clinical or personal data, the prototype cannot use the real thing, and a synthetic copy may not exercise the parts that matter. If the uncertainty is the data, and the data is the part you are not allowed to touch, a clickable interface will teach you very little.

If a user’s participation is itself controlled, if you cannot ask a lab analyst to spend twenty minutes on an unvalidated tool without a documented reason, then “put it in front of people who do the work” is a governance question before it is a design one.

If the system of record is the constraint, the honest first prototype is often a data contract or an integration spike, not a screen.

In those cases the response is not to abandon the approach. It is to move the prototype to where the risk actually is, and to accept that first contact may require a narrower audience and a longer lead time. What should not survive is the assumption that a full delivery project is the only path to a first tangible artifact.

A different rhythm of work

1. Start each idea with a learning question.
2. Create the cheapest artifact that lets someone act, decide or react.
3. Use realistic examples and synthetic data. Mark it clearly as non-production. Give it an expiry date and an owner who is accountable for that date.
4. Put it in front of people who perform the work. Watch where they pause, disagree, ask for missing information or invent a workaround.
5. Revise the workflow. Remove what does not matter. Document the assumptions that remain untested.
6. Then write the requirements.
7. Then decide whether the idea deserves real engineering.

Question → Artifact → Contact → Learning → Requirements → Engineering

Step three is the one that fails in practice, so it deserves more than a bullet. An expiry date with no owner is a comment in a README. The prototype that gets used is the one that survives, and the reason it survives is that it is solving a real problem badly while the real system does not exist. Killing it is unpopular precisely when it has proven its value.

Two things make the date real. The first is that the expiry belongs to a named person who has to either extend it in writing or turn the thing off, which forces the decision to be made rather than deferred. The second is that the prototype should be built with a deliberate ceiling: no real credentials, no write access to a system of record, no data that anyone would miss. Not as ceremony, but so that it genuinely cannot be trusted with the work it would otherwise absorb. A prototype that cannot quietly become production does not need to be defended against.

The first artifact should arrive while the idea is still easy to change. That is when criticism is cheapest and curiosity is still stronger than commitment.

This has little to do with reckless speed. Early work and late work require different disciplines. Early work should be rough, reversible and explicit about what it is trying to learn. Late work should be secure, reliable and engineered for its environment. Confusing the two produces the familiar pair of failures: exploration buried under delivery machinery, or experimental code drifting into production. Stage-appropriate seriousness avoids both.

The deeper organizational effect of AI may be that it gives us a new medium for thought. It lowers the cost of admitting “we do not know yet,” because we can make something that helps us find out.

With agentic AI, the first prototype has become cheap enough that the bottleneck has moved. It now sits in permission: permission to create a first version before certainty has been performed.

The next time someone says “we should build a tool for this,” do not begin with the complete requirements.

• Ask what can be made visible this week.
• Ask which uncertainty the artifact should expose.
• Ask who needs to react to it.

Build that much. Observe what happens. Then write the requirements and bring in the engineering team.

They will begin from a shared experience instead of five different systems hiding behind the same sentence.

Sources

• Stanford d.school: Design Thinking Bootleg
• DORA: State of AI-assisted Software Development 2025
• How do requirements evolve during elicitation?
• Institutional Ecology, “Translations” and Boundary Objects
• The Lean Startup Methodology

Figures 1, 3 and 4 generated with GPT Image 2.