Z Lovable na produkcję w 2 tygodnie

Klient przyszedł do nas z czymś imponującym i czymś niekompletnym jednocześnie: działającym prototypem PropTech SaaS, zbudowanym w całości w Lovable na React i Supabase, który w podglądzie wyglądał przekonująco. Brakowało im natomiast czegokolwiek, co przypominałoby produkcję.

Bez CI/CD — każda zmiana wymagała ręcznego wdrożenia. Bez monitoringu — nie było jak sprawdzić, czy aplikacja działa poprawnie, ani żadnego alertu, gdyby przestała. Pliki leżały w Supabase Storage, co wystarczało na skali prototypu, ale lada chwila miały przekroczyć limity kosztów i wydajności, gdy tylko pojawią się realni użytkownicy. Nikt nie spojrzał na kod pod kątem bezpieczeństwa. A launch się zbliżał.

Pytanie nie brzmiało, czy przebudować. Prototyp był w porządku. Pytanie brzmiało, jak szybko uda się podłożyć pod niego infrastrukturę produkcyjną, żeby klient mógł faktycznie wpuścić użytkowników.

Wyzwanie

• Działający prototyp, bez drogi na produkcję. Aplikacja działała w podglądzie Lovable. Nie było planu, jak miałaby działać gdziekolwiek indziej.
• Tylko ręczne wdrożenia. Każda zmiana wymagała kogoś z właściwymi uprawnieniami, kto wypchnie ją ręcznie — wzorzec założyciel-jako-infrastruktura opisany w moim artykule o ukrytych kosztach.
• Zero monitoringu i alertów. Gdyby aplikacja padła, nikt by się nie dowiedział, dopóki nie poskarżyłby się jakiś użytkownik.
• Pliki tylko w Supabase Storage. OK przy skali prototypu; drogie i kruche przy skali realnych użytkowników.
• Brak przeglądu bezpieczeństwa. Nikt go nie przeprowadził. Plan zakładał launch; ryzyko pozostawało nieznane.

Co zrobiłem

Dwa do trzech tygodni od pierwszej rozmowy do przekazania produkcji. Prowadziłem trzy ścieżki równolegle: przegląd bezpieczeństwa, budowę infrastruktury i migrację plików.

1. Audyt bezpieczeństwa OWASP Top 10. Uporządkowany przegląd wg OWASP Top 10. Problemy krytyczne zidentyfikowane, spriorytetyzowane według ryzyka biznesowego i naprawione. (Konkretne wyniki nie są publikowane — mogłyby zidentyfikować klienta.)
2. Pipeline CI/CD. Automatyczne testy i wdrożenie przy każdym pushu. Koniec z ręcznymi wdrożeniami; koniec z wąskim gardłem jednej osoby.
3. Konfiguracja serwerów produkcyjnych. Właściwe rozdzielenie środowisk — staging i produkcja jako odrębne środowiska, każde ze swoją konfiguracją. Koniec z „aplikacja jest tam, gdzie akurat jest przeglądarka założyciela”.
4. Monitoring i alerty. Monitoring błędów i wydajności 24/7, z alertami kierowanymi we właściwe miejsce. Awarie są znane w minutach, nie dniach.
5. Migracja na AWS S3 + CloudFront. Pliki przeniesione z Supabase Storage na S3 z CDN-em CloudFront. Taniej, szybciej, a sufit pojemności znika.
6. Konfiguracja domeny, SSL i infrastruktury. Porządne HTTPS, DNS, zmienne środowiskowe i produkcyjny build — niezbyt efektowna robota, która odróżnia wdrożoną aplikację od dema.
7. Dokumentacja przekazania. Pisemna dokumentacja dla zespołu klienta: jak wdrażać, jak rotować poświadczenia, jak przepływają dane, co jest kruche i dlaczego. Dokumentacja to to, co sprawia, że następny zatrudniony inżynier jest skuteczny pierwszego dnia, a nie trzydziestego.

Rezultaty

Na koniec zlecenia aplikacja była naprawdę gotowa na produkcję — nie „gotowa według działu marketingu”, ale taka, która wytrzymuje, gdy pojawiają się realni użytkownicy. Konkretnie zmieniło się to:

Założyciel nie musiał już być obecny, żeby mogło się odbyć wdrożenie. Zespół miał alerty wdrożone, zanim okazały się potrzebne. Kwestia plików przestała być kosztową niespodzianką czającą się w przyszłości.

Co powiedziałbym innemu założycielowi w tej samej sytuacji

Studia przypadków są najbardziej użyteczne, gdy dają się uogólnić. Jeśli patrzysz na prototyp z Lovable, Bolt lub v0, który za chwilę spotka realnych użytkowników, kształt problemu zwykle jest ten sam. Krótka lista, wydestylowana z tego zlecenia:

• Zrób przegląd bezpieczeństwa przed launchem, nie w jego trakcie. OWASP Top 10 to punkt wyjścia, nie sufit — ale zaczynając od niego, wyłapujesz większość tego, co naprawdę uderza w młode produkty SaaS.
• Traktuj ręczne wdrożenia jak podatek założyciela. Jeśli jesteś jedyną osobą, która potrafi wdrożyć, nie jesteś tylko inżynierem — jesteś systemem wdrażania. CI/CD to inwestycja na tydzień, która zwraca ten czas na zawsze.
• Włącz monitoring od dnia zero, a nie w dniu pierwszej awarii. Zrobiony zawczasu, to zawsze zadanie na trzy godziny. Robiony w trakcie pożaru — na kilka dni.
• Załóż, że wyrośniesz z managed-service storage. Supabase Storage, Firebase Storage, Vercel Blob — wszystkie OK na start, wszystkie mają sufit. Zaplanuj ścieżkę migracji, zanim będzie potrzebna; wyjdzie dziesięć razy taniej niż robienie tego w panice.
• Opisz przekazanie, nawet jeśli „następnym” jesteś przyszły Ty. Osobą, która bez dokumentacji wdrożenia będzie się męczyć, zazwyczaj okazuje się Ty sprzed trzech miesięcy.

Dla dłuższej wersji tych wzorców zobacz moje artykuły o niewidzialnych bugach w kodzie AI i kiedy przekazać swoje MVP.