--- slug: cursor-and-lovable-workflow title: "Cursor + Lovable: A Two-Tool Vibe-Coding Workflow" excerpt: "A Cursor and Lovable workflow that prototypes fast and refines without throwing the work away. Three stages, with the spec rules that survive the hand-off." primaryKeyword: "Cursor and Lovable workflow" publishedAt: 2026-04-11 readingTimeMin: 7 author: "Robert Boylan" tags: - cursor - lovable - ai-coding-tools - workflow - vibe-coding --- You sit down to build a small app. Lovable feels right for the first hour, because you want to see something on screen quickly and you don't want to think about file structure yet. Then the app gets real, you want a custom auth flow Lovable can't quite do cleanly, and dropping into Cursor starts to make sense. The question is how to do that without throwing away the work or breaking what already runs. Most posts treat Cursor and Lovable as alternatives. They aren't. Used in sequence, they cover more of the build than either does alone. Here's the Cursor and Lovable workflow that actually holds up over a real project. ## Why no single tool covers the whole build Lovable and Cursor are good at very different things. Lovable is a browser-based AI app builder. You describe an app in plain language, it generates a working web project with a frontend, a backend, and a Supabase database wired up. The whole stack appears in one go. The strength is speed of first draft. The limit is control: when the AI makes an opinionated choice you don't agree with, your options for fighting back are narrower than in a code editor. Cursor is an AI-native IDE (an integrated development environment, basically VS Code with AI baked in). You're inside the code, you can see every file, you can navigate by feel, and the AI helps you make precise edits. The strength is control. The limit is starting cost: building the first 60% of an app from a blank repo, in Cursor, is slower than letting Lovable scaffold it in fifteen minutes. Used together, you get the speed of Lovable's first draft and the control of Cursor's surgical editing. The trick is knowing where to hand off. ## Stage 1: shape the app in Lovable Open Lovable. Paste your spec, the actual one with audience, features, tech stack, and data model. Don't paste a vague idea like "a habit tracker"; paste the structured description. The reason the spec matters in this stage is that Lovable is going to make lots of decisions implicitly. It'll pick a database schema, an auth flow, a UI library, a routing pattern. If you don't tell it what you want, it picks defaults. The defaults are usually fine for a prototype and frustrating to undo when the app gets serious. Push Lovable until you've got the skeleton: the main screens, the data model, working auth, working CRUD on the core entity. Don't try to get all the way to launch in Lovable. Get to the point where you have a real running app you can click through, with the shape of the product visible. Things that work well in this stage: - Spinning up the auth flow with Supabase - Generating the dashboard layout - Wiring up basic forms and tables - Getting a styled landing page on the marketing route - A first pass at the main feature flow Things that start fighting back: - Custom auth logic (magic links with custom redirect rules, multi-factor flows, organisation-based access) - Background jobs or scheduled tasks - Complex search or filtering UX - Anything involving third-party API quirks (Stripe edge cases, S3 presigned uploads) When you hit the second list, that's the signal to leave Lovable. Don't fight it. Hand off. ## Stage 2: export and drop into Cursor Lovable lets you export the project to a GitHub repository. Do that. Clone it locally. Open it in Cursor. This stage is uncomfortable for about ten minutes because you're suddenly looking at file structure that someone else (the AI) chose. Take fifteen minutes to read through the top-level layout. Look at how routes are organised. Look at the data model files. Look at the auth setup. You don't have to love any of it, but you have to know what's there so you can decide what to leave alone. Once you're oriented, the spec comes back into play. Paste it into the Cursor chat. Tell Cursor what you've got (the Lovable-generated app), what you want to add or change, and ask it to match the existing patterns rather than introduce new ones. The exact phrase that helps: > Match the file structure and naming conventions already in the repo. Don't refactor anything that isn't directly required for the change. That last line stops Cursor from "improving" the Lovable-generated code while it's in there. Lovable's code style isn't always how a senior engineer would write it, but it's consistent within the project, and switching styles mid-build is worse than imperfect style. ## Stage 3: surgical edits with Claude Code if needed For most indie projects, Stage 2 is enough. Cursor handles the precision work and you ship. Some projects, though, hit a moment where you want to make a sweeping change that touches twenty files. Renaming the core entity. Migrating from one auth provider to another. Restructuring the data model after you realised the original shape was wrong. These are tasks where Cursor's strength (you, in the loop) starts to feel like a limit (you, doing twenty edits). That's when Claude Code earns its keep. It runs from the terminal, reads the whole codebase, and executes a multi-file change as a single agentic task. There's a longer breakdown of [when Claude Code wins over Cursor](/blog/cursor-vs-claude-code) for this kind of work. You don't need Claude Code for every project. Plenty of indie apps live their whole life in the Lovable-then-Cursor pipeline and never need the third tool. But knowing it's there, for the days when twenty-file edits are what's blocking you, is part of why this workflow scales. ## Spec rules that survive the hand-off The thing that makes this workflow work is the spec, used as the through-line. Without it, Lovable builds one thing, Cursor builds another, and the two diverge. A few rules that hold across all stages: - **Pin the tech stack in the spec, not the conversation.** "Tech stack: Next.js, Supabase, Tailwind, deployed on Vercel" written into the spec means every tool in the chain reads it. Telling Lovable verbally and then forgetting to mention it in Cursor is how you end up with two different stack assumptions. - **Pin the data model with field names.** "Workout has id, user_id, date, exercises[]. Exercise has name, sets[]." Without the field names, Lovable will pick one set and Cursor will sometimes pick another when you ask it to add functionality. Now the codebase has both, and one of them is silently wrong. - **Pin the design tokens.** "Theme: dark, charcoal background, single accent colour #d4a574." Lovable picks colours fast, Cursor doesn't naturally re-pick them, and the styling drifts as you add features. A design field in the spec stops the drift. - **Note what's explicitly out of scope.** Both tools, given an open prompt, will helpfully add features you didn't ask for. The "do not build" list is as important as the build list. ## When the workflow breaks This pipeline isn't universal. A few signals that you're in a project it doesn't fit: - **The app is heavily backend-shaped.** Lovable is web-frontend-leaning. If your app is mostly an API service, a CLI tool, or a data pipeline, skip Lovable and start in Cursor or Claude Code. - **The frontend has unusual UI requirements.** Lovable's defaults are clean, modern, web. If you need a complex interactive canvas, a 3D scene, or a heavily animated experience, the Lovable scaffold becomes friction rather than a head start. - **You don't yet have a spec.** Without a written description of what you're building, neither tool will produce something coherent. The pipeline assumes the spec exists. If yours doesn't, that's the work to do first. Picking between Cursor and Lovable, or any other [pair of AI coding tools](/blog/which-ai-coding-tool-should-you-use), gets easier when you stop framing it as one-or-the-other. Most non-trivial indie apps benefit from a tool that scaffolds fast and a tool that edits precisely. The two are complementary, not competitive, and the workflow above is just one of several ways the hand-off can land. The bigger takeaway is the spec. Lovable's quality is a function of what you tell it to build. Cursor's quality is a function of what you ask it to change. Both inputs are easier to write when you've already done the thinking somewhere durable. That's the gap [Draftlytic was built around](/blog/good-lovable-app-spec): a single description of the app that survives every hand-off in the chain.