A PM at Airbyte was telling me how he opens a prototyping tool when he wants to test an idea on the actual product. He had been using Lovable for a few months. The first thing he had learned was where it stopped working.
“Whenever I initially ask, it has no knowledge of our code base. As soon as I say ‘it’s this specific page’, it goes, ‘oh yeah, I know where that page is’. It needs a lot more context than I would have expected to get started. And while it makes decent enough designs for communicating something to hand off, it’s still that handoff of: here’s what I want, but engineering has to start from scratch. – Matteo Palarchio, PM at Airbyte
The tools sped up idea->prototype. But they still land at a rebuild.
The workflow is this: The PM has an idea. The PM opens a prototyping tool. The tool produces an artifact that looks roughly like the product, with the design system replicated by approximation, the data invented, the page paths simplified. The PM uses the artifact to communicate the idea. Engineering reviews the artifact and starts from scratch. Whatever the prototype was, the thing engineering builds is something else. The prototype and the product diverge the moment engineering opens the ticket.
This is the part of the workflow most PM-tooling content does not engage with. The argument the field has been having for the last six months is whether the prototype replaces the PRD. That is the wrong fight.
A PM in a thread on r/ProductManagement called ‘Documentation can never be replaced’ wrote 70+ comments worth of an argument that started with the PRD-is-dead consensus from earlier in the year and pulled the other way. The top comment defending prototypes argued they were a useful starting point for finding a better solution than the PRD had specified. The thread complaint sat below that: the prototype could not replace the work the PRD did, because the prototype kept drifting from the product before it shipped.
That is the real argument. The prototype is fine. The PRD is fine. The thing nobody can defend is the gap between the prototype that got validated and the product that got shipped.
Diego Schmunis, a PM at Monotype, told me what that gap looks like when his team shows the prototype to a customer.
“Kinda looks close. It’s kinda right, but it’s not my product. – Diego Schmunis, PM at Monotype
The prototype was a defensible piece of work. The customer was looking at something that was supposed to be their product and was not. The validation conversation was about a different artifact than the product the customer would eventually use.
Drew Muller, the Director of PM at Ferry International, named the same gap from the other side, sitting in front of a tool that fights the design system every time he tries to use it.
“Tools really struggle with replicating the design system of your app quickly, easily, and efficiently. And for me personally, visual congruency is really important. I don’t want it to look like something else. I want it to look like an embedded part of my app. – Drew Muller, Director of PM at Ferry International
Drew was asking for a prototype that did not drift from the product. The visual congruency he was naming is the same drift Diego’s customer flagged on the call. The prototype that does not look like the product fails the validation conversation, because the conversation is about the wrong artifact.
The PM-tooling debate has been treating this as a fidelity problem. The actual problem is topology.
A prototype built outside the product is a separate object that has to be reconciled with the product later. The reconciliation is engineering rebuilding it. A prototype built inside the product is the same object as the product, with one branch difference. The reconciliation is a merge.
This is the post-PRD reframe the r/ProductManagement thread is reaching for and not quite naming. The argument is whether the prototype is the product. If the prototype is the product, the validation work and the shipping work are the same work. If the prototype is a separate artifact, the validation work pays its rent twice – once when the PM builds the prototype, once when engineering rebuilds the product.
When you prototype, you publish and you fix and you get the things to be just right. Then you hand it off and it gets completely rebuilt. There’s so much that is lost after you already put in so much work.
The work was real. The work was correct. The work did not survive the handoff because the prototype was a different object than the product.
PMs are discovering that picking tools by where the prototype lives is the gap they’ve been trying to bridge. A prototype that lives in a sandbox is going to drift, because every fact about the product – the design system, the auth state, the data shape, the feature flags – has to be re-injected into the sandbox or invented. A prototype that lives in the product cannot drift, because the prototype and the product are the same files.
Else is in the second category by construction. It installs as a GitHub app on the frontend repo. The prototype writes against the components and CSS already in production – the same <Button>, the same <Card>, imported from the same files engineering edits. When the prototype works, Else opens a pull request on the repo. Engineering reviews the PR the way they review any PR. The prototype enters the same merge gate any other branch enters. The artifact engineering reviewed and the artifact in production are the same artifact. For the four specific things the prototype runs on – design system, backend, auth, the PR itself – see prototype on your real codebase.
The prototype is the product. Just an unmerged branch of it.
Matteo at Airbyte was not running this play yet. He was using Lovable. He knew where it stopped. He was looking for the next tool.