A CPO at a B2B SaaS company had been evaluating prototyping tools for a few months when the difference clicked into place. She’d used Lovable. She’d looked at v0. The moment she opened Else for the first time, she named what she’d been missing.
“The biggest difference is it’s your actual product. If you’re using Lovable or Bolt, every time you open it, it’s a blank page. When you open Else, you look at your website as if you just opened your website. It’s fully functional, you can log in, you can do everything.”
The gap she identified was where the tool starts.
Built for someone with nothing
Lovable, v0, Bolt, Figma Make, Replit — the whole greenfield-first cohort — all begin with the same premise. A designer or PM has a new idea and no existing codebase to constrain it. The demo had to work for someone with nothing. A blank canvas. No design system to import. No production components to reference. No auth flow to puzzle through. No backend shape hiding in the staging environment. The tools were built sandbox-first.
That architecture was the right call for what those tools were designed to do. A designer who wants to test a wild new layout on a greenfield project — without spinning up a local environment, without touching production code, without needing an engineer to unlock the gate — gets a tool that works immediately. That is the win the greenfield-first tools deliver.
The architecture becomes a constraint the moment a PM at an existing company opens one of those tools and asks: can I prototype a feature on my actual product?
Why imitation is the wrong frame
A Growth PM at a B2B SaaS company had been testing different tools for exactly this reason. He had run up against the boundary himself. His summary was the cleanest articulation of the structural problem:
“Most of these prototyping tools assume that you have a brand new idea, brand new feature. So, they no good at imitating the existing look and feel.”
The sandbox tools were built to create from scratch, in a self-contained space. They cannot imitate the existing product because they were never given access to it.
A PM working on an existing product who wants to test a change to the dashboard — a new column, different filtering, a reworked state flow — can open Lovable and start building. The tool will produce something that looks roughly like a dashboard. The design library can be imported. The components can be approximated. Then the PM shows it to the team.
Everyone in the room is looking at two different artifacts in their head. The PM is looking at their product with one change. The designer is looking at a lookalike. The engineer is looking at something that was never connected to the backend. The customer, if they are in the room, is looking at a sketch of their product.
Built without access to your codebase
Sandbox tools were built to work without access to your codebase. That was the design. The tool recreates the interface every time because it has to — it has never seen the real one. When a design system lives on a repo and the prototype lives in a browser, they are separate objects trying to match. They drift by default. The PM keeps correcting. The tool keeps guessing.
A prototype that lives in a sandbox is a separate artifact from the product. It is a Figma file wearing the product’s clothes. When it ships, it has to be rebuilt because it was never the product in the first place.
Why Lovable, v0, and Bolt look nothing like your product
This is the question a PM is typing into Google or asking an AI assistant on a Friday afternoon: why does Lovable / v0 / Bolt look nothing like my actual product?
The answer is that those tools were built for someone with no actual product yet. Greenfield. The demo had to work for anyone, anywhere. Once the tool was sandbox-shaped, retrofitting it to run inside a B2B SaaS codebase — to import the real design system, respect the real auth state, speak to the real backend, work with real feature flags — was a different architecture entirely.
The tool makers kept their focus. The audience for greenfield tools is designers and solo builders and founders starting from zero. That market is enormous. Lovable, v0, Bolt, Figma Make, Replit are all winning in that space because they are doing exactly what they were built to do.
The PM at an existing company is a different audience and needs a different tool.
When the prototype is the change
The PM-to-designer-to-engineer handoff works best when the prototype and the product are the same object. The same files. The same design system. The same auth state. The same backend wired up. The same branch of the same repo.
Else lets PMs and designers prototype and test inside their actual product, then hand engineering a PR they merge, not rebuild.
When a prototype lives on the repo, it cannot drift. The design system the PM builds against is the real system. The components are the ones in production. The data is real because the prototype talks to the actual backend (or a safe extension of it). When the prototype is ready, it is the change, waiting for a code review.
The difference she named — between a blank page and your actual product — is the difference between rebuilding and merging.
For the use-case build, see Prototype on your real codebase. For the head-to-head, see Else vs Lovable.