Prototyp w Lovable działa, klikasz i wszystko śmiga. Tylko że zanim aplikacja z Lovable trafi na produkcję, zespół musi przejąć kod i bazę danych, przejrzeć bezpieczeństwo i zdecydować: rozwijamy prototyp czy budujemy od nowa? Działający prototyp sprawdza pomysł. Prawdziwi klienci to już inna liga, jeśli chodzi o niezawodność.
Vibe coding w firmie, czyli budowanie aplikacji poleceniami w języku naturalnym w Lovable, Bolt i podobnych narzędziach, mocno skraca drogę do pierwszej wersji. I dobrze. Ten tekst piszę dla właściciela firmy albo product managera, który ma taki prototyp i szuka zespołu do dalszego rozwoju.
Spis treści
Gdzie jest kod i baza prototypu, i kto ma do nich dostęp?
Kod projektu siedzi w Lovable. Można go jednak podpiąć do repozytorium GitHub z synchronizacją dwukierunkową albo pobrać, jeśli masz płatny plan. Jak opisuje dokumentacja integracji Lovable z GitHubem, repozytorium tworzone przy połączeniu jest domyślnie prywatne. Sprawdź jednak, czy leży w organizacji firmy, a nie na prywatnym koncie osoby, która klikała prototyp.
Uwaga na odłączanie integracji. Po rozłączeniu synchronizacja się kończy: repozytorium zostaje na GitHubie, ale kolejne zmiany zapisują się już tylko w Lovable. Tak łatwo o dwie rozjechane wersje kodu. Dlatego przed przekazaniem kodu ustal jedno źródło prawdy. Spisz też wszystkie osoby i konta z dostępem do Lovable, GitHuba i bazy danych. Zbędne uprawnienia? Odbierz.
Co zawiera eksport bazy, a co trzeba przenieść ręcznie?
Pod spodem prototypu pracuje PostgreSQL. Według dokumentacji eksportu bazy w Lovable eksport obejmuje strukturę i dane, razem z kontami użytkowników. Brzmi kompletnie, ale nie jest. Działająca aplikacja opiera się na kilku rzeczach, których w eksporcie nie znajdziesz. Osobno trzeba przenieść:
- pliki zapisane w storage, np. zdjęcia i dokumenty dodane przez użytkowników,
- kod edge functions, czyli funkcji uruchamianych po stronie serwera,
- sekrety i klucze API do usług zewnętrznych,
- konfigurację logowania i dostawców uwierzytelniania.
Przeniesienie backendu do innego dostawcy to robota dla programisty, nie jedno kliknięcie. Wpisz ją do planu i budżetu od pierwszego dnia. Bo bez tych elementów aplikacja po migracji po prostu nie wstanie.
Przegląd bezpieczeństwa aplikacji wygenerowanej przez AI: sekrety, RLS i logika serwera
Zasada numer jeden: kod frontendu działa w przeglądarce, więc nie może decydować o bezpieczeństwie. A każdy sekret, który w nim wyląduje, traktuj jak ujawniony. Tak to ujmują zalecenia bezpieczeństwa Lovable i od tego trzeba zacząć przegląd. Przeszukaj kod frontendu pod kątem kluczy i tokenów, unieważnij je i przenieś na serwer.
Drugi obszar to RLS (Row Level Security), czyli reguły, które określają, jakie rekordy w bazie widzi dany użytkownik, plus uprawnienia ról. Pytanie kontrolne jest proste: czy zalogowany klient może odczytać albo zmienić cudze dane? Jeśli tak, masz problem. Walidacja po stronie klienta też niczego nie chroni. Reguły biznesowe i kontrola danych mają działać na serwerze. O tym, jak w praktyce wygląda naprawianie kodu generowanego przez AI, piszemy szerzej w osobnym tekście.
Lista kontrolna przed przejęciem kodu aplikacji
Zanim zespół przejmie kod, przechodzi przez kilka obszarów, które w prototypie zwykle nikogo nie obchodziły:
- Własność repozytorium i bazy: organizacja firmy, lista kont z dostępem.
- Sekrety i klucze w kodzie frontendu.
- Reguły RLS i uprawnienia ról.
- Logika po stronie serwera zamiast w przeglądarce.
- Testy automatyczne, których zwykle brakuje.
- Kopie zapasowe bazy i plików oraz sposób ich odtwarzania.
- Koszty usług działających w tle: baz, funkcji, API zewnętrznych.
- Dane osobowe: jakie są zbierane, gdzie trafiają i kto je widzi.
Aplikacja, która przetwarza dane klientów, podlega przepisom o ochronie danych. W Unii Europejskiej to RODO, nie ma co się oszukiwać, że prototyp jest z tego zwolniony. Usługi w tle to z kolei stały element utrzymania aplikacji z AI. Policz od razu koszty utrzymania aplikacji po wdrożeniu, zanim zaskoczy cię pierwsza faktura.
Rozwijać prototyp czy zbudować aplikację od nowa?
Rozwijać, jeśli struktura kodu i bazy jest czytelna, a poprawki bezpieczeństwa są punktowe. Jeżeli trzeba ruszać fundamenty, lepiej potraktować prototyp jako specyfikację. Co przemawia za rozwojem? Spójny model danych. Logika, którą da się przenieść na serwer. I stos technologiczny, w którym zespół czuje się jak u siebie.
Za budową od nowa przemawia logika rozsmarowana po całym frontendzie, brak kontroli dostępu albo plany funkcji, których obecna architektura nie udźwignie. Ale nawet wtedy prototyp nie ląduje w koszu. Pokazuje przepływy, ekrany i potrzeby użytkowników, które już się sprawdziły, a to sporo warte. Na takim materiale może powstać pierwsza wersja produktu na solidnych podstawach.
Jak przekazać prototyp aplikacji AI zespołowi programistów?
Start: dostęp do repozytorium firmy, eksport bazy i lista elementów spoza eksportu. Meta: wspólny przegląd kodu. Po drodze przygotuj krótki opis celu aplikacji, listę funkcji, z których klienci naprawdę korzystają (nie tych, które miały być), znane błędy i wykaz kont oraz usług zewnętrznych.
Zespół, który przejmuje projekt, robi przegląd, planuje migrację backendu, dopisuje testy, ustawia kopie zapasowe i bierze na siebie dalsze utrzymanie. Szukasz wykonawcy na każdy z tych etapów? Opisujemy, jak wygląda u nas tworzenie oprogramowania na zamówienie.
Aplikacja z Lovable na produkcję: od czego zacząć
Prototyp zbudowany poleceniami w języku naturalnym to cenny dowód, że pomysł ma sens. Stabilności pod obciążeniem prawdziwych użytkowników jednak nie gwarantuje. Najpierw przegląd według listy kontrolnej, dopiero potem decyzja: rozwój albo przebudowa. W sumie cała rzecz sprowadza się do trzech spraw. Aplikacja z Lovable na produkcję wymaga uporządkowania własności kodu, bezpieczeństwa i decyzji o dalszej architekturze.
Najczęstsze pytania
Czy kod z Lovable należy do mnie i mogę go przenieść?
Kod da się zsynchronizować z repozytorium GitHub albo pobrać na płatnych planach. Pilnuj tylko, żeby repo leżało w organizacji firmy, a nie na prywatnym koncie twórcy. Wtedy przekazanie projektu zespołowi to w zasadzie nadanie uprawnień i tyle.
Czy eksport bazy z Lovable wystarczy do przeniesienia aplikacji?
Nie. Eksport obejmuje strukturę, dane i konta użytkowników, ale nie ma w nim plików w storage, kodu edge functions, sekretów, ustawień logowania ani kluczy API. To programista przenosi osobno.
Czy aplikację zbudowaną w Bolt przejmuje się tak samo?
Ogólnie tak, zasady przeglądu są te same: kod, baza, sekrety, uprawnienia i testy. Szczegóły eksportu zależą już od konkretnego narzędzia, więc przed przekazaniem projektu zajrzyj do jego dokumentacji.
