Lovable Rescue
Off Lovable, with a dev partner who knows the codebase.
A productized rebuild that gets your Lovable v1 onto a maintainable stack you own — plus the option to keep me on as the dev partner who ships v2 with you.
What you get
A repo you actually own
Schema reconciled into proper migrations. Edge Functions in deployable source. Frontend on Astro / Next — not whatever Lovable picked. Type-safe end-to-end. Tests on the paths users actually hit.
Supabase in your org, not Lovable's
All credentials handed over. DNS pointed at your infra. Lovable kept warm as a 24h fallback during cutover, then turned off. No platform lock-in — fork it the day after if you want.
A dev partner who knows the codebase
Optional 90-day Telegram partnership starting the day the rebuild ships. Async-first. No retainer minimums. The same person who built it ships the next feature.
Three tiers. Pick where you land.
Every engagement starts with Tier 1 — the rebuild. After that, you take the codebase and walk, stay on a light retainer, or keep me on as the embedded dev partner. Pick one, or pick none. The codebase is yours either way.
Tier 1 — Rebuild
€2,000 — €4,000
One-shot · 5 days to 4 weeks
Two sub-scopes. Schema-only (€2k) moves your data; full rebuild (€4k) takes the whole thing off Lovable — schema, Edge Functions, frontend, DNS, plus a 14-day stabilization window.
- Supabase project migrated into your org
- Migration history reconciled into version-controlled `supabase/migrations/`
- Edge Functions ported to deployable source
- Frontend ported to Astro / Next / Remix (full rebuild only)
- DNS cutover at 24h TTL with Lovable kept warm as fallback
- 14-day stabilization window on any cutover-related issue (full rebuild)
Tier 2 — Maintain
€1,500 / month
Async retainer · cancel with 2 weeks notice
Keep-the-lights-on after the rebuild. You ship v2 yourself; this is the safety net for the things you don't want to think about.
- Up to 20 dev-hours of small fixes / patches per month
- Dependency upkeep + security-advisory triage within 48h
- Monthly Sentry + Supabase + Stripe webhook health review
- Telegram channel for async questions, same-day EU business hours
- No new-feature delivery — that's Tier 3
Tier 3 — Build with me
€2,000 — €8,000 / month
Slider retainer · embedded dev partner
Builder retainer applied to a Lovable-rescue alumnus. Same envelope, same slider, same €50/h leveraged rate — except the partnership starts with the codebase known cold.
- 40h dev-h envelope at the €2k floor → 160h at the €8k soft cap
- Meeting cadence scales with the slider (2h/mo → 8h/mo)
- Feature delivery in the rebuilt codebase — async-first, Telegram-driven
- Charged on `manual_time + realistic_estimate_per_task`, both at €50/h
- Standalone, or as a 90-day bundle with a Tier 1 rebuild (rebuild drops to €3k)
Bundle discount: buy a Tier 1 full rebuild alongside a 3-month Tier 3 commitment and the rebuild drops to €3k. EU B2B invoiced ex-VAT under reverse-charge. Engagements start with a free 15-minute fit call before any payment.
Why founders leave Lovable
Lovable is a fantastic prototyping environment. The friction starts after product-market fit, when "I can't do that on Lovable" begins to gate real engineering decisions.
Vendor pricing creep
Lovable Cloud usage charges scale with edge function invocations and DB rows. At any meaningful traffic, your own Supabase + a $5/mo VPS undercuts it by an order of magnitude.
Invisible to AI crawlers
Lovable ships a React SPA. GPTBot, ClaudeBot, PerplexityBot do not execute JavaScript. Your marketing pages are effectively invisible in the AI discovery layer (AEO).
No real CI/CD control
You cannot run the Lovable build under your own GitHub Actions, gate on tests, or stage PR previews. Every deploy is a Lovable button click.
No direct Postgres access
Lovable Cloud does not expose the Supabase Postgres URL. Schema audits, complex migrations, and bulk imports go through their UI or are not possible at all.
Locked-in auth
Migrating users out without losing their passwords is undocumented. Done wrong, every user has to reset their password on day one of the migration.
The 4-PR migration pattern
The marketing-site half of every Tier 1 rebuild is sequenced into four pull requests. Order matters — each PR keeps the site green so you can pause at any point and still have a deployable artifact. Numbers below taken verbatim from the public RankRush commit history.
Scaffold + brand tokens
Astro 6 + Tailwind v4 + MDX project initialised. Brand colour tokens, fonts, and dark-mode scaffolding land in `global.css`. Pricing page first — proves the schema.org Offers shape end-to-end before you touch the rest of the site.
Port the React landing page
Lovable's SPA landing page becomes a single Astro page with zero client-side JS. Hero, features, social proof, CTA — all server-rendered HTML. Lighthouse goes from ~60 to 100.
AI discoverability layer
Sitemap with priorities + lastmod, `robots.txt` with explicit AI-crawler allowlist (GPTBot, ClaudeBot, PerplexityBot, etc.), default OG image, JSON-LD Organization + Service schema. The piece Lovable's SPA could not deliver.
Deploy pipeline + secondary pages
GitHub Actions deploys to your VPS (or Vercel/Netlify) on push. PR previews wired. About / Privacy / Terms / 404 ported from React. Lovable can now be paused — your marketing site is fully self-managed.
The data-layer half (Supabase schema + edge functions + auth users) runs in parallel and culminates in a DNS apex flip with sub-5-minute TTL rollback. Both halves are documented in the lead-magnet playbook below.
What every rebuild ships
Every Tier 1 engagement (Schema-only or Full Rebuild scoped accordingly) ships from the same six-artifact spine. No "we'll see what we have time for" — the scope is fixed.
Own Supabase project
Schema, edge functions, auth users (passwords preserved), and storage migrated to a Supabase project YOU own. Lovable Cloud disconnected at the end.
Astro marketing site
Public marketing pages ported off Lovable into a self-hosted Astro repo. Zero JS where possible — AI crawlers can read it.
Independent deploy pipeline
GitHub Actions workflows for marketing site + app. PR previews + production deploys. No Lovable in the critical path.
OAuth + secrets handover
Stripe / Google / Reddit redirect URIs updated. Secrets handed over via org-invite pattern — original owner pastes values; I never see them.
DNS cutover playbook
TTL choreography, DNS-01 cert issuance, apex flip with rollback plan. Smoke-tested from multiple resolvers before Lovable is paused.
Migration runbook
Markdown report documenting every drift fix, every secret moved, every redirect updated. Hand to your team so they can repeat the pattern.
Free playbook
Migrating off Lovable in a weekend — the playbook
The same 6-step migration pattern shipped on RankRush, written up as a self-serve guide. Pre-flight checklist, schema-drift fixes, the auth-password-preservation trick, OAuth-redirect checklist, DNS cutover choreography, and rollback playbook. About 25 pages of operational detail.
PDF rendering pipeline is still being wired. Email hi@gabegiro.com if you want the source MDX in the meantime.
Questions about the rescue
Will my users have to reset their passwords?
No. The migration uses an `auth.users` + `auth.identities` shuttle pattern that preserves the bcrypt password hashes verbatim. Your users log in on day one with the same credentials they had on Lovable. This was proven on a 37-user migration in April 2026 — see the RankRush case study.
How long does it take?
Two-week elapsed window for a typical Lovable project (one app + one marketing site + a CLI). Most of the wall-clock time is DNS TTL bake-in, OAuth-redirect propagation, and waiting on you to paste secrets. Hands-on engineering is ~5 working days.
Do you ever see my production secrets?
No. The migration uses a secret-handover pattern where I invite you to the new Supabase org as a Developer, you paste secret values directly into the Edge Function secrets panel. I see field names, never values. Stripe / Google / Reddit credentials follow the same pattern.
What if something breaks during cutover?
Cutover happens with Lovable still running. I keep both stacks live in parallel for 24–48 hours, smoke-test from multiple DNS resolvers, and only pause Lovable once your monitoring is clean. The DNS plan includes a rollback step with sub-5-minute TTL.
Can I keep using Lovable for my next prototype?
Yes. Lovable is a great prototyping tool. The migration is for projects that have hit product-market fit and need own-the-stack control. Many clients keep Lovable as their R&D sandbox after the migration.
What stacks does this work for?
Currently scoped to Lovable Cloud (Supabase + edge functions + React/Vite frontend). Other backends-as-a-service (Bubble, Webflow + Memberstack, etc.) are out of scope for v1 — different export shapes. Get in touch if you want to be the first migration of a different stack.
Why is the rebuild productized at a flat rate?
Migration scope is well-defined: schema + edge functions + auth users + marketing site + DNS. The flat rate eliminates the "unknown surprise" risk that makes hourly migrations expensive. If your project genuinely exceeds the scope (multi-tenant complexity, custom Postgres extensions), I quote a specific add-on instead of running the meter.
Is the RankRush case study real?
Yes. RankRush.ai was migrated off Lovable Cloud on 2 May 2026 — 103 schema migrations + 32 edge functions + 37 auth users + a separate Astro marketing site, all live and serving traffic. The 4-PR sequence on this page is taken verbatim from the public commit history of github.com/GabeGiro/rankrush-marketing.
Ready to talk?
Start with a free 15-minute discovery call. No commitment, no pitch deck — just an honest conversation about your problem and how I can help.