An internal pricing application rebuilt as a working, design-system-faithful front end — thirteen numbered builds, driven entirely through Claude, from meeting recordings and Figma exports to code that runs in a browser and behaves like the product. Not linked frames. Real state, real validation, real approval logic, and markup a React team can lift.
Underwriters price pharmacy benefit proposals: load a prospect’s claim file, price it, review the resulting offer, approve it. The existing tool spread that across hand entry, role handoffs, drawers and tabs.
The input was a mess, which is the point. Meeting recordings, call notes, a screen recording of the current tool, screenshots of the existing workspace, brand mockups and Figma exports. No clean specification. That is what a real project looks like before somebody turns it into something.
The output is software. A single HTML file that runs in any browser with no server and no build step, where the queue updates as work happens, files upload and validate, hydration runs, and approval locks and unlocks against real rules.
This is the actual prototype, not a video of one. Open a Ready item to reach the full offer. Open the one marked Needs review to fix a broken claim file and re-check it. Upload any file you like — it accepts them. All figures are illustrative.
The underwriting queue — click to open the running prototype in a new tab
The useful question about an AI-built prototype is not whether it runs. It is whether an engineering team can do anything with it afterwards. This one was written so they can.
All application state lives in a single object — current view, open record, filter, panel, draft edits, unsaved-change guard. Eleven render functions read from it and return markup: the nav, the top bar, the header card, the queue, the intake wizard, the offer body, the slide-over panel. Nothing reads the DOM to decide what to do next.
Those render functions are component boundaries already drawn. Each takes state and returns UI with no hidden dependencies, so porting is mechanical rather than interpretive — the queue renderer becomes a Queue component, the panel renderer becomes a Panel, and the state object becomes a store or a context. The data constants are hoisted out of presentation, so they move as-is.
Twenty-three CSS custom properties carry the navigation plum, the active state, the accent pink, the lilac table headers, the rules, the status greens and the label greys. Every component references them. One token change propagates everywhere, which is why a late instruction like “make every table match the hydrated page” was a single edit rather than a sweep.
The point was a prototype that looks and behaves like the real product, not a generic approximation of it. The design system lives in Figma, so the exports were the bridge.
From image exports, not guesswork.
Tokens and shared render functions.
The step that is not optional.
Four screens, all live in the prototype.
Halfway through, the operating model changed. The original requirements described four specialist roles sharing a queue. A working session replaced that with a single underwriter who owns the record end to end, fed by automated intake.
In a frame-based prototype that is a redraw. Every affected screen, every variant, every prototype link. In practice it is the moment a prototype stops keeping up with the project and quietly becomes a picture of an earlier idea.
Here the rules changed once and the product reflowed. Roles removed, statuses derived differently, intake automated with the manual path demoted to a visible exception, approval re-gated. One build. The previous version was kept intact, so the earlier model can still be opened and compared.
That is the argument for building prototypes as software. Not that it is faster to make, but that it is cheaper to change — and requirements always change.
Speed is only useful if the thing is right. Two layers, and they catch different faults.
Each build was driven in a headless browser: open the page, click the flows, fill the fields, upload files, assert the results. The largest run was sixty-three checks. It caught initialisation-order faults and a deleted helper that would have broken the unsaved-changes dialog — both before anybody saw them.
Three of the six recorded defects were found only because the designer looked at the result and sent a screenshot. Tooltip text overflowing its box. A demo file that could never pass re-check. Mappings from one file silently applying to the next. Tests cannot judge any of those.
Every hand-off listed assumptions, source conflicts and what was not built. It is a prototype: no back end, figures illustrative, mapping suggestions simulated. Saying so is what makes the rest of it credible.
Three things this method is genuinely good for, and one it is not.
Not a clickable picture. A working front end your stakeholders can use with their own inputs, in a browser, in days. Opinions about a mockup are cheap; watching someone actually attempt a task tells you what to fix.
Tokens, a component inventory, the rules written down, test scripts and a version trail. Readable markup with state and accessibility attributes in place, structured so a React team can port it rather than start over.
This is prototype-grade and we say so. No back end, no real data layer, no security review, no performance work. It is the fastest honest way to find out whether the design is right — before anyone spends a quarter building the wrong thing properly.