Product managers have always had the same core constraint: to test a hypothesis with real users, you first need a prototype. And to get a prototype, you need engineering time. That loop has been the source of half the frustration in product work for the last decade.
The Lovable MCP server changes the loop entirely.
Lovable recently released what is, in my opinion, their most important feature in a year: a proper MCP server that lets you connect Claude Code to Lovable. The result is that you can generate faithful, on-brand Lovable prototypes directly from Claude Code, using your app's actual design tokens and design system, without involving your dev team at all.
This is not just a developer convenience. For product managers and product designers, it is a workflow shift that removes the main bottleneck between a hypothesis and validated learning. It does that by combining the two things that were always at odds before: the design-system fidelity you only got from building inside the codebase, and the instant shareable link you only got from a standalone tool.
Watch the full walkthrough here:
Key Takeaways
- The Lovable MCP server combined with Claude Code removes the main bottleneck between a PM hypothesis and a validated prototype, eliminating the need for engineering time to build a testable version.
- Build a reference project once inside Lovable using your real codebase design tokens and component patterns; every future prototype duplicates this base so fidelity is automatic, not recreated from scratch.
- Each feature hypothesis gets its own isolated Lovable project: no branch management, no risk of touching production, and an instant public share link ready for user tests.
- This approach combines design-system fidelity (Claude Code reads your real tokens and conventions) with instant shareability (Lovable deploys to the cloud automatically), solving the trade-off that made both previous approaches impractical.
- The organizational benefit is real: PMs can run user tests in week one of a sprint rather than week three, and bring a validated prototype to engineering instead of a static Figma mock.
- The sustainable use case for Lovable in a professional product workflow is hypothesis validation, not one-off app building: a repeatable sandbox that keeps prototypes on-brand and faithful to the real product.
Learn this hands-on
Become a 10x PM by learning how to use Claude Code in your daily work as a Product Manager, through 3 highly efficient live sessions of 1h30. Join the Claude Code for PMs live cohort.
Why PMs Need Their Own Prototype Lane
The traditional path from feature idea to user feedback looks like this: write the spec, wait for sprint planning, wait for the feature to be built, wait for deployment, run the test. That is weeks of elapsed time before you learn anything real about whether the idea was worth pursuing.
The faster alternative that most teams have tried is Figma prototypes. These are faster to produce, but they require a skilled designer, they are not interactive enough to feel real to test participants, and they cannot be deployed to actual users in a shareable link they open on their own device.
What PMs actually need is something that looks and behaves like the real product, is shareable instantly, and does not require a branch, a deployment pipeline, or any engineering coordination.
That is exactly what the Lovable MCP server combined with Claude Code provides.
Prerequisites
Before you start, make sure you have three things in place:
- Access to your app's repository. Claude Code needs to read your codebase to extract design tokens, color systems, spacing conventions, and component patterns. The more complete your codebase, the more faithful the reference prototype will be.
- Claude Code. You will be orchestrating everything from Claude Code, including the Lovable MCP commands.
- A Lovable account. The Lovable MCP server authenticates via OAuth, so you need a Lovable account with active access.
The Workflow: Reference Project, Duplicate, Ship
The core workflow has three phases. Each one is deliberate, and skipping the first phase is the most common mistake.
Step 1: Build the Reference Project Once
The foundation of the entire workflow is a Lovable "reference project," a version of your existing app rebuilt inside Lovable that is as faithful as possible to your real product.
You build it from Claude Code, with the Lovable MCP server connected, by giving Claude Code an explicit instruction: scan the codebase for design tokens, colors, typography, spacing, and component patterns, then generate a Lovable project that replicates the existing UI as closely as possible.
Provide a screenshot of your app alongside the prompt. Claude Code will read the codebase context and pass detailed instructions to Lovable via the MCP server. Lovable generates the project in a few minutes and gives you a live preview link.
The first version will not be perfect. That is expected. Open the Lovable editor and iterate directly: add missing components, fix spacing, adjust colors. The goal is to get the reference project close enough that a user who sees the prototype would think it is the real product.
Once you are satisfied, rename the project clearly (something like "REF - [App Name]") and never delete it. This is your base for every future prototype.
Step 2: Duplicate the Reference for Each New Feature
Whenever a new feature hypothesis needs to be tested, you go back to Claude Code and ask it to create a new Lovable project that duplicates the reference. Each feature gets its own isolated lane, its own clean copy of the reference project with the new feature added on top.
In the demo walkthrough, the feature being tested was the ability to add tables to a canvas inside an Excalidraw-style whiteboard app, a feature that users had been requesting in GitHub issues and that FigJam already offers.
The prompt to Claude Code included the feature description, a link to the relevant GitHub issue (for detailed context), and screenshots of how FigJam implements the table interaction. Claude Code instructed the Lovable MCP to duplicate the reference project and add the table functionality on top.
Within a few minutes, there was a new Lovable project with a working table element that could be dragged and dropped onto the canvas, complete with the ability to add rows and edit content inline.
Step 3: Share, Iterate Live, Then Bring It Back
The Lovable project has an instant shareable preview link. You send that link to users or customers without any deployment setup, no ngrok tunnel, no Vercel config, no coordination with the infra team.
As you collect feedback, you iterate directly in Lovable. If users find the table interaction confusing, you adjust it live and share the updated link. This tight feedback loop is what makes the workflow genuinely useful for hypothesis validation, not just for generating prototypes.
Once a feature is validated and you want to bring it into the production codebase, you extract the logic from the Lovable project and implement it properly via Claude Code in the main repo.
The Best of Both Worlds: Fidelity Plus an Instant Link
To understand why this workflow matters, it helps to look at the two approaches PMs have today, and where each one breaks down.
Approach 1: Build the prototype on a branch from your codebase. This is the gold standard for fidelity. You are working inside the real product, so the design system is exact and the behavior is real. The problem is that it only lives in a local environment. To put it in front of users, you have to deploy it: expose your local server with a tool like ngrok, push it to Vercel, or go through your company's own cloud setup. Every one of those options pulls in your engineering team, at least for the initial configuration. Great fidelity, painful to share.
Approach 2: Build a standalone prototype in Lovable. Now you get the opposite trade-off. Lovable gives you an instant public link you can share with anyone, with zero deployment work. But the project sits on its own, decorrelated from your codebase. It does not know your design tokens, your components, or your conventions, so what you share looks like a generic Lovable app rather than your actual product. Easy to share, weak fidelity.
The workflow takes the best of both worlds. By connecting Claude Code to Lovable through the MCP server, you generate new features and pages from your real codebase (Claude Code reads your design tokens, components, and patterns) and you get them deployed to the cloud instantly behind a Lovable share link. You keep the design-system fidelity of the branch approach and the instant shareability of the standalone approach, without choosing between them.
Each prototype is also isolated by design. It lives in its own Lovable project, so there is no risk of touching production and no branch management to handle. The link is live the moment the project is generated.
The net effect is that product people can validate a hypothesis quickly, without waiting on engineering to ship a first feature-flagged version, and without waiting on a product designer to build a dynamic prototype from scratch.
As Teresa Torres, author of Continuous Discovery Habits, puts it: "Building is very cheap now. That doesn't mean we should build every idea we have."
Building is very cheap now. That doesn't mean we should build every idea we have.
What This Unlocks for Product Teams
The deeper benefit is organizational. When PMs and designers can spin up on-brand, interactive prototypes independently, the shape of how product decisions get made changes. Product teams that pair this workflow with a dedicated agent stack can cut the feedback loop even further.
You can test multiple versions of a feature in parallel before the team commits to building any of them. You can run user tests in week one of a sprint instead of week three. You can show a validated prototype to engineering rather than a Figma mock, which changes the quality of the spec conversation.
You can also instrument the prototypes with analytics or heatmaps without touching production infrastructure, which means you get behavioral data from test users on top of qualitative interview feedback.
The engineering team is not cut out of the loop, they are freed to work on implementation details and architecture rather than spending cycles on speculative features that might not survive user testing.
Product manager and want to work like this? This is exactly what we teach in Claude Code for PMs, our live cohort for product teams: 3 live sessions of 90 minutes over 2 weeks. Every PM ships a real feature, builds their own agent, and gets personalized written feedback.
The Sustainable Lovable Use Case
It took a while to find a recurring, sustainable use case for Lovable in a professional product workflow. The answer is hypothesis validation. Not one-off app building, not replacing engineers, but giving PMs and designers their own sandbox for testing ideas before those ideas consume engineering capacity.
The combination of Claude Code and the Lovable MCP server makes that sandbox genuinely on-brand and faithful to your real product. That is what makes it useful for real user research rather than just internal demos.
The requirements are modest: repo access, Claude Code, and a Lovable account. The workflow is repeatable for every new feature idea. And the output is a shareable prototype in minutes, not weeks.
