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. Czego nie mieli — to czegokolwiek, co przypominało produkcję.

Bez CI/CD — każda zmiana wymagała ręcznego wdrożenia. Bez monitoringu — nie było jak sprawdzić, czy aplikacja jest zdrowa, i nie było alertu, jeśli nie była. Pliki leżały w Supabase Storage, co wystarczało na skali prototypu, ale miało uderzyć w limity kosztów i wydajności w momencie, gdy 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ł OK. Pytanie brzmiało, jak szybko możemy 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 naszym artykule o ukrytych kosztach.
• Zero monitoringu i alertów. Jeśli aplikacja by padła, nikt by się nie dowiedział, dopóki użytkownik nie zgłosi.
• Pliki tylko w Supabase Storage. OK przy skali prototypu; drogie i kruche przy skali realnych użytkowników.
• Brak przeglądu bezpieczeństwa. Żaden nie został wykonany. Plan był taki, żeby launchować; ryzyko było nieznane.

Co zrobiliśmy

Dwa do trzech tygodni od pierwszej rozmowy do przekazania produkcji. Prowadziliśmy trzy ścieżki równolegle: pass bezpieczeństwa, budowę infrastruktury i migrację plików.

1. Audyt bezpieczeństwa OWASP Top 10. Strukturalny pass 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. Pisane dokumenty dla zespołu klienta: jak wdrażać, jak rotować poświadczenia, jak płyną 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 „w stylu działu marketingu", ale taka, która wytrzymuje, gdy pojawiają się realni użytkownicy. Co zmieniło się konkretnie:

Założyciel nie musiał już być obecny, żeby mogło się odbyć wdrożenie. Zespół miał alerty na miejscu, zanim ich potrzebował. Plan storage'u przestał być kosztową niespodzianką czekającą w ukryciu.

Co powiedzielibyśmy 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 pass bezpieczeństwa przed launchem, nie w trakcie. OWASP Top 10 to punkt startu, nie sufit — ale zaczynając tam, łapiesz większość tego, co naprawdę atakuje 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 dnia zerowego, nie w dniu pierwszej awarii. Zawsze to trzygodzinne zadanie, gdy robisz je zawczasu. I wielodniowe, gdy robisz je, gdy coś się pali.
• 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 jej potrzebujesz; jest dziesięć razy tańsza niż wersja paniczna.
• Udokumentuj powierzchnię przekazania, nawet jeśli „przekazanie" to przyszły Ty. Osobą, która będzie walczyć bez dokumentacji wdrożenia, zazwyczaj jest wersja Ciebie sprzed trzech miesięcy.

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