For the PM who has shipped a prototype that worked perfectly until the customer’s real account hit the page. What changes when the prototype runs on the actual backend.
The customer’s real account is the thing the prototype never saw. Seven-year billing history. Tenant-specific permissions. A feature flag locked on from a prior experiment. The flow that worked on the PM’s laptop breaks on day one of production – and engineering rebuilds the feature to fix it.
TL;DR
Most prototyping tools mock the data. The dropdown that listed three products renders three hundred when a real customer hits it. The seven-year billing history breaks the table. Engineering ships the feature, then ships the rebuild that handles the real conditions.
Else runs the prototype against your actual backend – the real API, real accounts, real permissions, real feature flags. The failure surfaces in your editor, when you still have time to fix it.
Else lets PMs and designers prototype and test inside their actual product, then hand engineering a PR they merge, not rebuild.
Why mocked-data prototypes break
A PM builds a visual flow in Lovable. The customer watches a demo on the PM’s laptop and approves it. Engineering ships the feature three weeks later. On day one of production, the real data arrives.
The customer’s account has a seven-year billing history. The dropdown that listed three products renders three hundred. Each one a small problem the prototype never had to confront, because the prototype was a drawing under invented conditions.
The two categories Drew Muller ships at Ferry
Drew Muller is the Director of Product Management at Ferry International, a real estate coaching, training, and education company. The features he ships split almost evenly into two categories.
Visual flows – navigating courses, exploring learning paths – “are really easy to spin up with Figma Make or another vibe-coding tool.” Business tools are different: “Those do require data to be functional. They require user data.”
The first category runs cleanly in sandboxed prototyping tools because the design is the deliverable. The second depends on the data behaving the way real customer data behaves.
How Else runs the prototype on real data
Else runs the prototype against your actual backend – the real API, accounts, permissions, feature flags, and data. When the prototype calls the billing history, it calls the actual endpoint. The data it loads is the data your users see.
For new fields the prototype depends on – something the backend does not return yet – Else adds a prototype-only data layer. Your backend stays untouched. When the scope requires actual backend work, Else exports a backend spec and a handoff prompt alongside the frontend PR. The engineer building the new endpoint receives the spec with the ticket.
The edge cases that break sandbox prototypes
Sandbox prototypes hide failures until production:
- Enterprise accounts with multi-year billing histories. Tables built for fifty rows break at fifty-three.
- Tenants with custom permissions. Authorization fails because the check assumes a standard role.
- Customers with feature flags locked on from old experiments. New features conflict with old state.
- Timezone mismatches. The prototype tested in UTC; the customer is in Los Angeles.
- Currency formatting. Mocked USD; the customer operates in EUR with different decimal rules.
- Volume. The query returns three hundred items; the prototype tested with ten.
- Account state. The customer has an inactive subscription, a past-due invoice, a refund pending.
Lovable, Bolt, v0, and Figma Make were all built to handle a blank canvas. A blank canvas has none of these conditions. See Else vs Lovable for the head-to-head.
Breaking before production
Mocked-data prototypes hide the failure until production. The real conditions – real volume, real edge cases, real state transitions – arrive on day one. By then engineering has rebuilt the feature.
When the prototype runs on real data, the failure surfaces in your editor, when you still have time to fix it.
For how this changes the handoff to engineering, see ship a production PR without coding. For the broader argument on prototyping inside an existing codebase, see prototype on a real codebase.