Jak wygląda budowa aplikacji krok po kroku — od zakresu do startu produkcyjnego?

Kolejność prac: dziesięć kroków, dziesięć artefaktów

Porządna budowa ma dziesięć kroków, a każdy kończy się czymś, co da się otworzyć, przeczytać albo kliknąć. Krok bez artefaktu i bez osoby, która go przyjmuje, nie jest krokiem — jest obietnicą.

Po stronie firmy akceptuje jedna osoba decyzyjna, po stronie wykonawcy jedna osoba odpowiada za dostarczenie. Dwie osoby decyzyjne to dwa zdania o tym samym ekranie i tydzień na uzgodnienie, które z nich obowiązuje.

1. Rozpoznanie. Ustalamy, co ma się zmienić w firmie i kto tego użyje. Artefakt: karta projektu — problem, odbiorcy, jedna funkcja główna, pierwsze ekrany. Akceptuje: właściciel. Blokuje: bez nazwanego odbiorcy i jednej funkcji głównej nie da się zamknąć zakresu.
2. Zakres pierwszej wersji. Dokument, który rozstrzyga, co wchodzi, a co jest pracą dodatkową. Artefakt: zakres z listą ekranów i listą „czego nie ma”. Akceptuje: obie strony, na piśmie. Blokuje: zmiana zakresu w trakcie to osobna wycena i nowy termin, nie „dorzucimy”.
3. Makiety przed kodem. Ekrany do akceptacji, zanim powstanie logika. Artefakt: komplet makiet ekranów z zakresu. Akceptuje: właściciel. Blokuje: kod pisany przed akceptem makiet przerabia się drugi raz, razem z bazą pod nim.
4. Budowa etapami. Widoczny postęp na osobnym adresie, nie „pokażemy na końcu”. Artefakt: działające ekrany na środowisku podglądowym po każdym etapie. Akceptuje: właściciel, uwagami do etapu. Blokuje: brak materiałów, decyzji i dostępów po stronie firmy zatrzymuje bieg terminów.
5. Odbiór pierwszej wersji. Zgłoszenie do odbioru otwiera okno na uwagi — w naszych umowach 7 dni, brak uwag oznacza odbiór. Artefakt: zgłoszenie i lista uwag z rozstrzygnięciem. Akceptuje: właściciel. Blokuje: uwagi poza zakresem są pracą dodatkową i nie wstrzymują odbioru.
6. Gwarancja usuwania błędów. 90 dni, liczone od późniejszego z dwóch zdarzeń: odbioru albo startu produkcyjnego. Artefakt: rejestr zgłoszeń i poprawek z datami. Akceptuje: właściciel, zamykając zgłoszenie. Blokuje: gwarancja nie obejmuje skutków zmian w kodzie wprowadzonych przez kogoś z zewnątrz.
7. Start produkcyjny. Aplikacja na docelowej domenie, z prawdziwymi płatnościami. Artefakt: działający adres, konta u dostawców założone na firmę właściciela, potwierdzony test odtworzenia kopii. Akceptuje: właściciel. Blokuje: bez domeny i dostępów po stronie firmy startu nie ma.
8. Rozruch. W naszych umowach jest domknięty liczbą i czasem: pierwszych 50 użytkowników, najdłużej 9 miesięcy od startu; budżet reklamowy jest po stronie właściciela. Artefakt: pierwsi płacący użytkownicy i dane o tym, czego naprawdę używają. Akceptuje: właściciel. Blokuje: aplikacja bez użytkowników nie daje materiału na rundę drugą.
9. Opieka po starcie. Utrzymanie funkcji, aktualizacje bezpieczeństwa, sprawność płatności. Artefakt: czas reakcji zapisany w umowie — u nas 1 dzień roboczy na zgłoszenia krytyczne i 3 dni na pozostałe, przy czym reakcja to podjęcie działań, nie naprawa. Akceptuje: właściciel. Blokuje: aplikacja bez opieki starzeje się razem z bibliotekami, na których stoi.
10. Przekazanie. Kod, konta i dane w rękach właściciela. Artefakt: kopia repozytorium i dostępy do kont u dostawców, w zakresie i terminie z umowy. Akceptuje: właściciel. Blokuje: dopóki konta stoją na wykonawcy, właściciel nie ma czym zarządzać ryzykiem.

Trzy rzeczy nie mają w tej liście własnego numeru, a decydują o reszcie: środowisko podglądowe, model uprawnień w bazie i płatność uruchomiona w trybie testowym. Każda z nich jest tania na początku i bardzo droga po starcie.

Środowisko podglądowe nie jest luksusem. U dostawcy hostingu, którego używamy, każdy commit na gałęzi innej niż produkcyjna tworzy osobne wdrożenie z własnym adresem — tak opisuje to dokumentacja Vercel, zaktualizowana 14 sierpnia 2026 (odczyt 31 sierpnia 2026). Jeśli wykonawca pokazuje postęp wyłącznie na zrzutach ekranu, warto zapytać dlaczego.

Gdzie budowa się wykłada?

Pięć awarii wraca w każdym projekcie, który się posypał, i żadna z nich nie jest awarią techniczną. Wszystkie biorą się z kroku, który ktoś przeskoczył, żeby było szybciej.

W płatnościach „prawie działa” kosztuje najwięcej: webhook operatora jest jedynym źródłem prawdy o wpłacie, a front nigdy nie zalicza płatności sam, po przekierowaniu z bramki.

Stripe ponawia nieudane dostarczenie zdarzenia przez trzy dni z rosnącym odstępem w trybie live, a w piaskownicy — trzy razy w ciągu kilku godzin. Ręczne ponowienie: z panelu do 15 dni od powstania zdarzenia, z wiersza poleceń do 30 dni (dokumentacja Stripe, odczyt 31 sierpnia 2026).

Margines ratunku działa tylko wtedy, gdy ktoś zauważy problem w oknie ponowienia — nieudane zdarzenie płatnicze musi trafiać na czyjąś skrzynkę, nie do logu. Podpis weryfikuje się sekretem punktu końcowego, a biblioteki Stripe dopuszczają domyślnie 5 minut różnicy między znacznikiem czasu a zegarem serwera; bez weryfikacji webhook to otwarty adres na „zapłacone”.

Automatycznych kopii na darmowym planie bazy, której używamy, nie ma — dokumentacja Supabase odsyła do własnego eksportu z wiersza poleceń. Plan Pro trzyma 7 ostatnich kopii dziennych, Team 14, Enterprise do 30 dni (odczyt 31 sierpnia 2026).

Odtwarzanie do punktu w czasie jest płatnym dodatkiem z haczykiem: po jego włączeniu kopie dzienne przestają powstawać. U nas kopię sprawdza się odtworzeniem, nie istnieniem pliku: punkt i czas odtworzenia zapisujemy, zanim będą potrzebne.

Po czym poznać porządną robotę?

To są pytania, które zamawiający może zadać przed podpisaniem i po każdym etapie. Żadne nie wymaga wiedzy technicznej, a każde ma odpowiedź, którą da się sprawdzić w kilka minut.

• Zakres na piśmie — lista ekranów i lista „czego nie ma”. Odpowiedź „ustalimy w trakcie” oznacza, że termin też się ustali w trakcie.
• Makiety przed kodem — komplet ekranów do akceptacji, zanim ktokolwiek zacznie pisać logikę.
• Adres podglądowy, który mogę otworzyć dziś — nie zrzuty ekranu, nie nagranie, tylko działająca strona.
• Płatność przeszła w trybie testowym — i widać jej ślad w bazie, zapisany z powiadomienia operatora, nie z przekierowania przeglądarki.
• Kopia była odtworzona — poproś o datę ostatniego testu odtworzenia i o to, ile wtedy trwał.
• Konta u dostawców na firmę zamawiającego — hosting, baza, operator płatności, poczta i domena. Wykonawca dostaje dostęp, nie własność.
• Kryteria odbioru zapisane razem z zakresem — z liczbą dni na uwagi i z informacją, co się dzieje, gdy uwag nie ma.
• Jedna osoba decyzyjna po każdej stronie — z nazwiskiem, nie „zespół”.
• Wiadomo, co dzieje się po odbiorze — od kiedy liczy się gwarancja, co obejmuje i czym różni się od opieki po starcie.

Jeśli na trzy z tych pytań pada odpowiedź „zrobimy to na końcu”, data startu jest życzeniem. Nie dlatego, że wykonawca jest nierzetelny — dlatego, że trzy rzeczy, które zwykle wysadzają termin, zostały przesunięte na moment, w którym nie ma już czasu na poprawki.

Czego ta lista nie rozstrzyga?

Kolejność prac nie odpowiada na pytanie, ile budowa kosztuje ani czym ją zbudować. Rachunek kosztu i porównanie dróg prowadzimy osobno: ile realnie kosztuje aplikacja w trzy lata oraz czym to zbudować. Wybór operatora płatności do pierwszej wersji ma własny rachunek — Stripe, Tpay, Przelewy24 i BLIK w MVP.

Nie rozstrzyga też, czy w danej branży jest miejsce i ilu płacących użytkowników trzeba, żeby aplikacja się broniła — to osobny rachunek. Do kogo należy kod, gdy część powstała z pomocą AI, opisaliśmy w tekście o prawach do kodu z AI i no-code.

Ten artykuł opisuje jedno: co powstaje na każdym kroku, kto to przyjmuje i co zatrzymuje następny krok. Reszta decyzji ma swoje miejsce i swoje liczby.