Naprawiać czy pisać od nowa aplikację React Native zbudowaną przez AI?

Najtrudniejszy moment z aplikacją zbudowaną przez AI to nie pierwsze demo. To punkt, w którym demo działa, a każde realne zadanie przed launchem odsłania kolejny ukryty problem.

Logowanie jest zrobione w połowie. Ekran paywalla istnieje, ale niczego nie blokuje. Paczki Expo są przestarzałe. To samo wywołanie API dzieje się w trzech miejscach. Analityki nie ma. Wysyłka do App Store to dalej zagadka.

W tym momencie founderzy zadają właściwe pytanie:

Naprawiać ten kod czy pisać go od nowa?

Ten tekst daje praktyczne ramy triage dla aplikacji React Native i Expo zbudowanych narzędziami AI: Cursor, Lovable, Bolt, Replit albo agentami kodującymi.

Złe pytanie: czy ten kod da się naprawić?

Prawie każdy kod da się naprawić.

To nie znaczy, że naprawianie jest najlepszą decyzją biznesową.

Prawdziwe pytanie brzmi:

Czy ten kod doprowadzę do launchu szybciej, niż napiszę krytyczną ścieżkę od nowa na czystym fundamencie?

Jeśli tak, ratuj. Jeśli nie, przepisz to, co się liczy, i przestań płacić odsetki od długu technicznego.

Co naprawdę znaczy "gotowa do launchu"

Gotowa do launchu aplikacja mobilna z AI to nie jest działające demo.

Potrzebuje:

• stabilnego onboardingu

• niezawodnego logowania

• jednego jasnego przepływu AI

• logiki płatności i subskrypcji

• sprawdzania entitlements

• zdarzeń analitycznych

• crash reportingu

• czystych metadanych w App Store

• polityki prywatności i usuwania konta

• obsługi stanów ładowania, pustych i błędu

• kodu, który zrozumie inny developer

Jeśli Twoja aplikacja tego nie ma, dalej może mieć wartość. Ale nie jest skończona.

Zachowaj kod z AI, jeśli to prawda

1. Główna podróż użytkownika jest zrozumiała

Otwórz aplikację i prześledź ścieżkę:

1. użytkownik wchodzi

2. użytkownik zakłada konto

3. użytkownik dociera do głównej wartości

4. użytkownik widzi paywall

5. użytkownik płaci albo zostaje na darmowym

6. użytkownik wraca później

Jeśli ten przepływ jest czytelny w kodzie i w UI, projekt może być do uratowania.

Jeśli każdy ekran ma własny stan, własne wywołania API i własne założenia o płatnościach, nie patrzysz na produkt. Patrzysz na rozłączne demka.

2. Zależności nie walczą z aplikacją

Sprawdź podstawy:

• wersję Expo SDK

• wersję React Native

• bibliotekę nawigacji

• SDK dostawcy logowania

• integrację z RevenueCat, Stripe albo StoreKit

• uprawnienia natywne

• narzędzia buildu

Jeśli AI zainstalowało przestarzałe paczki, ale szkody są odizolowane, naprawa może być rozsądna.

Jeśli aplikacja buduje się tylko dlatego, że AI zdowngradowało Expo albo skleiło niekompatybilne wersje, przepisanie fundamentu bywa szybsze.

3. Ekrany da się wykorzystać

Narzędzia AI często produkują użyteczne UI. Nawet jeśli logika jest kiepska, ekrany mogą zawierać dobre myślenie produktowe:

• teksty onboardingu

• układ dashboardu

• ekrany wyników

• ustawienia

• stany puste

• kierunek marki

Nie musisz tego wyrzucać. Ratunek może zachować warstwę wizualną, przepisując logikę biznesową pod spodem.

4. Główny przepływ AI działa na prawdziwym urządzeniu

Nie ufaj preview w przeglądarce. Nie ufaj zamockowanej odpowiedzi.

Przetestuj główną akcję AI na urządzeniu:

• upload albo wejście działa

• wywołanie API się udaje

• stan ładowania jest czytelny

• wynik się zapisuje

• błędy są obsłużone

• koszt jest przewidywalny

Jeśli główny przepływ AI działa, ratunek jest bardziej prawdopodobny. Jeśli działa tylko na fałszywych danych albo pada na urządzeniu, aplikacja wymaga głębszej roboty.

Przepisz krytyczną ścieżkę, jeśli to prawda

1. Logowanie, onboarding i płatności są splątane

To największy sygnał ostrzegawczy.

Jeśli kod nie odpowiada jasno na pytania:

• czy użytkownik jest zalogowany?

• czy onboarding jest ukończony?

• czy użytkownik płaci?

• jaki ma plan?

• jaki ekran powinien zobaczyć dalej?

to aplikacja nie nadaje się do launchu. Te reguły sterują przychodem i retencją. Nie mogą być rozsypane losowo po ekranach.

2. Każda poprawka rodzi kolejnego buga

To zwykle znaczy, że architektura nie ma granic.

Naprawiasz onboarding i psujesz dashboard. Naprawiasz dashboard i psujesz logowanie. Aktualizujesz paczkę i aplikacja przestaje się budować.

To nie jest normalny "bałagan startupu". To znak, że fundament jest za kruchy.

3. Logika biznesowa jest zduplikowana

Typowe wzorce w kodzie generowanym przez AI:

• trzy różne sprawdzenia subskrypcji

• dwa klienty API

• zduplikowane typy użytkownika

• powtórzone strażniki logowania

• podobne ekrany ze skopiowaną logiką

• martwe funkcje pomocnicze

Duplikacja robi launch niebezpiecznym, bo nikt nie wie, która ścieżka kodu jest prawdziwa.

4. Wymagania App Store zostały zignorowane

Jeśli aplikacja ma subskrypcje, konta użytkowników, obietnice zdrowotne, treści generowane przez AI albo dane wrażliwe, wymagania App Store kształtują produkt.

Przepisz albo zrefaktoruj, jeśli brakuje:

• usuwania konta

• adresu polityki prywatności

• informacji o subskrypcji

• restore purchases

• regulaminu

• wyjaśnień uprawnień

• przepływów bezpieczeństwa albo moderacji tam, gdzie są potrzebne

Nie chcesz odkryć tego po wysłaniu buildu.

Macierz decyzyjna

Prosta reguła:

Co powinien dawać audyt Ratunek dla aplikacji

Użyteczny audyt nie kończy się na "ten kod jest zły".

Ma dać decyzję:

1. co przetrwa

2. co zostaje naprawione

3. co zostaje przepisane

4. co wypada z v1

5. co blokuje wysyłkę do App Store

6. ile kosztuje sprint ratunkowy

To jest różnica między code review a planem launchu.

Jak Silpho podchodzi do ratowania aplikacji z AI

Silpho nie próbuje zostać tanim serwisem do naprawiania bugów w vibe-codowanych aplikacjach.

Oferta jest węższa:

Pomagam founderom przejść od prototypu zbudowanego przez AI do produktu mobilnego gotowego na launch.

To znaczy, że kod mnie obchodzi, ale tylko dlatego, że kod ma wspierać wynik biznesowy:

• użytkownicy przechodzą onboarding

• użytkownicy mogą zapłacić

• główny przepływ AI działa

• analityka mówi, co się wydarzyło

• aplikację da się wysłać do sklepu

• repo da się przekazać

Czasem to znaczy naprawę istniejącej aplikacji. Czasem przepisanie krytycznej ścieżki na czystym stacku.

Zacznij od audytu za 1 990 zł netto

Jeśli utknąłeś, nie zaczynaj od pełnego przepisania. Zacznij od triage.

Audyt Ratunek dla aplikacji przegląda kod React Native albo Expo, sprawdza blokery launchu i daje Ci stałą ścieżkę ratunku. Jeśli wchodzisz w sprint, koszt audytu zalicza się na poczet pracy.

Dowiesz się, czy aplikację naprawiać, przepisać, czy porzucić.

Ta jasność jest warta więcej niż kolejny miesiąc proszenia agenta AI o łatanie tego samego fundamentu.

Powiązane

• Jak naprawić aplikację zbudowaną przez AI przed launchem

• Jak naprawić vibe-codowaną aplikację React Native

• Zobacz cennik Silpho