Prototyp z Lovable, Bolt albo Cursora działa. Co dalej, zanim wpuścisz prawdziwych użytkowników?

Jeszcze niedawno sprawdzenie pomysłu na aplikację wymagało programisty i kilku tygodni pracy. Dziś Lovable, Bolt, v0, Cursor czy Claude Code pozwalają w kilka dni zbudować coś, co wygląda i działa jak prawdziwy produkt. To świetna zmiana: pomysły można testować szybciej i taniej niż kiedykolwiek. Problem pojawia się w momencie, w którym prototyp ma obsłużyć prawdziwych użytkowników, ich dane i ich pieniądze.

Ten tekst nie jest przeciwko AI — sami używamy tych narzędzi codziennie. Jest o tym, czego typowo brakuje w aplikacji zbudowanej szybko, i jak podjąć decyzję, co z nią zrobić dalej.

Czego zwykle brakuje w prototypie

Uprawnienia sprawdzane po stronie serwera

Najczęstszy i najgroźniejszy problem. Interfejs ukrywa przycisk przed zwykłym użytkownikiem, ale serwer (albo baza danych wystawiona bezpośrednio do przeglądarki) nie sprawdza, kto wysyła żądanie. Wystarczy wywołać je ręcznie, żeby zobaczyć lub zmienić cudze dane. W aplikacjach opartych o gotowe bazy w chmurze często chodzi o niewłączone lub źle napisane reguły dostępu do wierszy.

Klucze i sekrety w kodzie frontendu

Klucze do API płatności, modeli AI czy usług pocztowych trafiają do kodu, który pobiera przeglądarka — a więc może je przeczytać każdy. Skutek to cudze rachunki za Twoje konto albo dostęp do danych.

Walidacja danych

Formularz sprawdza pola w przeglądarce, ale serwer przyjmuje wszystko. To otwiera drogę do błędnych danych w bazie i ataków, które w dojrzałych frameworkach są blokowane domyślnie.

Testy i powtarzalne wdrożenia

Prototyp działa, dopóki nikt go nie zmienia. Bez testów każda poprawka może zepsuć coś innego, a bez automatycznych wdrożeń nikt nie wie dokładnie, która wersja działa na produkcji.

Kod, którego nikt nie rozumie

Aplikacja wygenerowana w wielu rozmowach z modelem często ma powielone fragmenty, nieużywane pliki i niespójne podejście w różnych częściach. Działa, ale kolejny programista — człowiek albo AI — ma coraz większy problem z wprowadzeniem zmiany bez efektów ubocznych.

Dane osobowe i RODO

Gdzie fizycznie leżą dane użytkowników, kto ma do nich dostęp, jak długo są przechowywane i czy da się je usunąć na żądanie — prototyp zwykle nie odpowiada na te pytania, a produkt musi.

Jak to sprawdzić

Nie trzeba zgadywać. Przegląd kodu i konfiguracji pokazuje, które z tych problemów występują i jak są poważne. W ramach audytu aplikacji sprawdzamy uprawnienia, sekrety, walidację, zależności, dane osobowe i sposób wdrażania, a wynikiem jest raport z listą ryzyk uszeregowanych według ważności. Audyt nie zobowiązuje do dalszej współpracy — raport możesz przekazać komukolwiek.

Rozwijać czy budować od nowa?

Na podstawie przeglądu zapada decyzja. Z grubsza wygląda to tak:

Rozwijać, gdy architektura jest rozsądna, a problemy dotyczą konkretnych miejsc: uprawnień, sekretów, walidacji. Naprawiamy je, dodajemy testy i automatyczne wdrożenia, a produkt żyje dalej.
Przebudować częściowo, gdy interfejs jest dobry, ale backend nie nadaje się do rozwoju. Zostawiamy to, co działa dla użytkownika, i wymieniamy fundament.
Zbudować od nowa, gdy każda zmiana w prototypie jest ryzykowna, a produkt ma rosnąć przez lata. Prototyp nie idzie wtedy na śmietnik — staje się najlepszą możliwą specyfikacją, bo pokazuje, jak produkt ma działać, i był już sprawdzony z użytkownikami.

W dwóch ostatnich przypadkach przeprowadzamy produkt do wersji produkcyjnej tak, jak przy budowie MVP: w Laravelu i React, z testami, code review i automatycznymi wdrożeniami.

Jak korzystać z AI i nie wpaść w te pułapki

Traktuj wygenerowany kod jak kod od nowego, bardzo szybkiego współpracownika: przeglądaj go, zanim trafi na produkcję.
Wymuś sprawdzanie uprawnień po stronie serwera dla każdej operacji na danych.
Trzymaj klucze wyłącznie po stronie serwera, w zmiennych środowiskowych.
Dodaj testy dla najważniejszych ścieżek, zanim zaczniesz szybko dokładać funkcje.
Zanim wpuścisz prawdziwych użytkowników, poproś kogoś niezależnego o przegląd.

Podsumowanie

Narzędzia AI świetnie sprawdzają się do szybkiej weryfikacji pomysłu.
Typowe braki prototypu to uprawnienia po stronie serwera, sekrety w frontendzie, walidacja, testy i RODO.
Decyzję „rozwijać czy budować od nowa” podejmij na podstawie przeglądu kodu, a nie wrażenia z interfejsu.
Nawet przy budowie od nowa prototyp jest cenną, sprawdzoną specyfikacją.

Masz działający prototyp i planujesz start? Napisz do nas — przejrzymy go i powiemy, co trzeba zrobić, zanim wpuścisz pierwszych użytkowników.