Aplikacja z Lovable rozsypała się po prototypie? Co naprawić przed premierą

Aplikacja z Lovable wyglądała przekonująco w podglądzie, ale pierwszy prawdziwy przepływ użytkownika obnażył zepsute logowanie, brakujące dane, niestabilny stan albo produkt, który nie ma jak trafić do App Store.

Skrót

Jeśli aplikacja z Lovable pada po etapie prototypu, przestań dokładać funkcje i najpierw zdiagnozuj ścieżkę do premiery. Problemem rzadko jest jeden bug. Zwykle to słaba granica między UI, logowaniem, stanem bazy, płatnościami, zachowaniem na mobile i wymogami produkcyjnymi. Naprawiaj, jeśli przepływ produktowy jest jasny, model danych da się użyć, a zepsute części są odizolowane. Przebuduj krytyczną ścieżkę, jeśli logowanie, stan, logika backendu albo wymogi premiery mobilnej są poplątane w poprzek ekranów. Skorzystaj z Ratunku dla aplikacji AI, gdy potrzebujesz spojrzenia z zewnątrz na to, co da się uratować, zanim spalisz kolejne tygodnie na promptowanie.

Najważniejsze fakty

• Prototyp z Lovable potrafi udowodnić kształt produktu, nie będąc gotowym na produkcję.

• Zepsute logowanie, brakujące reguły w Supabase, zduplikowany stan i kruche wywołania API to normalka po kilku cyklach promptowania.

• Pierwsze pytanie nie brzmi "czy da się naprawić tego buga?", tylko "czy ten kod udźwignie użytkowników, płatności, analitykę i wydanie?".

• Zachowaj z prototypu teksty, ekrany, założenia o danych i wnioski produktowe, jeśli są przydatne.

• Przebuduj krytyczną ścieżkę, gdy fundament ukrywa zbyt duże ryzyko.

• Premiera mobilna dokłada pracę, której Lovable zwykle nie kończy: buildy natywne, materiały do sklepu, usuwanie konta, odpowiedzi o prywatność i QA na TestFlight.

• Ścieżki z cennika Silpho obejmują wsparcie przy robocie własnej, premierę zrobioną za Ciebie i produkt gotowy na przychód.

Diagnoza: co jest naprawdę zepsute

Najdroższy błąd to traktowanie każdej awarii jako pojedynczego problemu do wypromptowania.

Kiedy founder mówi "moja aplikacja z Lovable jest zepsuta", zwykle chodzi o jedno z tych:

• logowanie działa w podglądzie, ale pada po odświeżeniu

• użytkownicy widzą cudze dane albo żadnych danych

• tabele w Supabase istnieją, ale row-level security jest niejasne

• funkcja działa raz, potem psuje się po nowym prompcie

• stany ładowania nigdy się nie kończą

• wygenerowany kod zduplikował tę samą regułę biznesową w kilku plikach

• aplikacja nie ma jasnej drogi do iOS, Androida, TestFlight ani App Review

• UI wygląda na skończone, ale nie ma usuwania konta, analityki, raportowania crashy ani stanu płatności

Ta lista miesza bugi z brakującą infrastrukturą produktową. Niedziałający przycisk to bug. Stan zalogowania oparty na lokalnych założeniach rozsypanych po pięciu ekranach to problem architektury. Ładny paywall bez logiki entitlements to nie jest system płatności. Aplikacja webowa, która dobrze wygląda na desktopie, to nie aplikacja mobilna gotowa na App Review.

Pytanie diagnostyczne jest proste: w jakim stanie jest aplikacja, gdy się psuje?

Wypisz dokładny stan użytkownika:

• wylogowany

• zalogowany

• onboarding niedokończony

• onboarding dokończony

• użytkownik darmowy

• użytkownik płacący

• subskrypcja wygasła

• konto usunięte

• płatność odrzucona

• użytkownik wracający po zamknięciu aplikacji

Jeśli aplikacja nie potrafi czysto odpowiedzieć na te stany, kolejne promptowanie zwykle przesunie buga w inne miejsce. Może naprawić widoczny ekran, jednocześnie utrudniając rozumienie całego systemu.

Dlaczego prototypy z Lovable padają po demo

Lovable jest mocne w skracaniu pierwszej fazy: ekrany, przepływy, teksty, podstawowe interakcje i działający kształt produktu. Awaria pojawia się, gdy prototyp zaczyna potrzebować produkcyjnych gwarancji.

Pierwsza przyczyna to dryf promptów. Wczesne prompty tworzą prostą strukturę. Późniejsze łatają po jednym widocznym problemie naraz. Wygenerowany kod kończy z nowymi helperami, zduplikowanymi komponentami, nakładającymi się wywołaniami bazy i sprawdzeniami stanu, które działają wyłącznie na happy path.

Druga przyczyna to brak granic odpowiedzialności. Produkcyjne aplikacje potrzebują jasnych miejsc na logowanie, dostęp do danych, reguły biznesowe, płatności, analitykę, obsługę błędów i nawigację. Kod prototypowy zwykle pozwala ekranom robić za dużo. Na początku to szybkie, dopóki każdy ekran nie stanie się częściowym klientem backendu, częściowym menedżerem stanu i częściowym silnikiem reguł produktowych.

Trzecia przyczyna to niedopasowanie do mobile. Jeśli celem jest produkt mobilny, prototyp webowy zostawia natywną robotę:

• strategia buildów na iOS i Android

• wzorce nawigacji mobilnej

• RevenueCat, StoreKit, Google Play Billing albo inna ścieżka płatności

• usuwanie konta

• etykiety prywatności i strony wsparcia

• zrzuty ekranu i teksty wizytówki

• testy na urządzeniach przez TestFlight

• raportowanie crashy i analityka

Czwarta przyczyna to słabe dowody na gotowość do premiery. Prototyp pokazuje, jak produkt ma się czuć, ale produkcja potrzebuje dowodu, że użytkownik przejdzie całą podróż. Ta podróż zaczyna się przed rejestracją i kończy po płatności, restore purchases, wylogowaniu, usunięciu konta i powrocie do aplikacji.

Ścieżka naprawy: napraw, zaudytuj albo przebuduj

Nie zaczynaj od pytania, czy Lovable jest dobre czy złe. To za mgliste, żeby pomóc. Zacznij od decyzji, które części pracy mają wartość.

Zachowaj prototyp, jeśli daje Ci:

• jasnego użytkownika docelowego

• przydatne teksty

• wiarygodny przepływ ekranów

• kierunek marki do ponownego użycia

• sensowny model danych

• zwalidowany główny przepływ

• decyzje produktowe, których odkrywanie od nowa zajęłoby czas

Napraw istniejącą aplikację, gdy awaria jest wąska. Przykłady: jedno zapytanie jest błędne, ekran ma zepsuty import, brakuje strażnika trasy albo polityka w Supabase wymaga korekty. Wtedy eksportuj kod, obejrzyj go lokalnie, przetestuj padającą ścieżkę i napisz małą poprawkę z powtarzalnym sprawdzeniem.

Zaudytuj przed naprawą, gdy objawy przechodzą przez granice. Jeśli logowanie wpływa na onboarding, onboarding na płatności, a płatności na dostęp do funkcji, potrzebujesz mapy stanów, zanim zaczniesz łatać. Tu wchodzi Ratunek dla aplikacji AI: celem jest decyzja, co przetrwa, co naprawiamy, a co trzeba zbudować od nowa.

Przebuduj krytyczną ścieżkę, gdy aplikacja nie ma wiarygodnego fundamentu. To nie znaczy wyrzucenia produktu. To znaczy zachowanie dowodów produktowych i przebudowanie tych części, które decydują, czy użytkownik się zarejestruje, dostanie wartość, zapłaci, wróci i przejdzie recenzję.

Przy produktach mobilnych ścieżka przebudowy zwykle prowadzi przez React Native albo Expo. Jeśli jesteś techniczny i chcesz prowadzonego punktu startowego, Kickstart daje Ci boilerplate Ship React Native, sesję 1 na 1, code review i 30 dni wsparcia za 1 990 zł netto. Jeśli wolisz, żeby aplikację zbudował ktoś za Ciebie, ścieżki Launch i Launch + Growth w cenniku są czystszym porównaniem.

Porównanie

FAQ

Czy zepsuta aplikacja z Lovable może się jeszcze przydać?

Tak. Kod może być słaby, a praca produktowa wartościowa. Ekrany, teksty, przepływy użytkownika, założenia o danych i główna obietnica mogą przetrwać naprawę albo przebudowę.

Czy dalej prosić Lovable o naprawę buga?

Tylko jeśli bug jest odizolowany i potrafisz zweryfikować poprawkę. Jeśli każda poprawka psuje inny ekran, przestań promptować i rozrysuj model stanów. Ten wzorzec zwykle oznacza problem architektoniczny.

Kiedy przebudować zamiast naprawiać?

Przebuduj, gdy logowanie, nawigacja, wywołania backendu i reguły biznesowe są poplątane w poprzek ekranów. Przebuduj też, gdy nie ma jasnej drogi wydawniczej, a produkt musi trafić do App Store. Zachowaj decyzje produktowe, nie kruchą implementację.

Czym to się różni od problemu "Lovable do App Store"?

Tamto pytanie dotyczy ścieżki premiery mobilnej. To pytanie dotyczy tego, czy istniejący fundament produktu przeżyje prawdziwych użytkowników. Wersję o ścieżce premiery znajdziesz w Czy aplikacja z Lovable trafi do App Store?.

Co sprawdzić w kodzie najpierw?

Zacznij od logowania i własności danych. Potwierdź, gdzie trzymane są sesje, jak ładują się chronione trasy, czy polityki Supabase odpowiadają własności rekordów przez użytkownika i czy ekrany duplikują te same sprawdzenia stanu.

A co z płatnościami?

Nie podpinaj płatności na niestabilnym logowaniu. Aplikacja mobilna potrzebuje ładowania produktów, przepływu zakupu, sprawdzania entitlements, restore purchases, obsługi wygasłych subskrypcji i zdarzeń analitycznych. Sam ekran paywalla to za mało.

Czy Silpho może naprawić aplikację z Lovable?

Silpho robi audyt i triage aplikacji zbudowanych przez AI w ramach Ratunku dla aplikacji AI. Efektem może być plan naprawy, przebudowa krytycznej ścieżki albo rekomendacja startu od zera przy aplikacji mobilnej.

Jak poznać, czy potrzebuję Launch czy Launch + Growth?

Launch, gdy potrzebujesz skupionej aplikacji gotowej na przychód z głównym przepływem AI, paywallem, subskrypcjami, podstawową analityką i zgłoszeniem do obu sklepów. Launch + Growth, gdy ten sam produkt potrzebuje też researchu ASO, zoptymalizowanych wizytówek, rozbudowanych zrzutów ekranu, filmu podglądowego, kreacji na premierę i optymalizacji po starcie.

Następne kroki

• Porównaj stałe ścieżki premiery w cenniku.

• Przynieś repo albo prototyp do Ratunku dla aplikacji AI, jeśli potrzebujesz decyzji naprawiać kontra przebudować.

• Przeczytaj Czy aplikacja z Lovable trafi do App Store?, jeśli zepsuty prototyp ma stać się aplikacją mobilną.