← Field notes

2026-05-12

Why Lovable rebuilds your design system every time

Paul Johns·Co-founder·Updated 2026-05-18

Kyle Grant is a PM at HP. When he opens Lovable to prototype against the product his team already ships, he doesn’t start on top of what they’ve built. He starts from zero. Every component, every color, every spacing token – it’s all been defined already, in the design system that governs the actual product. None of it carries over into the prototyping tool.

The tool was not built for existing products. It was built for the open web, where the first UI is the only UI. A design system is a constraint a greenfield tool was never asked to honor.

Kyle’s framing: “the limitation with Lovable is that you have to recreate your design system every time. So, we have a design system that we’ve built out, and every time a designer uses Lovable, they have to recreate that design system in Lovable.”

Not a “maybe you’ll run into this.” Every time. One designer, one session: rebuild. Five designers, five sessions: rebuild five times. The recreation tax compounds across every prototype because nothing carries forward into the tool.

The cost surfaces later, when the prototype moves to engineering. Kyle frames that moment too: “when it goes to engineering, they have to reimplement it within the actual design system of our application. So, there’s rework there.”

Some rework is the honest version. The dishonest versions float through every prototype conversation: engineers are being slow, or design is being precious, or the PM should have been more specific in the first place. The actual failure is one layer deeper. The prototype tool consumed time on a problem engineering solved years ago – how to keep a product internally consistent across years of work and dozens of contributors. The tool was designed to ignore that solution, then hand the problem back to engineering to solve again.

The hidden cost is where the PM’s effort goes. The session doesn’t start with “what should this feature do.” It starts with “rebuild these buttons, these colors, these interaction patterns.” The PM’s first prototype was not a prototype of a feature. It was a prototype of a design system that already exists.

A senior designer at another company described the inverse of this moment. She had access to Figma. She used a vibe-coded prototype to make it interactive. The prototype was fine for testing – it was not fine for design review. It did not match the actual product. She knew that going in. The handoff to engineering was a Loom video and a reference Figma. Engineering rebuilt it.

The cycle repeats because the tool category was built for a use case that is not yours. The open web has no design system. Your product does. A vibe-coded prototype that ignores it is not a prototype your design team can endorse. A prototype your design team cannot endorse is not a prototype that ships.

The solution has a clean exit. Pick a tool that uses your actual components.

If the tool runs on your actual codebase, the recreation tax disappears. The buttons in the prototype are the buttons that already exist. The colors are right because they came from the source. The spacing, the interaction states, the token structure – all of it is the system your product already enforces. Design review becomes a conversation about the design, not about whether the design system is being respected.

Kyle described what that would mean for his team: “the prototype would be much more representative of the actual product. And it would mean that there’s less rework for engineering.”

Not zero rework. Less. The rework that remains is rework about the thing he was trying to test – the feature, the flow, the interaction – not rework about systems that are already locked. Engineering moves at speed because the constraints are already there, already enforced, already part of the artifact he handed them.

The fix is producing artifacts the design system has no reason to reject.

For the structural reason vibe-coding tools build something that isn’t your product, see tools that can’t imitate your actual product. For the brownfield-over-greenfield argument this piece sits inside, see the existing codebase advantage.

Else lets PMs and designers prototype and test inside their actual product, then hand engineering a PR they merge, not rebuild.


Build like the product leaders you just read about

Try it out