--- slug: when-to-migrate-off-lovable title: "When to Migrate Off Lovable (or Bolt) Onto Your Own Codebase" excerpt: "Knowing when to migrate off Lovable is harder than the migration itself. Here are the four signals your project has outgrown the platform, and what to do next." primaryKeyword: "migrate off Lovable" publishedAt: 2026-07-27 readingTimeMin: 7 author: "Robert Boylan" tags: - lovable - bolt-new - migration - cursor - indie-dev --- Your Lovable app has real users. Maybe paying ones. The core feature works, sign-up flows, the data saves, people actually come back. And then something breaks in a way that re-prompting doesn't fix. Or your hosting bill crosses a number that makes you squint. Or a user asks for a thing you know exactly how to build and you can't, because the platform is in the way. That's the moment. Most people ignore it for a while. The platform got them this far; it feels disloyal to leave. And the migration looks scary from the outside. This post is for the point after that moment, when you're ready to take it seriously. The signals are usually obvious in hindsight. Let's make them obvious before that. ## The four signs you've outgrown the platform These aren't "maybe" signals. When multiple show up at once, you're not ahead of the curve. You're already behind it. **1. The cost of staying exceeds the cost of moving.** Lovable's hosted plans are priced for prototypes and early products. Once you have real traffic, the per-seat or per-message pricing on many AI builders turns into a real line item. Compare what you're paying to run a comparable stack yourself on something like [Supabase](https://supabase.com) and Vercel, and the math usually favours moving well before you expect it to. This isn't a knock on the pricing model. The convenience premium is real and worth it while you're proving the idea. The question is whether you're still in that phase. **2. Performance is becoming a product problem.** Browser-based AI builders like Lovable and Bolt run on shared infrastructure. That's fine for a prototype. When users start complaining about load times, or you're watching your Core Web Vitals crawl, or the app is slow in a way you can't diagnose because the hosting is a black box, that's a signal. Moving to infrastructure you control lets you cache, optimise, and actually measure what's happening. **3. An integration is blocked by the platform.** This is the clearest signal. You want to add a webhook handler. You need a background job that runs on a schedule. You want Stripe to post events to your server, or you want to call an API that requires a server-side secret. The platform either can't do it, does it awkwardly through a workaround, or gates it behind a plan tier that costs more than the feature is worth. Custom logic that runs server-side is the wall most AI-built apps hit first. Lovable's Supabase integration handles a lot, but it's still a frontend-plus-database pattern at heart. Once your app needs a genuine backend, you're fighting the tool instead of building the product. **4. Debugging requires understanding code you can't see.** Re-prompting is a valid debugging strategy until it isn't. The moment you're spending more time fighting the AI's interpretation of a bug than you would spend just reading the code and fixing it, you've crossed a line. If you exported the project tomorrow, cloned it, and opened it in Cursor, could you work on it? If yes, you're probably better off already. If no, the migration work includes getting comfortable with the codebase, which is worth planning for. ## What "owning your codebase" actually means and doesn't Owning your codebase means the code lives in a Git repository you control, and you can run it, change it, deploy it, and debug it without going through the platform's interface. It does not mean writing everything by hand. It does not mean giving up AI tools. It does not mean becoming a traditional developer who reads stack traces for fun. After a Lovable export (or a Bolt download), you have a real React app backed by a Supabase project, sitting in a folder on your machine. The code is yours. The database is yours. You can open that folder in Cursor or Claude Code and keep building in exactly the same vibe-coding way you've been working, with more control over what happens. The shift is from "the platform decides what's possible" to "the code decides what's possible, and you can change the code." That's the whole migration. The tooling doesn't have to change. The pace doesn't have to change. What changes is the ceiling. ## Migration in three phases: export, audit, continue building **Phase 1: Export.** Both Lovable and Bolt let you export your project to a GitHub repository. Do this before anything else. Then clone the repo, open it in Cursor or Claude Code, and don't touch anything yet. Spend fifteen minutes reading the file structure. Where are the components? How is routing set up? Where does the Supabase client live? You don't need to approve of every choice the AI made. You need to know what's there. Point your own Vercel account at the repo and do a clean deploy from source. Make sure the app still works before you change a single line. This is your baseline. **Phase 2: Audit.** Go through the app with a short checklist. What's working well and should be left alone? What's fragile (or just confusing) and needs to be cleaned up before you build on top of it? What third-party things are wired up that you didn't know about? The things worth auditing first: the auth setup, the database schema, any hardcoded secrets or API keys in the frontend, and the environment variable story. Lovable and Bolt both manage some of this for you invisibly. Now you're the one managing it. For secrets specifically: any API keys the AI builder was injecting as part of the platform need to move into your own Vercel environment variables. Don't skip this. A key left in a public GitHub repo has a shelf life of about four minutes. **Phase 3: Continue building.** Once the app is running in your own infrastructure and the audit is done, you're done migrating. You don't need to rewrite anything. Pick up where you left off, using whatever AI coding tool you'd reach for anyway. See [the Cursor + Lovable workflow post](/blog/cursor-and-lovable-workflow) for a practical breakdown of how to keep that development style after the hand-off. This phase is where people waste time by trying to "fix everything" before shipping the next feature. Don't. The migration is a continuity event, not a refactor. Fix what's broken or risky. Leave what's working. Build what's next. ## When not to migrate Sometimes the platform isn't the problem, and migrating is just procrastination with extra steps. **You don't have real users yet.** If you're still trying to find product-market fit, the platform's convenience is worth more than the codebase ownership. The thing you need to ship fast is the idea, not the infrastructure. Come back to this post when you have people who would miss the app if it disappeared. **The platform isn't the bottleneck.** If you're stuck because the feature is hard to design, or because you don't know how a particular API works, or because you're not sure what to build next, none of that gets better when you own the codebase. The bottleneck is the product thinking, not the platform. Moving hosting doesn't fix it. **The app is genuinely simple.** Some apps are a CRUD front-end on a database and nothing else. Lovable is excellent at that shape forever. If your app will never need custom server logic, background jobs, or complex integrations, staying on the platform is the rational choice. The signal that you're migrating too early: you can't point to a specific thing the platform is blocking you from doing. "I want more control" is not a migration reason. "I can't add a webhook handler and I need one to process Stripe events" is. ## Picking the next tool: Cursor vs Claude Code vs something else Once you're off the platform and building on your own codebase, you need an AI coding tool that works inside a real project folder. The two that make the most sense for former Lovable or Bolt users are Cursor and Claude Code, and [the differences between the two AI coding approaches](/blog/cursor-and-lovable-workflow) are worth understanding before you pick. The short version: **Cursor** (an AI-native IDE based on VS Code) is the natural landing spot if you want to see all your files, make precise edits, and stay in a familiar code editor shape. It's good at targeted changes: "update this component," "fix this bug," "add this field to the form." After an AI builder export, most people find Cursor the least-friction next step. **Claude Code** (Anthropic's terminal-based AI coding agent) is better for larger changes that span many files at once. Restructuring the data model, migrating an auth provider, wiring up a whole new feature end-to-end. It reads your whole codebase at once and can execute a complex change as a single agentic run. Overkill for most daily edits; genuinely useful when the change is sweeping. For most indie devs coming off Lovable or Bolt: start with Cursor. Use Claude Code when you hit a change that feels like twenty edits in a row. Neither one requires you to write code from scratch any more than the platform did. You're still describing what you want. The description just has higher resolution now. ## The cost of waiting too long The longer you stay on the platform past the point where migration makes sense, the worse the migration gets. You build more features that are tangled with platform-specific behaviour. You accumulate workarounds that mask the actual structure of the data. The gap between "what the AI thinks is happening" and "what is actually happening" grows quietly. Most people who migrate too late describe the same experience: they get into the codebase and find that it's more coherent than they expected, but messier in specific corners they'd been avoiding. The workarounds are visible in the code. The data model has drift from the fifth re-prompt that tried to fix something the fourth re-prompt broke. You can't avoid all of that. It's just what AI-built code looks like. But you can stop adding to it, and the audit phase is where you find and isolate the worst of it before it spreads. The migration itself usually takes one day. The audit usually takes another. Two days to own your own product. That's a reasonable trade, and most people put it off for six months after the moment they should have done it. Draftlytic won't do the migration for you, but it's useful as a planning layer before and after: describe what you've got, clarify what you're keeping and what you're adding, and generate a spec that goes cleanly into [Cursor](/prd-for/cursor) or [Claude Code](/prd-for/claude) instead of a browser-based builder. The codebase changes. The thinking process doesn't have to.