Stop Using Lovable for Prototyping — Use Storybook + Claude Instead
TL;DR
Stop using Lovable for UI prototypes. Instead, write a Claude skill that knows your codebase. Use it to generate Storybook stories, and mock API calls with MSW. You get prototypes built with your real components. Stakeholders can click through them. Developers can ship them — no rewrite needed.
Why we wanted more
Lovable does what it promises. But we found a workflow that gets us closer to shipping.
Our design system lives in our codebase. It's not a separate package. To get full value from Lovable, we'd have to pull it out, publish it, and keep it in sync. That's a lot of overhead just for prototyping.
Bridging the gap takes work. Lovable creates its own project with its own build system, folder structure, and conventions. You can add custom instructions to steer the output — but then you're maintaining those instructions in Lovable and keeping them in sync with your codebase. The prototypes look great, but moving that code into your project still means rewriting it.
We wanted prototypes that used our components and produced code we could ship without a rewrite. That led us to a different approach.
A better way: Storybook + a Claude skill
Instead of taking your code to an outside tool, bring the prototyping into your codebase.
Teach Claude how you write code.
We have a CLAUDE.md that shows Claude our design system, file structure, and coding conventions. We have a skill which tells Claude how to write the story in a way that writes code that fits straight into the codebase. No cleanup. No migration.
Use Storybook as your canvas.
Storybook lets you build and preview UI components on their own — without running the full app or connecting to a real backend. Each prototype is a Storybook "story": a small file that renders a component with sample data. For API calls, we use MSW (Mock Service Worker) to intercept network requests. The story loads the component, MSW handles the API calls, and the prototype works just like it would in production — without a real backend.
Sharing is easy. Storybook builds into a static site. Host it and share the link. Stakeholders get the same experience as Lovable — a clickable prototype in the browser — but it's built with your actual components. We use Chromatic for hosting Storybook.
The tradeoff
There is one downside. You work locally. You run Storybook on your machine and build with Claude. You can't just open a browser tab and start typing prompts like you would with Lovable.
This hasn't slowed us down. Everyone on the team already writes code with AI. Running Storybook and working with Claude feels like normal development. It's actually faster because the output is ready to use right away.
Why this works
The key idea: prototypes should be part of your real codebase, not a separate world.
When a prototype lives inside your project and uses your actual components, it serves two purposes. Stakeholders get something to review. Developers get a head start on the real thing. The code already uses the right components, patterns, and file structure. Going from "prototype" to "feature" is a small step, not a rewrite.
There's a deeper benefit too. Our codebase has several quality checks built in — prettier, eslint, dangerjs, knip, and typescript strict mode. When prototypes live in the repo, they go through the same checks. If Claude writes code with unused imports, knip catches it. If the types are wrong, tsc catches it. If the formatting is off, prettier fixes it.
Since prototypes live in the repo, they already pass your CI checks before anyone reviews them.
Bonus: handling pages with routing
Some prototypes aren't single components. They're full pages with routing — multi-step wizards, tabbed views, or pages with nested routes. Storybook doesn't support this by default because it controls the URL bar itself.
The fix: use an in-memory router (like createMemoryRouter in React Router or Memory Routing in Tanstack Router) inside the story. Storybook still owns the address bar. But inside the story, your page components move between routes just like they would in the real app — route params, redirects, nested layouts, all of it.
When you're ready to move to the main app, move the components to app routes — no major changes are required.
We made the switch
If your design system lives in your codebase, your prototypes should too. Storybook + Claude gives you prototypes built with your real components, following your real standards, producing code you can ship.
Product managers and designers have started pushing ideas and design changes themselves. They clone the repo, run Storybook, and iterate with Claude — no engineering involved. A PM can prototype a new flow, share the Storybook link for feedback, and have working code ready before engineering even gets involved.