Your Lovable or Bolt prototype did its job: it proved people want the thing. Users clicked through it, maybe some pre-paid, and now you need the version that can take real money from real customers without embarrassing you. What you do not need to do is start over — and you also shouldn't ship the prototype as-is, for reasons we've catalogued in detail.
This is the migration playbook: how to audit what you have, choose between the two viable routes, and execute either one in weeks rather than months. It assumes you've already accepted the demo-vs-production gap and decided a real foundation matters — we won't re-argue those here.
The two routes (and when each makes sense)
Route A — harden the AI output. Keep the generated codebase and upgrade it subsystem by subsystem. Choose this when the app is genuinely small (a single-purpose tool, few entities, no teams), your stack confidence is high, and the generated structure is unusually clean. Budget two to six weeks.
Route B — port the proven idea onto a boilerplate. Treat the prototype as a specification — validated screens, flows, and copy — and rebuild its features on a production foundation that already ships auth, billing, tenancy, and email. Choose this when money will move through the app, teams/permissions are anywhere in your future, or the generated code already fights you. Budget one to three weeks, less than most people expect, because the hard 30% arrives pre-built.
The honest default for anything you'll charge for is Route B. Founders consistently overestimate the rebuild cost (the features are the easy part to recreate) and underestimate the hardening cost (you become the first production user of every subsystem you patch).
Step 1: Audit what you actually have
Half a day, regardless of route:
- Export the code (Lovable and Bolt both support this — typically to GitHub). Even if you port, the export is your reference implementation.
- Inventory the features that earned validation. List what users actually used and praised — that list, not the codebase, is the asset you're migrating. Be ruthless: prototype features nobody touched don't board the lifeboat.
- Map the data. What entities exist, what owns what, and whether there's real user data to preserve (often there isn't — which makes everything simpler).
- Run the gap checklist from the production-readiness article: auth depth, billing edge cases, tenancy, security, email, tax, deployment. Score each subsystem keep / harden / replace. If most scores read "replace," Route B just chose itself.
Route A: the hardening path
Work in this order — each layer protects the ones after it:
Replace demo auth with real auth
Rip out whatever session improvisation the generator produced and wire a maintained auth layer (Supabase Auth used properly with verified flows, or Clerk, or your framework's hardened library): password reset that expires, OAuth, session revocation, re-verification on email change. Auth is first because every other fix assumes identity works.
Wire real billing — webhooks first
The checkout was never the hard part. Build the webhook handler before anything else: signature verification, idempotency, out-of-order event handling, and a subscription-state table your app trusts instead of asking Stripe on every request. Then the ugly paths — failed renewals, dunning, cancellation timing, access revocation. Test with Stripe's CLI replaying events, including duplicates and gaps; if your DB state survives that, you have billing.
Security review — non-optional before launch
Database rules that aren't allow all (the classic prototype footgun), input validation at the API boundary, rate limiting actually attached, secrets out of client code, and an ID-swap test on every endpoint (log in as user A, request user B's resources — any success is a launch blocker). Have your AI tool review its predecessor's work as an adversary: "audit this codebase as a penetration tester" catches a remarkable share of generated-code holes.
Then the long tail: transactional email on a configured domain, error tracking, separated environments, backups. This is the route's real cost — the checklist keeps going, and you own every item.
Route B: the boilerplate-foundation path
Pick the foundation to match the prototype's shape
AI builders overwhelmingly output React/Next.js with Supabase underneath, which makes the shortlist natural — verified against current directory listings:
- supastarter ($100–249) — the lowest-friction landing for Supabase-shaped prototypes: same backend mental model, auth and Stripe/Lemon Squeezy wired, Next.js/Nuxt/SvelteKit flavors.
- ShipFast ($129–149, Next.js) — the speed pick: Stripe, auth, email, SEO defaults, simplest structure to learn in a day.
- MakerKit ($299–599, Next.js/React/Remix + Supabase) — the long-haul pick: strict architecture, admin panel, docs/blog infrastructure; choose it when teams and years-of-maintenance are in the plan.
Filter the wider field by stack and must-have integrations on the comparison hub — Stripe kits, auth, Next.js — and compare any two head-to-head before buying.
Port features as specs, not as code
Deploy the kit untouched first (an afternoon — it front-loads every infrastructure surprise). Then move feature by feature: for each item on your validated-features list, describe it to Cursor or Claude Code referencing the prototype — screenshots, exported components for styling reference, the data shapes from your audit — and have the AI implement it inside the boilerplate's patterns. This is exactly the boilerplate + Cursor workflow, and it's why the rebuild is fast: the AI does the typing, the kit supplies the conventions, and your prototype supplies the spec that's already been user-tested.
Resist improving features mid-port. Match the validated behavior, ship, then iterate — scope creep is how two-week migrations become two-month rebuilds.
Migrate data only if there's data worth migrating
Prototype-stage user data is usually small enough for a script (your AI tool writes it from "here's the old schema, here's the new one"). Real pre-payments deserve care: reconcile against the payment provider's records, which are the source of truth your prototype's DB probably isn't.
A worked example timeline (Route B)
What the port actually looks like for a typical validated prototype — say, a niche project-tracking tool with four core screens, Supabase underneath, and a dozen pre-paying users:
- Day 1: Buy the kit, deploy it untouched, configure auth providers and Stripe test keys. Read the docs. Write the rules file for your AI tool.
- Days 2–3: Data model first — port your entities onto the kit's existing user/team tables, write the migration, seed test data. This is the only step where thinking slowly pays compound interest.
- Days 4–7: Core screens, one vertical slice at a time, AI-implemented against prototype screenshots. Resist the redesign urge; match what validated.
- Days 8–9: Billing wiring — plans configured, webhook flow tested with CLI replays, dunning emails checked. The kit did the architecture; you're doing configuration and verification.
- Day 10: Pre-launch checklist (below), redirect the prototype URL, email your early users the new home.
Two weeks of calendar time at part-time intensity, and the version that breaks under real customers never ships.
The four migration mistakes that cost the most
Worth naming explicitly, because every one of them is common:
- Porting the codebase instead of the spec. Copy-pasting generated components into the boilerplate imports the improvisation you're escaping. Port behavior (screenshots, flows, data shapes); let the AI re-implement it in the kit's patterns.
- Improving features mid-port. "While I'm rebuilding this screen anyway…" is how two weeks becomes two months. The validated version ships first; the improved version is week three's reward.
- Leaving billing for last. Billing is the riskiest integration and the one with the longest feedback loops (webhooks, test clocks, edge cases). Wire it mid-migration, not the night before launch.
- Abandoning the prototype's users. Your pre-paying prototype users are the launch asset — migrate their accounts deliberately, tell them what's improving, and redirect the old URL. Losing them in the move forfeits the validation you're building on.
The pre-launch checklist (both routes)
- ID-swap test passes on every endpoint; database rules deny by default
- Webhook handler survives replay, duplication, and out-of-order delivery
- Failed payment → dunning email → access revocation, tested end-to-end with test cards
- Password reset, email change, session revocation all verified by hand
- Transactional email from a configured domain (SPF/DKIM), landing in inboxes
- Error tracking live; deploy rollback rehearsed once; backups restored once
- Tax answered: either registrations/Stripe Tax configured, or a merchant-of-record checkout (Lemon Squeezy/Paddle) doing it for you
- Prototype URL redirects to production (your validation traffic is real traffic)
Choosing your foundation: the short version
Supabase-shaped prototype, want it live fastest → supastarter. First product, Next.js, optimizing for momentum → ShipFast. Teams, permissions, years of maintenance ahead → MakerKit. Different stack entirely → the directory and comparison hub cover Laravel, Django, SvelteKit and beyond — the cross-listing table is the fastest way to see which foundations already ship every item on the checklist you just read.
Frequently Asked Questions
Can I export my code from Lovable or Bolt?
Yes — both support exporting the full codebase, typically straight to a GitHub repo. The strategic question is what the export is for: as a production foundation it inherits every gap of generated code (improvised auth, unhandled billing edge cases, permissive security defaults), but as a reference implementation — validated screens, flows, copy, and data shapes to port onto a real foundation — it's genuinely valuable. Export it either way; it's your spec.
Should I harden my AI prototype or rebuild on a boilerplate?
Harden (Route A) when the app is small, single-user, and your stack confidence is high — budget two to six weeks of subsystem-by-subsystem work. Port onto a boilerplate (Route B) when money, teams, or long-term maintenance are involved — typically one to three weeks, because auth, billing, tenancy, and email arrive pre-built and maintained while you rebuild only the validated features. For anything you'll charge for, Route B is the honest default.
How long does it take to get a Lovable prototype production-ready?
Via the boilerplate route: one to three weeks — a day to deploy and learn the kit, then feature-by-feature porting with Cursor or Claude Code doing most of the implementation against your prototype-as-spec. Via the hardening route: two to six weeks, dominated by auth replacement, webhook-first billing work, and security review. Both estimates assume ruthless scope discipline: migrate what users validated, nothing else.
Do I lose my validation momentum by migrating?
No — the migration protects it. Your validated asset is the learning (which features, which flows, which words), not the generated code, and all of it transfers: the prototype becomes the spec, its URL redirects to production, and early users land on a version that can actually take their money without breaking. What kills momentum is the alternative — shipping the demo and meeting its production gaps in public, with customers attached.