Aplikace z Lovable do produkce: co je potřeba dotáhnout

Krátká odpověď: Lovable postaví funkční webovou aplikaci z textového zadání, včetně databáze a přihlašování. Do produkce pro skutečné zákazníky je obvykle potřeba dotáhnout pět věcí: přístupová pravidla k datům, práci s klíči a platbami, zálohy a oddělená prostředí, výkon při větší zátěži a převzetí kódu do vlastních rukou. Lovable to částečně pokrývá svými skeny, odpovědnost ale zůstává na vás.

Proč na tom záleží

Lovable je dnes běžná cesta, jak si zakladatel nebo manažer postaví první verzi produktu bez vývojáře. Funguje to, a proto přichází další otázka: můžu tuhle verzi pustit zákazníkům?

Odpověď není ano ani ne. Lovable je nástroj pro vibe coding, tedy pro stavbu aplikace popisem v běžném jazyce, a v té roli funguje dobře. Produkce je ale jiná disciplína než prototyp. V MeguMethod vidíme, že první verze aplikace stále častěji vzniká u klienta, a proto jsme k vývoji na míru přidali App as a Service: aplikace dostane pevné základy a klient ji pak dál rozvíjí s AI sám. Tenhle článek je o tom, co je potřeba dotáhnout, než aplikaci uvidí první platící zákazník.

Máte aplikaci z Lovable a chcete vědět, kde stojí? Domluvte si 30 minut online s námi. Projdeme ji a řekneme vám, co bychom dotáhli jako první. Domluvit online call

Co Lovable udělá za vás

Lovable pokrývá víc, než by člověk od nástroje na prompty čekal. Podle jeho dokumentace generuje frontend i serverovou část, napojuje databázi Supabase, řeší přihlašování uživatelů a umí aplikaci publikovat na vlastní doméně.

Má také vestavěné bezpečnostní skeny. Rychlý sken se spouští automaticky při publikaci a kontroluje přístupová pravidla databáze, známé zranitelnosti v knihovnách a rozhraní pro AI nástroje dostupná bez přihlášení. Hloubkový sken, který si musíte spustit sami, kontroluje navíc kód aplikace: řízení přístupu, nebezpečné vstupy, uniknuté klíče, platební logiku a vystavená osobní data. Klíče, které vložíte do chatu, nástroj rozpozná a uloží do zabezpečeného úložiště místo do kódu.

To je solidní základ. Dokumentace Lovable zároveň říká jasně, že za splnění bezpečnostních požadavků odpovídá autor aplikace a že u aplikací s citlivými daty je dobré zvážit další odbornou bezpečnostní kontrolu. Jinými slovy: nástroj vám ukáže problémy, které umí najít. Nezaručí, že jiné nejsou.

Lovable přitom není jediný nástroj tohoto typu. Podobně fungují Bolt nebo Replit a v Česku vzniklo Macaly od zakladatelů Avocode, které podle CzechCrunch (červenec 2025) míří hlavně na lidi bez programování a aplikaci publikuje jedním klikem na vlastní doménu. Pět oblastí níže platí pro aplikace ze všech těchto nástrojů. Liší se jen to, kolik z nich nástroj pohlídá sám.

1. Přístupová pravidla k datům jsou nejčastější díra

Nejcitlivější místo aplikace z Lovable je to, kdo smí číst a měnit která data, a proto ho Lovable kontroluje už v rychlém skenu před publikací. Supabase, databáze, kterou Lovable používá, řídí přístup pravidly na úrovni řádků. Když pravidlo chybí nebo je nastavené jako „všichni můžou vše“, každý přihlášený uživatel může vidět data ostatních.

Dokumentace Lovable doporučuje pravidla pravidelně kontrolovat, hlavně po změnách v přihlašování a databázi. Důvod je praktický: AI při každé větší změně aplikace může pravidla upravit nebo přidat novou tabulku bez nich. Co s tím:

• Pro každou tabulku mít napsané, kdo k ní smí. Jedna věta na tabulku. Když ji neumíte napsat, nevíte, co aplikace chrání.
• Po každé větší změně spustit hloubkový sken znovu. Neběží průběžně.
• Otestovat dvěma účty. Zkusit se z jednoho dostat k datům druhého. Tenhle test za pět minut odhalí víc než hodina čtení kódu.

2. Klíče, platby a vše, co stojí peníze

Aplikace v produkci pracuje s věcmi, které mají cenu: platební brána, e-mailová služba, AI modely placené za použití. Lovable klíče k nim hlídá a volání přes ně navrhuje řešit na serveru. Co už za vás neřeší, je obchodní logika kolem nich.

• Platební logika musí být na serveru a ověřená. Cena, sleva a stav předplatného se nikdy nepočítají v prohlížeči, kde je může kdokoli změnit.
• Limity na placené služby. Když aplikace volá AI model za každou akci uživatele, potřebujete strop. Jinak jeden uživatel nebo jeden skript vygeneruje fakturu, kterou nikdo nečekal.
• Klíče, které kdy byly v chatu nebo v kódu, vyměnit. I když je nástroj přesunul. Co už jednou někde leželo, berte jako prozrazené.

3. Zálohy, prostředí a co se stane při chybě

Prototyp má jedno prostředí a v něm se všechno děje. Produkce potřebuje aspoň dvě: jedno pro zákazníky a jedno, kde se zkoušejí změny. To je ta nejmenší investice s největším efektem.

Důvod je jednoduchý. Když AI mění aplikaci na základě vaší věty, mění ji celou, včetně databáze. Případ z července 2025, kdy AI agent v nástroji Replit smazal produkční databázi během zmrazení změn (popsal ho magazín Fortune), není o jednom nástroji. Je o tom, že experimenty a živá data nepatří na jedno místo.

• Automatické zálohy databáze s vyzkoušenou obnovou. Supabase zálohy nabízí podle tarifu; zkontrolujte, co váš tarif skutečně dělá a jednou obnovu zkuste.
• Oddělené prostředí pro vývoj. Nové funkce se zkoušejí tam, ne na zákaznících.
• Monitorování chyb a dostupnosti. Jednoduchý nástroj, který dá vědět, když aplikace nejede, dřív než napíše zákazník.

4. Výkon: aplikace, která fungovala pro deset lidí

Aplikace z Lovable je postavená tak, aby fungovala. Ne tak, aby fungovala pro tisíc lidí najednou. To není chyba nástroje, je to vlastnost prototypu.

Typické místo, kde to praskne, je databáze: dotazy, které načítají všechno a třídí až v aplikaci, chybějící indexy, nahrávání souborů bez limitu. Při deseti uživatelích to nikdo nepozná. Při stovce se aplikace zpomalí, při tisíci přestane odpovídat.

Nemusíte řešit škálování na miliony. Potřebujete vědět, co se stane při desetinásobku dnešní zátěže, a mít plán, co uděláte, až se to stane. To ukáže jednoduchý zátěžový test.

5. Převzetí kódu: čí ta aplikace vlastně je

Aplikace, která existuje jen uvnitř Lovable, je závislá na jednom nástroji a na tom, že AI pochopí každou další změnu. Lovable umožňuje kód obousměrně synchronizovat s GitHubem, a to je krok, který doporučujeme udělat dřív, než aplikace dostane prvního zákazníka.

Důvod není nedověra k nástroji. Důvod je, že v produkci přijdou požadavky, které popis v běžném jazyce neřeší dobře: integrace na firemní systém, složitější obchodní pravidla, oprava chyby, která se projevuje jen u některých uživatelů. V té chvíli potřebujete člověka, který kód přečte a upraví cíleně. A ten potřebuje kód mít kde.

• Kód v GitHubu pod vaším účtem. Ne pod účtem kolegy, který prototyp stavěl.
• Krátký popis, jak aplikaci spustit a nasadit. Pár odstavců, které ušetří novému člověku den.
• Kontrola kódu, automatická i lidská. Nejdřív automatické AI code review, které projde celý kód a najde možné chyby, pak zkušený vývojář, který posoudí základ. Ne audit, ale odpověď na otázku, jestli dává smysl na aplikaci stavět dál, nebo části přepsat teď, dokud je to levné.

Kdy Lovable stačí a kdy už ne

Lovable stačí, když:

• ověřujete nápad a potřebujete něco ukázat lidem dřív, než do toho dáte peníze,
• aplikace je interní nástroj pro pár kolegů a nepracuje s citlivými daty,
• nejsou v ní platby ani osobní údaje většího počtu lidí,
• máte v týmu někoho, kdo umí kód přečíst a skeny spouští po každé změně.

Je čas přizvat tým, když:

• aplikace má jít k platícím zákazníkům nebo veřejnosti,
• zpracovává platby, zdravotní nebo finanční údaje,
• potřebujete napojení na firemní systémy (účetnictví, CRM, sklad),
• změny přes prompt začínají rozbíjet to, co už fungovalo,
• produkt je základem byznysu a výpadek stojí peníze nebo důvěru.

Náš pohled v MeguMethod: aplikace z Lovable není něco, co se musí zahodit a postavit znovu. Ve většině případů je to dobrý prototyp a jasné zadání zároveň. Práce týmu je dotáhnout pět oblastí výše, ne začínat od nuly.

Pokud jste se našli v druhém seznamu, napište nám pár vět o své aplikaci. Ozveme se s tím, jak bychom postupovali. Poslat poptávku

Jak k tomu přistupuje MeguMethod

V App as a Service bereme aplikaci z Lovable nebo podobného nástroje jako zadání a prototyp v jednom. Nejdřív ji spolu projdeme: přístupová pravidla k datům, práci s klíči, zálohy a prostředí, výkon a stav kódu. Pak postavíme první produkční verzi s architekturou, testy a pravidly pro nasazování a předáme vám kód i nástroje, se kterými další úpravy děláte sami. Každou vaši úpravu pak prověří naše AI i naši experti, takže hlídají bezpečnost, architekturu i funkčnost.

Prvním klientem, se kterým jsme tento model vyzkoušeli, byla brněnská digitální účetní firma Rocketas. Potřebovala interní nástroj a měla v týmu člověka, který ho chtěl po spuštění dál rozvíjet. U citlivých klientských dat ale chtěla jistotu, že aplikace stojí na pevných základech. Přesně tohle rozdělení práce v modelu funguje: oni znají svůj provoz a zákazníky lépe než my, my známe architekturu a bezpečnost. Jak funguje App as a Service

Další krok

Máte aplikaci z Lovable a chcete vědět, co jí chybí do produkce? Podívejte se, jak funguje App as a Service, nebo si rovnou domluvte 30 minut online. Pokud si to chcete nejdřív projít sami, použijte náš checklist připravenosti AI-built aplikace pro skutečné uživatele.