Lovable.dev umožňuje nasadit fungující aplikaci za víkend. Tato superschopnost je reálná a je to důvod, proč Lovable doporučujeme pro prototypy a rané ověření. Jakmile ale aplikace začne brát reálné peníze od reálných uživatelů, stejná šablona, co vás dovedla k launchi, se stane úzkým hrdlem.
Tato příručka prochází sedm kroků migrace Lovable prototypu na produkční Nuxt 3 nebo Next.js aplikaci. Je to stejný proces, který používáme pro klientské zakázky, zhuštěný do průvodce, podle kterého můžete postupovat sami nebo ho použít k briefování vývojářského týmu.
Proč vůbec migrovat?
Tři důvody. První, bezpečnost: defaultní Supabase RLS v Lovable je permisivní způsobem, který nepřežije reálný bezpečnostní audit. Druhý, výkon: generovaný kód používá Supabase z klienta způsobem, který neškáluje přes pár stovek souběžných uživatelů. Třetí, rozšiřitelnost: jakmile potřebujete custom integraci, ne-šablonový platební flow nebo funkci, kterou Lovable UI neumí vyjádřit, narazíte na zeď.
Pokud tyto problémy nemáte, migrovat nemusíte. Lovable je v pořádku, jaký je. Spouštěcím momentem bývá konkrétní událost: bezpečnostní review, scaling incident, enterprise zákazník chtějící SOC 2, nebo požadavek na funkci, kterou AI neumí spolehlivě vygenerovat.
Krok 1: Audit Lovable projektu
Než napíšete jakýkoliv nový kód, pochopte, co máte. Exportujte Lovable kódovou bázi. Zmapujte každou Supabase tabulku, každé Row Level Security pravidlo, každou env proměnnou a každou externí integraci. Sepište user flow, které musí cutoverem projít beze změny - obvykle signup, login, platba a hlavní value-delivery flow.
Tohle je obvykle 2-3 denní cvičení. Přeskočte ho a najdete chybějící data nebo rozbité flow během cutoveru.
Krok 2: Vyberte cílový stack
Nuxt 3 na Cloudflare Pages nebo Next.js na Vercel jsou běžné volby pro SaaS migrace. Obě fungují dobře, obě mají vynikající Stripe a Supabase ekosystémy, obě deployují rychle. Volba obvykle závisí na tom, se kterým frameworkem je váš tým pohodlnější.
Zachovejte Supabase jako databázi, pokud nemáte konkrétní důvod přejít jinam. Supabase Postgres je stejný Postgres, jaký byste použili kdekoliv jinde; problémy s Lovable aplikacemi jsou v RLS konfiguraci a jak aplikační kód mluví se Supabase, ne v Supabase samotném.
Krok 3: Znovu vytvořte schéma a zpřísněte RLS
Vytvořte nový Supabase projekt (nebo nové schéma ve stávajícím). Přehrajte všechny definice tabulek ze zdrojového projektu. Pak přepište každé RLS pravidlo.
Princip: anon role by nikdy neměla mít insert, update nebo delete na tabulkách s uživatelskými daty. Authenticated uživatelé by měli mít přístup jen k vlastním řádkům. Cokoliv, co potřebuje překračovat hranice řádků - admin akce, cron joby, customer support nástroje - by mělo běžet přes service-role z backendu, nikdy z klienta.
Tato jediná změna typicky vyřeší 70-80 % bezpečnostních nálezů v Lovable auditu.
Krok 4: Implementujte UI
Většina Lovable aplikací používá Tailwind a shadcn/ui, oba přenositelné na Nuxt a Next. Migrace je stránka po stránce: implementujte nejprve nejnavštěvovanější routes, pak méně navštěvované, pak admin nástroje. Vizuální design zachovejte identický - uživatelé by si cutoveru neměli všimnout.
Čas na stránku se hodně liší. Jednoduchý list-detail pohled může trvat 2 hodiny. Komplexní dashboard s grafy a filtry den. Plánujte podle toho.
Krok 5: Nahraďte šablonové platby reálným Stripe
Lovable integrace plateb je demo. Funguje pro ukázku investorům, že peníze chodí, ale chybí jí produkční esenciály: ověření podpisu webhooks, idempotency keys na každém payment intentu, robustní state machines subscriptions, customer portal access, automatické zpracování refundů, dunning email logika pro selhané platby.
Implementujte Stripe pořádně. Použijte Stripe webhook CLI na lokální testování. Mějte checklist failure modes (výpadek sítě během checkoutu, double-submit, expirovaná karta, disputed charge) a ověřte každý. Tohle je jediný nejdražší krok, který je třeba dostat správně později.
Krok 6: Přidejte observability a CI/CD
Sentry chytá errory v produkci. Axiom nebo Logflare agreguje logs dotazovatelným způsobem. Uptime monitor (Better Stack, Pingdom) říká, když aplikace spadne. Tyto tři věci dohromady vám dají viditelnost, kterou Lovable nemá.
CI/CD na GitHub Actions: každý PR pouští lint, typecheck a testy. Každý PR dostane preview deploy. Staging environment zrcadlí produkci pro QA. Deploy do produkce se stane nudným, což je to, co chcete.
Krok 7: Cutover
DNS cutover je viditelná událost, ale nejmenší krok. Vyberte okno s nízkým provozem. Nechte Lovable verzi živou a DNS přepnutelnou 48 hodin jako rollback variantu. Mějte otevřený monitoring dashboard s error rate, úspěšností platby a metrikami vašeho hlavního user flow.
Komunikujte uživatelům, že probíhá údržba. Samotnou změnu udělejte neviditelnou - stejné URL, stejné UI, stejná data, stejné přihlášení. Dobře udělaný cutover trvá pod 30 minut a uživatelé si toho nevšimnou.
Co to typicky stojí
Typická Lovable-to-production migrace pro SaaS s 1-3 hlavními user flow vyjde na 220 000-450 000 Kč za 4-8 týdnů. Větší aplikace jdou výš. Audit a plánovací fáze je fixní cenový vstupní bod (15 000-35 000 Kč) a řekne vám skutečný rozsah, než se zavážete k rozpočtu.
Detaily na Lovable do produkce, nebo si přečtěte související průvodce Co je vibe coding a kdy vaše AI aplikace potřebuje záchranu? pro kontext, kdy je tato migrace skutečně rozumná.