For the PM whose prototype keeps failing the ‘but it’s not our product’ test. What changes when the code runs on the frontend your team shipped.
The prototype looked right on the PM’s laptop. The customer signed off. Engineering opened the file, looked at a design system rebuilt from screenshots, and started the whole thing over from the real components. The prototype was a sketch. The product is the rebuild.
TL;DR
Sandbox prototyping tools generate code against a copy of your design system. The result looks close but isn’t your product – which is why every customer demo from one of these tools risks the “kinda right” verdict and every PR engineering writes is a rebuild from scratch.
Else runs on the four things that make a prototype actually your product: the design system in your repo, the staging backend, your auth and feature flags, and the PR itself. Same components, same data, same users, same merge gate.
‘It has no knowledge of our code base’
A PM at Airbyte, describing what happens the moment he opens a general-purpose prototyping tool on an existing product:
“Whenever I initially ask, it has no knowledge of our code base… It’s still that handoff where I describe what I want, now, Engineering has to go start from scratch.” – Matteo Palarchio, Airbyte
The prototype was supposed to shorten engineering’s work. In a sandbox tool, it adds a step. For why this matters across every kind of AI prototyping tool, see the AI-prototyping playbook for product managers.
‘Your product’ is not a visual thing. It is four specific technical things the prototype either runs on or doesn’t. Else runs on all four.
1. The design system
A PM at HP named the specific failure:
“The limitation with Lovable is that you have to recreate your design system every time.” – Product Ops, HP
Every sandbox tool – Lovable, Bolt, v0, Figma Make – writes code against a copy of something that looks like your design system. Tokens get approximated. Components get re-implemented from screenshots. States are mostly right. A PM at Monotype relayed the customer reaction to a demo that came out of this loop:
“Kinda looks close. It’s kinda right, but it’s not my product.” – Diego Schmunis, Monotype
The ‘kinda right’ state is the predictor of design-system rejection in review – the start-over pattern is how that scene plays out in detail.
Else installs as a GitHub app on the frontend repo and writes against the components and CSS already in production – the same <Button>, the same <Card>, the same <Modal> engineering shipped, imported from the same files the team is editing. If the design system changes next sprint, the Else prototype picks the change up at build time, because it is pulling from the files that changed.
2. The backend
A sandbox prototype calls sandbox APIs. The data is mocked. The account states are invented. The edge cases that exist in your actual product are invisible – the customer with the anomalous billing history, the enterprise account whose feature flag is locked on, the SKU that breaks the table layout.
Else extends the backend without modifying it. The prototype makes real calls against the real API, reads real data, and adds a prototype-only data layer for anything the new flow depends on that doesn’t exist in production yet. For new backend functionality the prototype depends on, Else exports a full backend spec and a handoff prompt engineering can pick up – the PR is the frontend; the backend ticket arrives with a spec attached.
3. Auth, feature flags, real users
The things only your product has: your auth provider, your feature flags, your permissions model, your Pendo or Amplitude instrumentation. The things a sandbox prototype cannot see.
When the Else SDK runs, the prototype loads as an alternative version of the product for whichever users the PM targets – a specific account, a specific team, a specific cohort. Auth state is the real auth state. Feature flags are real feature flags. Permissions are the permissions that user already has. The prototype sees the world the user sees.
4. The PR itself
When the prototype works, Else opens a frontend pull request on the repo – a PR that uses the components, the CSS, the file structure, and the test patterns already in the repo.
Engineering reviews it the way they review any PR – same pipeline, same tests, same merge gate. The author line is the only thing different.
Proof: rework numbers
The Product Ops team at HP sized the cost of a prototype that does not run on the real code:
“I’d say it’s highly variable. On the low end, maybe 10-20% rework. On the high end, maybe 50%+. It really depends on how well the prototype captures the full scope of what needs to be built.” – Product Ops, HP
10 to 50%+ is the engineering time a PM spends paying back for a prototype built somewhere the codebase isn’t.