Past code-backed. The prototype is the code.

UXPin deserves credit for naming the real problem years before AI made it fashionable: prototypes lie when they are built from drawings. Merge attacks that by rendering production components inside the design tool, so what stakeholders click is visually and behaviorally honest.

But a Merge prototype is still an arrangement inside a proprietary editor. The assembled screen is not an application; engineering still rebuilds the composition, the flows, and the glue. Prototyper closes that remaining gap. The canvas holds an actual React codebase, the screens on it are that codebase running, and shipping means continuing the code, not translating a simulation of it. In that sense this is the bet UXPin made, carried to its conclusion.

UXPin is a power tool, and interaction logic with variables and conditions is a skill worth respect. It is also hand work: someone builds every state, wires every condition, and maintains the prototype as the idea changes.

On Prototyper the assembly is delegated. You put the intent on the canvas, a sketch, a sticky, a sentence, and your agent constructs the working screen, states and logic included. Revision is a note, not an evening. Your hours go to judging the result rather than wiring it.

That matters most while the idea is still moving. Early product work changes daily, and a prototype that costs hours to rewire becomes an argument against changing it. When revision is cheap, the prototype stays honest to the current thinking instead of the thinking from last Tuesday.

Code-backed design has an operational cost that shows up after the demo: engineering connects the component library, keeps it synced, and owns the pipeline when it breaks. For teams with a staffed design system, that investment can be worth it. For everyone else it is the reason the rollout stalls.

Prototyper skips the pipeline. Bring your components and tokens into the workspace and the agent composes with them directly, because it is writing real code against real files. There is no bridge between the design tool and the codebase to maintain, since there is no gap between them.

The end of a UXPin project is a specification with excellent evidence: a high-fidelity simulation, documentation, and honest components. Engineering still starts a build, translating composition and logic into an application, and the prototype retires once the product exists.

The end of a Prototyper project is a codebase. The screens the team tested are React files an engineer, or the same agent, continues directly: wiring real data sources, hardening the edges, deploying. The handover meeting becomes a code review, and estimates get easier because they start from working software rather than a picture of intent. Nothing is thrown away at the moment of success, which changes the economics of prototyping deeply enough that it stops feeling like a separate phase.

If your organization needs governed design system documentation with usage rules and long-lived component specs, UXPin has tooling built for that discipline, and it is ahead of ours today. Enterprise teams that live inside that workflow have real reasons to stay.

The seat Prototyper claims is the making: going from an idea to a working, testable, shippable product on one surface, with your agent doing the construction and your team steering in multiplayer. If prototypes at your company exist to become products, that is the difference that compounds.

Teams deep in a Merge deployment do not need to unwind it to try this. Pick one upcoming feature, brief it on a Prototyper canvas, and let the agent build it with your existing component names and tokens. For a fair test, pick something with real interaction rather than a static page. Then compare the path from idea to user test against your current cycle, and compare what engineering inherits at the end.

There is no prototype import; the idea travels, not the file. Paste screenshots of the current prototype into the brief and the agent rebuilds it as a running app, usually inside a working session. Design system documentation can stay wherever it lives today, and nothing about the trial commits you to moving it.