Jak przebiega tworzenie aplikacji dla firmy krok po kroku — od zakresu do startu?

Tekst wygenerowany przez AI · Wydawca: Tomasz Niedźwiecki · zawiera oznaczoną reklamę jego usług

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 każdej stronie decyduje jedna osoba. 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. Zespół agentów AI po starcie. Biznes od startu prowadzi właściciel; w naszych umowach może korzystać z zespołu agentów AI przygotowanego pod jego aplikację. Artefakt: miesięczny limit wydatków zespołu, który ustala właściciel. Akceptuje: właściciel — decyduje, co zespół robi i co wychodzi w jego imieniu. Blokuje: nic — to opcja.
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 liście własnego numeru, a decydują o reszcie: środowisko podglądowe, model uprawnień w bazie i płatność w trybie testowym. Każda jest tania na początku i droga po starcie.

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.

Najdroższa z tych awarii to płatności: webhook operatora jest jedynym źródłem prawdy o wpłacie.

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 zadaje przed podpisaniem i po każdym etapie. Żadne nie wymaga wiedzy technicznej.

• 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ść.
• Jedna osoba decyzyjna po każdej stronie — z nazwiskiem, nie „zespół”.

Jeśli na trzy z tych pytań pada odpowiedź „zrobimy to na końcu”, data startu jest życzeniem: rzeczy, które zwykle wysadzają termin, przesunięto na moment bez czasu na poprawki.

Jak to robimy — dowody, nie deklaracje

Zdanie „testujemy” nic nie znaczy, dopóki nie wiadomo, co blokuje wdrożenie. U nas blokuje siedem rzeczy — każdą da się pokazać zamawiającemu jako dowód.

• Czerwony test rdzenia zatrzymuje wydanie. Jeden scenariusz prowadzi od wejścia użytkownika do pierwszej realnej wartości dla klienta. Komplet zielonych testów potrafi opisywać aplikację, która nie robi tego, po co powstała.
• Ekran bez wejścia z interfejsu blokuje krok. Każdy widok z planu musi dać się osiągnąć klikaniem, nie wpisaniem adresu. Ekran-sierota wygląda przy odbiorze jak zrobiony, a w rękach użytkownika jak funkcja, której nie ma.
• Krok zamyka test dymny na żywym adresie. Dopóki nikt nie otworzył wdrożonej wersji pod jej własnym adresem, krok jest otwarty: brakujący sekret albo nieustawione uprawnienie widać dopiero po wdrożeniu, nie na komputerze programisty.
• Zmianę wrażliwą ogląda inna rola niż autor. Migracje, uprawnienia, logowanie, role, płatności, pliki i sekrety przechodzą audyt przed scaleniem, ze śladem w dzienniku budowy. Autor nie widzi własnego błędu tam, gdzie błąd kosztuje najwięcej.
• W trakcie budowy nic nie wychodzi do prawdziwych ludzi. Bezpiecznik jest domyślnie zamknięty: wiadomości idą wyłącznie na adresy testowe, a wyjście z trybu budowy wymaga jawnej decyzji z datą i osobą. Wiadomości testowej, która trafiła do prawdziwego odbiorcy, nie da się cofnąć.
• Makietę i front porównujemy plik do pliku. Układ, strefy i hierarchia ekranu z planu są zestawiane z tym, co zbudowano; rozjazd wykrywa automat, ale werdykt „zgodna” albo „niezgodna” wymaga obejrzenia zestawienia przez człowieka.
• Plan ekranów ma odcisk. Skrót kryptograficzny sprawia, że zmiana planu po starcie budowy jest wykrywana i wymaga jawnej akceptacji. Bez tego odbiór porównuje wynik do dokumentu, którego nikt świadomie nie zatwierdził.

To są bramki budowy, nie startu. Co sprawdzamy tuż przed uruchomieniem na żywo, opisaliśmy osobno: środowisko testowe, płatności testowe i testy automatyczne.

Dla Twojej branży: co się zmienia w tych krokach

Kroki są te same w każdej branży — zmienia się ich treść: lista ekranów w zakresie, integracje i obowiązki, które aplikacja musi obsłużyć. Tę część wnosi partner, który zna swoją branżę. Czy jest w niej miejsce i co taka aplikacja musi umieć — sprawdzisz w serwisach siostrzanych:

• Aplikacja dla biura rachunkowego w roku KSeF
• Aplikacja dla małej firmy budowlanej i podwykonawców
• Aplikacja dla firmy sprzątającej
• Aplikacja dla firmy transportowej do 3,5 tony
• Aplikacja dla fizjoterapeutów
• Aplikacja dla restauracji i małej gastronomii
• Aplikacja dla pracowni architektonicznej
• Aplikacja dla warsztatu samochodowego
• Co musi umieć aplikacja dla agencji marketingowej
• Co musi umieć aplikacja dla biura nieruchomości
• Co musi umieć aplikacja do ewidencji czasu pracy kierowców
• Czy aplikacja firmowa może śledzić lokalizację pracownika
• Co musi liczyć system dla dewelopera mieszkaniowego
• Co musi umieć aplikacja dla szkoły językowej

Niezależnie od branży pierwszy krok jest ten sam: zamknięty zakres pierwszej wersji z listą ekranów. Pozostałe kroki opisujemy w dziale Jak przebiega budowa. Kiedy w projektach wydawcy serwisu pojawiają się pierwsze ekrany, opisuje jego karta ile trwa budowa aplikacji i kiedy zobaczę ekrany.

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ż, ilu płacących użytkowników trzeba, żeby aplikacja się broniła — to osobny rachunek. Do kogo należy kod powstały z pomocą AI, opisaliśmy w tekście o prawach do kodu z AI i no-code. Co musi stać w samej umowie na budowę, zestawia lista 12 punktów umowy na stworzenie aplikacji.