For the PM at a product with years of history behind it, who keeps getting demos that look nothing like the thing they actually ship.
You describe the feature, the tool generates something clean, and it looks nothing like the product you ship. Wrong components. Wrong spacing. A design system the tool has never seen. The demo works. It is just not your product, and now an engineer has to rebuild it from scratch to make it real.
Else lets PMs and designers prototype and test inside their actual product, then hand engineering a PR they merge, not rebuild.
Why the demo never matches your product
Most AI prototyping tools assume a blank slate. They are built for the brand-new idea, the brand-new feature, the founder validating a concept with nothing shipped yet. A PM building on a mature product described what that assumption costs everyone else: most of these tools assume you have a brand new idea, a brand new feature, so they are bad at imitating the existing look and feel.
Most products are not new. A PM running product alone at an eleven-year-old fundraising platform put it plainly: we have this 11 year old product, and we are still investing in it. Years of components, design tokens, routing, backend behaviour, and customer muscle memory already exist. A prototype that ignores all of it is a clean picture of a product you do not have.
What “existing product” means in practice
When a prototype runs on your existing product and its existing codebase, it inherits what is already there:
- Real components from your repo, not lookalikes
- Real CSS and design tokens, so spacing and type match on the first pass
- Real routing and app structure
- Your backend, called the way production calls it
- The same CI checks and merge gate every other change goes through
The output is not a screenshot of a feature. It is the feature, sitting inside the product, behaving the way the product behaves.
The workflow
- Install the GitHub app on your repo.
- Describe the change you want.
- Else writes it against your existing components and conventions.
- Engineering reviews the PR.
- Engineering merges.
There is no rebuild step, because there is nothing to rebuild. The prototype is the code, and the code already uses your patterns.
What this removes
The engineering time for a small change is not the problem. The same lone PM estimated it usually takes an engineer two days to do the APIs and the front end. Two days is not what stalls the change. The wait does – the change sitting behind a quarter of committed work, the PM running the math on whether it is worth interrupting anyone to ask for it.
Else does not remove the engineering review, and it does not pretend the work is free. It removes the wait between a validated idea and a PR sitting in engineering’s inbox. The PM owns the bet. Engineering owns the merge.
Who this is for
- You have a product in market with real history behind it
- Engineering owns the merge gate, and you want it to stay that way
- You carry a backlog of small changes that never clear the queue
- Your customers are trained on the product as it is today, so a redesign is the wrong answer
- You have tried Lovable, v0, or Bolt and the output looked nothing like your product
If most of those are true, the blank-slate tools were never built for your situation. For the longer view on why, see AI prototyping for product managers, the field note on tools that can’t imitate your actual product, and why Lovable rebuilds your design system every time. The head-to-head on Else vs Lovable and the existing codebase advantage cover what changes once the prototype runs on the product you already shipped.