Jak naprawić vibe-codowaną aplikację React Native: checklista ratunkowa
Praktyczna checklista dla founderów, którzy zbudowali aplikację React Native narzędziami AI i teraz muszą naprawić bugi, uporządkować architekturę i przygotować launch.
Vibe-codowana aplikacja React Native rozsypuje się w bardzo konkretny sposób.
Demo wygląda na prawie gotowe. Ekrany są. Narzędzie AI stworzyło routing, przyciski, formularze, a czasem nawet paywall. Potem founder próbuje wystartować i produkt zaczyna się sypać: logowanie się psuje, build pada, płatności są udawane, wymagań App Store nie ma, a każda drobna zmiana rodzi kolejnego buga.
To jest checklista, której używam, zanim zdecyduję, czy vibe-codowaną aplikację naprawiać, przepisać, czy porzucić.
Zacznij od ścieżki do launchu, nie od drzewa plików
Nie zaczynaj od sprzątania losowych komponentów.
Prześledź prawdziwą podróż użytkownika:
użytkownik otwiera aplikację
użytkownik zakłada konto albo świadomie pomija logowanie
użytkownik dociera do głównej wartości
użytkownik trafia na paywall albo limit darmowy
użytkownik płaci, robi restore albo idzie dalej
użytkownik wraca później, a aplikacja pamięta stan
Jeśli ta ścieżka jest stabilna, aplikację da się uratować. Jeśli opiera się na zduplikowanym stanie, danych testowych i jednorazowej logice w ekranach, projekt potrzebuje głębszego ratunku.
Sprawdź, czy fundament React Native jest zdrowy
Agenty AI instalują to, co sprawia, że bieżący błąd znika.
Sprawdź:
wersje Expo SDK i React Native się zgadzają
build EAS działa
build iOS działa na fizycznym urządzeniu
nawigacja używa aktualnego wzorca
moduły natywne są kompatybilne z Expo
żadna paczka tylko webowa nie steruje funkcją mobilną
lockfile nie jest stertą wymuszonych resolutions
Jeśli AI zdowngradowało Expo, wymieszało niekompatybilne zależności albo załatało błędy natywnego buildu bez zrozumienia, napraw fundament, zanim dodasz cokolwiek nowego.
Rozplącz stan i logikę biznesową
Najczęstszym problemem w vibe-codowanych aplikacjach nie jest brzydkie UI. To ukryta logika biznesowa.
Szukaj:
wywołań API w handlerach przycisków
sprawdzeń subskrypcji skopiowanych po ekranach
informacji o ukończonym onboardingu trzymanej w kilku miejscach
stanu logowania kontrolowanego przez komponenty ekranów
reguł biznesowych w plikach UI
zduplikowanej logiki walidacji
Czyste aplikacje React Native mają rozdzielone warstwy: UI, stan, API, logowanie, płatności, analityka i storage. Vibe-codowane mieszają to razem, bo AI optymalizowało pod widoczny efekt.
Traktuj paywall jak infrastrukturę
Ekran paywalla to nie system monetyzacji.
Przed launchem potrzebujesz:
poprawnie skonfigurowanego RevenueCat, StoreKit, Google Play Billing albo Stripe
identyfikatorów produktów zgodnych ze sklepem
sprawdzania entitlements
restore purchases
obsługi wygasłej subskrypcji
logiki uprawnienia do triala
zdarzeń analitycznych
stanów błędu zakupu
Jeśli użytkownik zamknie paywall i dalej ma dostęp do płatnych funkcji, paywall jest makietą. Jeśli zakupy działają, ale po restarcie aplikacja nie wie, kto płaci, paywall dalej jest zepsuty.
Dodaj analitykę, zanim zaprosisz użytkowników
Nie naprawisz tego, czego nie widzisz.
Minimum, co trzeba mierzyć:
instalacja albo pierwsze otwarcie
start i koniec onboardingu
rejestracja
główna akcja rozpoczęta
główna akcja ukończona
wyświetlenie paywalla
start triala
ukończony zakup
nieudany zakup
zdarzenia retencyjne
Wiele aplikacji budowanych przez AI pomija analitykę, bo analityki nie widać w demie. Dokładnie dlatego founderzy zacinają się po launchu.
Zdecyduj, co zachować
Vibe-codowana aplikacja nie jest automatycznie bezwartościowa.
Zwykle da się zachować:
kierunek marki
układ ekranów
teksty
decyzje o przepływie użytkownika
assety
część warstwy komponentów UI
drobne kawałki działającej logiki biznesowej
Ale bądź gotów wymienić:
przepływ logowania
logikę płatności
klienty API
model stanu
analitykę
założenia nawigacyjne
konfigurację natywną
Wygraną nie jest zachowanie każdej wygenerowanej linijki. Wygraną jest wypuszczenie produktu szybciej, niż bałagan po AI zdąży zjeść resztę Twojego czasu.
Kiedy przepisać zamiast naprawiać
Przepisz krytyczną ścieżkę, jeśli:
każdy przepływ ma własną wersję stanu użytkownika
zależności są przypięte do starych albo niekompatybilnych wersji
logice płatności nie da się ufać
logowanie i nawigacja są splątane
aplikacja nie buduje się czysto
żaden developer nie potrafi wyjaśnić, jak działa główny przepływ
dodanie jednej funkcji psuje niepowiązane ekrany
To nie zawsze znaczy pełny redesign. Zwykle znaczy zachowanie użytecznych decyzji produktowych i przepisanie fundamentu.
Co robi Silpho
Ratunek dla aplikacji w Silpho ma jedno publiczne wejście: audyt za 1 990 zł netto. Audyt rozstrzyga, czy kod dostanie wycenę skupionej naprawy, czy przechodzi w czysty sprint budowy produktu. Opłata za audyt zalicza się na poczet obu ścieżek.
Przeglądam kod React Native albo Expo, wskazuję, co da się uratować, i daję stałą ścieżkę do gotowości na launch: logowanie, onboarding, paywall, analityka, przygotowanie App Store i plan wzrostu.
Przeczytaj dalej:
FAQ
Czy vibe-codowaną aplikację React Native da się naprawić?
Tak, jeśli główna podróż jest zrozumiała, zależności zdrowe, a zepsute kawałki odizolowane. Jeśli logowanie, stan, płatności i nawigacja są splątane, przepisanie krytycznej ścieżki jest zwykle szybsze.
Czy dalej prosić Cursor albo innego agenta o łatanie bugów?
Tylko przy odizolowanych problemach, które rozumiesz. Jeśli ten sam bug wraca w kolejnych wcieleniach, problem leży w architekturze, a nie w jakości promptu.
Ile trwa ratunek?
Proste porządki to kwestia dni. Prawdziwy ratunek pod gotowość do launchu zajmuje zwykle od 2 do 4 tygodni, zależnie od tego, ile istniejącego kodu da się uratować.