Aplikacja z Lovable nie działa na produkcji? Jak przygotować ją do produkcji

Dlaczego moja aplikacja z Lovable działa w podglądzie, a psuje się na produkcji?

W podglądzie są Państwo jednym użytkownikiem, z danymi testowymi, klikającym ścieżki, które Państwo zbudowali. Produkcja dodaje obcych ludzi, prawdziwe pieniądze i czas. Awarie, które z tego wynikają, rzadko są winą złej linijki kodu. To brakujące decyzje: kto może czytać który wiersz, co się dzieje, gdy płatność się powiedzie, ale przeglądarka zostanie zamknięta, i kto zauważy, że e-maile przestały wychodzić.

• Wycieki danych między użytkownikami. Supabase udostępnia tabelę w eksponowanym schemacie do odczytu i zapisu każdej roli z uprawnieniem do niej, chyba że zabezpieczenia na poziomie wierszy są włączone, a ich polityki poprawne.
• Sekrety w przeglądarce. Klucz publiczny (anon) można bezpiecznie udostępnić; klucz service role omija każdą politykę RLS i nigdy nie może trafić do przeglądarki.
• Płatności, które się rozjeżdżają. Checkout wracający na stronę sukcesu nie jest dowodem płatności. Serwer musi potwierdzić ją w Stripe.
• Zmiany, które psują stare funkcje. Bez testów regresji każdy nowy prompt może cofnąć coś, co działało w zeszłym tygodniu.
• Ciche awarie. Bez monitoringu klienci znajdą błąd przed Państwem.

Nic z tego nie dotyczy wyłącznie Lovable. Każda szybka pierwsza wersja, napisana przez człowieka czy przez AI, ma zwykle te same luki, bo zadaniem prototypu jest udowodnić pomysł, a nie przetrwać kontakt z obcymi.

Czy aplikacja z Lovable jest gotowa na produkcję od razu?

Częściowo. Dokumentacja Lovable mówi, że po podłączeniu Supabase Lovable pisze polityki zabezpieczeń na poziomie wierszy dla tabel, przy publikacji uruchamia szybki skan bezpieczeństwa (przegląd bazy danych, np. tabel bez RLS lub reguł przepuszczających wszystkich, audyt zależności i kontrolę serwera MCP) oraz oferuje głębszy skan uruchamiany ręcznie. Mówi też wprost, że skan nie gwarantuje pełnego bezpieczeństwa i nie zastępuje gruntownego przeglądu bezpieczeństwa.

To uczciwy opis. Skan może powiedzieć, że polityka istnieje. Nie powie, czy polityka odpowiada regułom biznesowym – na przykład że administrator zespołu widzi faktury, a członek zespołu nie. Ten osąd to w praktyce gotowość produkcyjna.

Co oznacza gotowość produkcyjna dla aplikacji z Lovable?

Jak bezpiecznie dodać płatności Stripe do aplikacji z Lovable?

Integracja Stripe w Lovable działa przez funkcje edge, więc tajny klucz nie trafia do aplikacji, a płatności jednorazowe otwierają Stripe Checkout. Według dokumentacji Lovable domyślnie nie konfiguruje webhooków: aplikacja sprawdza status płatności i subskrypcji bezpośrednio w Stripe, a webhooki można dodać na życzenie. Zaznacza też, że identyfikatory cen różnią się między trybem testowym a produkcyjnym, więc uruchomienie wymaga nowych.

Sprawdzanie statusu na żądanie wystarcza przy prostym checkoucie. Gdy sprzedają Państwo subskrypcje, zwykle potrzebne są też webhooki, bo odnowienia, odrzucone karty i anulowania dzieją się, gdy użytkownika nie ma na stronie. Dokumentacja Stripe precyzyjnie opisuje, jak robić to bezpiecznie:

• Weryfikować każdy webhook nagłówkiem Stripe-Signature i sekretem endpointu, na surowej treści żądania.
• Spodziewać się duplikatów i zdarzeń w złej kolejności. Zapisywać identyfikatory przetworzonych zdarzeń, aby każde obsłużyć raz (idempotentność).
• Pamiętać, że Stripe ponawia nieudane dostarczenia w trybie produkcyjnym przez maksymalnie trzy dni, więc zepsuty endpoint po naprawie może odtworzyć zdarzenia z kilku dni.
• Trzymać sekrety testowe i produkcyjne osobno. Obiekty z jednego trybu nie są widoczne w drugim.

Naprawić samodzielnie, zatrudnić freelancera czy zespół?

Jeśli aplikacja ma garstkę użytkowników, bez płatności i wrażliwych danych, można przejść przez powyższą tabelę samodzielnie, korzystając ze skanu bezpieczeństwa Lovable i Security Advisora Supabase, który wskazuje tabele z wyłączonym RLS i polityki przepuszczające wszystkich. To dobrze spędzone popołudnie.

Freelancer lub sprint ratunkowy o stałej cenie pasuje do znanego, ograniczonego problemu: jednej zepsutej integracji, jednego audytu. Często to tańsza opcja dla takiego zadania. Jednorazowa poprawka nie daje jednak kolejnych sześciu miesięcy: testów, wydań, aktualizacji i incydentu poza godzinami pracy. Tę ciągłą odpowiedzialność sprzedajemy: Plutonapps specjalizuje się we wprowadzaniu aplikacji z Lovable na produkcję i ich utrzymaniu, a nasze porównanie software house’ów, freelancerów, zatrudnienia na etacie i abonamentów pokazuje, kiedy pasuje każda opcja.

Co dzieje się po starcie i kto ma dyżur?

Start to moment, w którym praca się zmienia, a nie kończy. Ktoś musi obserwować błędy, instalować aktualizacje bezpieczeństwa, reagować na incydenty i wdrażać kolejną funkcję, nie psując poprzedniej. W naszym planie Starter założyciele dalej piszą prompty w Lovable, a nasi inżynierowie wbudowują każdą wersję w prawdziwy produkt, przy każdej zmianie uruchamiają testy regresji i wizualne testy regresji, code review i kontrole bezpieczeństwa, wdrażają na produkcję dwa razy w tygodniu i obsługują do pięciu awaryjnych zdarzeń produkcyjnych miesięcznie, ze wsparciem w godzinach pracy. Growth dodaje ciągłe wdrażanie i wsparcie 24/7. Szczegóły i ceny są w naszym cenniku.