Prototype-in-a-day: the AI-native product discovery loop

Last updated: July 2026

The product discovery loop used to be measured in weeks. A designer would sketch, a product manager would spec, an engineer would build a scaffolded prototype, and by the end of a two-week sprint the team had something a user could click through. The AI-native version compresses that loop to a day — and by day we mean a real working day, not a stretched sprint. Idea in the morning, running prototype by afternoon, first user feedback by end of day. This post is what fits in the day, what does not, where prototype-in-a-day ends and production begins, and the common failure modes when the discipline slips. It is a cluster child of our 70%-AI-generated codebase pillar.

Key takeaways

• Prototype-in-a-day is discovery, not delivery. The prototype exists to test an idea, not to be shipped. Confusing the two produces prototypes that get rushed into production and production systems that get scoped like prototypes.
• The loop has three phases in one day: shape, build, test. Morning shape (spec, sketches, design tokens). Middle build (AI coding agents produce the running prototype). Afternoon test (real user in front of it, learning captured).
• What fits in the day is a single hypothesis, one flow, one persona. Multiple hypotheses do not fit. Prototypes that try to test three flows in one day test none of them well.
• The prototype-to-production gap is real and it is the point. The prototype cheats on the things that make production expensive (auth, edge cases, error states, observability). Naming what it cheats on is what stops the "just ship the prototype" trap.
• The AI stack that makes it possible is small and specific. Design tokens in Figma. A coding agent with access to a starter framework. A test surface the user can hit without deploying. Nothing exotic.

What "a day" actually is

The day is not eight hours of continuous work by one person. It is a specific choreography:

Morning (2 hours) — shape. Product lead frames the hypothesis in one paragraph: "we think X user needs Y capability to accomplish Z." Designer produces enough Figma to specify the surface — one flow, three or four screens, using the existing design tokens. No pixel-perfect polish; enough to be readable by the coding agent and the human reviewer. Product lead lists five specific questions the prototype needs to answer.

Middle (3-4 hours) — build. Design engineer points the coding agent at the Figma frames. The agent produces a running prototype in the team's starter framework (Next.js on Vercel, or the equivalent). The prototype uses fake data, skips real auth, does not persist state across sessions. What matters is that the flow works and the surface looks close enough to the intended experience that a user can react to it. The design engineering pipeline from our sibling post is what makes this possible.

Afternoon (2 hours) — test. Real user (or realistic proxy) sits in front of the prototype for 30-45 minutes. Product lead facilitates, designer observes. The five questions from the morning get answered. The learning is captured in writing before the session ends — because the session is where the loop earns its keep.

End of day — decision. Continue with this direction, pivot to a new hypothesis, or drop the initiative. Whichever it is, the next day starts with clarity that would previously have taken two weeks.

The whole day involves three or four people, but only one of them (the design engineer) is heads-down the whole time. Product and design pair through morning and afternoon, and hand off to the design engineer during the build.

What fits (and what does not)

The single most important discipline is scoping the hypothesis to fit the day.

Fits:

• A new user surface for an existing capability. "What if the checkout flow started with a single question instead of a form?"
• A new capability in a familiar shape. "What if we added a recommendation panel to the product listing?"
• A choice between two design directions on the same problem. Build both, test both, pick one.

Does not fit:

• A whole product. Prototype-in-a-day tests parts. Testing a whole product takes multiple days on multiple parts.
• A capability with real backend logic. If the hypothesis is "does the search algorithm feel right," the prototype needs the search algorithm — which is not a day's work. Scope the hypothesis to something a fake result set can test.
• Anything requiring real user data. The prototype cannot legitimately test on real customer data in a day, and testing on synthetic data invalidates half the learning.

The pattern for scoping down: if the answer to "what will we learn in the afternoon test" is more than two sentences, the hypothesis is too big for a day. Cut it until the answer is two sentences.

The AI stack that makes it work

The tools that show up in a prototype-in-a-day run:

• Figma with the team's design system tokens configured. This is the specification the coding agent reads.
• A coding agent — Claude Code or Cursor Composer per the AI-coding stack post. Cursor for smaller prototypes, Claude Code when the surface spans many files.
• A starter framework the team maintains. Whatever the team ships production with (Next.js, SvelteKit, Remix), but stripped down — no auth, no database wiring, no analytics. The starter exists specifically for prototypes.
• A no-config hosting surface. Vercel preview URLs, Netlify, or the equivalent. The prototype has to be reachable by the user's browser without SSH and without a build pipeline.
• A user-testing surface. Session recording, live share, or in-person. Whichever fits the user; the key is that the observer sees what the user sees.

The stack is deliberately not exotic. Prototype-in-a-day works because the team has practised the choreography, not because they have a novel technology. Teams that try to introduce a new tool during a prototype day burn the day on the tool.

Where the prototype-to-production gap sits

The prototype is designed to cheat on the things that make production expensive. Naming what it cheats on is what stops the "just ship it" trap.

• Authentication. The prototype uses a hardcoded logged-in user or bypasses auth entirely. Production needs real login, session management, and OAuth flows.
• Persistence. The prototype fakes writes. Real writes need database schema, migrations, referential integrity, and backup.
• Error states. The prototype assumes the happy path. Production has to handle network failures, upstream timeouts, validation errors, and user mistakes.
• Observability. The prototype has no metrics, no logs, no error tracking. Production needs all three.
• Edge cases. The prototype handles the median user. Production handles the tail.
• Accessibility. The prototype uses reasonable defaults. Production has to meet the accessibility bar the team commits to.
• Security. The prototype accepts inputs at face value. Production sanitises, authorises, and audits.

Every one of those is a real cost. The prototype's job is to answer whether the idea is worth paying those costs. If the answer is yes, the delivery team picks up the work with the prototype as the specification. If the answer is no, the team saved the delivery cost.

The failure mode is skipping the discipline and letting the prototype become the production system. This is a version of technical debt that a competent product lead can spot in Phase 1 of any engagement. The tell: someone says "the prototype is already working, why don't we just clean it up." The clean-up is where the cost lives, and the clean-up is more expensive than starting over.

The failure modes when the day slips

Three failure modes account for most of the "our prototype day did not work" stories we hear.

Scope creep during the morning. The hypothesis grew from one to three. The morning went from 2 hours to 5 hours. The build phase started at 2pm, not 11am. The user test got moved to tomorrow. The day broke. The fix is a strict two-sentence rule on the hypothesis; if it grows, cut it.

The coding agent got stuck. The prototype needed a component the design system did not have. The AI improvised, made three attempts, none looked right. The design engineer took over and hand-coded. The build took six hours. The fix is to include "if the design system does not have it, we skip that part of the flow" in the day's scope.

The user did not show. No user, no test, no learning. The day produced a prototype with nothing to react to. The fix is to book the user in advance and treat the slot as immovable — the day is shaped around the afternoon, not the other way around.

The teams that get prototype-in-a-day to work reliably do all three things right and treat the choreography as the product. The teams that treat it as an aspiration ship prototypes on some days and lose others to the failure modes above.

What this shifts for the enterprise

Enterprises that adopt prototype-in-a-day as their discovery pattern find three things move:

• Discovery cost drops sharply. A hypothesis that would previously have cost two weeks now costs a day. Portfolios of hypotheses become affordable to test.
• Failure gets cheaper. A discarded hypothesis costs a day, not a sprint. Teams take more risks because the downside is bounded.
• The gap between product and engineering shrinks. The design engineer and the product lead are in the same room all day. The classical hand-off between product spec and engineering scoping compresses to nothing.

The enterprise that has not adopted the pattern in 2026 is running product discovery at 5-10x the cost of a partner that has. Not because the partner is smarter — because the partner has practised the choreography enough times that it happens without ceremony.