Stop Using Lovable for Prototyping. Use Storybook + Claude Instead

17 Feb, 2026

TL;DR

Stop using Lovable for UI prototypes. 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 moved away from Lovable

Lovable does what it promises. But we kept running into the same friction.

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, keep it in sync. That’s a lot of overhead for prototyping.

And even with custom instructions in Lovable, the prototypes still live in their own project with their own build system and folder structure. The output looks great, but moving that code into your actual project means rewriting it. We wanted prototypes we could ship without that step.

What we do instead: Storybook + a Claude skill

Instead of taking your code to an outside tool, bring the prototyping into your codebase.

Teach Claude your codebase

We have a CLAUDE.md that describes our design system, file structure, and coding conventions. On top of that, We have a skill that tells Claude how to write Storybook stories, so the generated code fits straight into the repo. No cleanup. No migration.

Use Storybook as the canvas

Storybook lets you build and preview UI components in isolation. No running the full app, no real backend. Each prototype is a 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 mock responses, and the whole thing works like it would in production.

For sharing, Storybook builds into a static site. We host ours on Chromatic. Stakeholders get a clickable prototype in the browser. Same experience as Lovable, but built with our actual components.

The tradeoff

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.

In practice this hasn’t mattered. Everyone on the team already writes code with AI. Running Storybook and iterating with Claude feels like normal development, and it’s actually faster because the output is ready to use immediately.

Why this works

Prototypes should be part of your codebase, not a separate world.

When a prototype lives in your project and uses your actual components, it does double duty. Stakeholders get something to review. Developers get a head start. The code already uses the right components, the right patterns, the right file structure. Going from “prototype” to “feature” is a small step, not a rewrite.

There’s a less obvious benefit too. Our codebase runs 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. Wrong types? tsc catches it. Bad formatting? prettier fixes it. The prototypes already pass CI before anyone reviews them.

Bonus: pages with routing

Some prototypes aren’t single components. They’re full pages with routing. Multi-step wizards, tabbed views, nested routes. Storybook doesn’t support this by default because it controls the URL bar.

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 navigate between routes like normal. Route params, redirects, nested layouts, all of it.

When you’re ready to move to the main app, you just move the components to real routes. No major changes.

Wrapping up

If your design system lives in your codebase, your prototypes should too.

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 picks it up.