Tworzenie aplikacji na zamówienie krok po kroku: co decydujesz na każdym etapie
Sześć etapów tworzenia aplikacji na zamówienie, od warsztatu do pierwszych tygodni po starcie. Przy każdym piszemy, co robisz Ty, co dostajesz i ile to trwa.

Każdy etap kończy się czymś, co możesz zobaczyć i zatwierdzić.
Tworzenie aplikacji na zamówienie to ciąg decyzji, które podejmujesz Ty, i materiałów, które zatwierdzasz po drodze. Gdy wiesz, co dzieje się na każdym etapie, łatwiej pilnować budżetu i terminu. Rozpisujemy sześć kroków, przez które przechodzi każdy system webowy na zamówienie, od pierwszego warsztatu po pierwsze tygodnie po starcie.
Krok 1. Warsztat, czyli problem zamiast listy funkcji
Projekt zaczyna się od rozmowy o tym, co dziś boli. Ile osób przepisuje dane między arkuszami, gdzie gubią się zamówienia, ile czasu zajmuje jedna oferta. Lista funkcji przychodzi później, bo bez zrozumienia procesu każda funkcja to zgadywanie.
Na warsztacie ustalamy trzy rzeczy. Kto będzie z aplikacji korzystać i w jakich rolach. Jaki jeden mierzalny efekt ma dać pierwsza wersja, na przykład oferta w 10 minut zamiast godziny. Z jakimi systemami aplikacja musi rozmawiać od pierwszego dnia, a które mogą poczekać.
Ty przynosisz wiedzę o procesie i przykładowe dokumenty, na przykład arkusz, którym dziś się ratujecie. My przynosimy pytania, których zwykle nikt wcześniej nie zadał. Efektem jest opis procesu i lista wymagań spisana Twoim językiem.
Krok 2. Zakres pierwszej wersji i wycena etapami
Z listy wymagań wybieramy to, bez czego aplikacja nie ma sensu. To jest pierwsza wersja. Reszta trafia do kolejnych etapów z osobną wyceną. Dzięki temu nie płacisz od razu za wszystko i możesz zatrzymać projekt po pierwszym etapie, jeśli wynik nie broni się w praktyce.
Wycena rozbita na etapy pokazuje, za co płacisz. Moduł zamówień, panel klienta, integracja z systemem księgowym, każdy ma swoją pozycję i swój czas. Gdy budżet jest napięty, wiesz od razu, co wyciąć, żeby zmieścić się w kwocie.
Tu zapada też decyzja o modelu rozliczeń. Przy jasno opisanym zakresie działa stała cena. Przy systemie, który będzie rósł z firmą, bezpieczniej rozliczać czas pracy, bo zmiana priorytetu nie wymaga wtedy aneksu do umowy.
Krok 3. Prototyp ekranów do kliknięcia
Zanim powstanie kod, dostajesz klikalny prototyp. To ekrany, po których przechodzisz jak po gotowej aplikacji, tylko bez prawdziwych danych pod spodem. Pokazujesz je osobom, które będą z systemu korzystać na co dzień, i zbierasz ich uwagi.
Poprawka w prototypie kosztuje godzinę pracy projektanta. Ta sama poprawka po zbudowaniu ekranu kosztuje dni programisty. Dlatego najwięcej zmian zgłaszaj właśnie tu. Typowe odkrycia z tego etapu to brakujące pole w formularzu, zła kolejność kroków albo rola, o której nikt nie pomyślał na warsztacie.
Akceptacja prototypu zamyka projekt wyglądu i ścieżek użytkownika. Od tego momentu zespół buduje to, co widziałeś i zatwierdziłeś.
Krok 4. Budowa w sprintach i integracje
Budowa idzie w dwutygodniowych cyklach. Po każdym dostajesz działającą wersję na środowisku testowym, z prawdziwą logiką i coraz pełniejszymi danymi. Widzisz postęp na bieżąco, a nie dopiero po kilku miesiącach.
Najwięcej niespodzianek kryją integracje. System księgowy, sklep, kurier, płatności, każdy ma swoje ograniczenia i swój sposób wymiany danych. Integracje uruchamiamy jak najwcześniej, na kopii prawdziwych danych, bo dopiero wtedy widać, czy kartoteki się zgadzają i czy zewnętrzny system odda to, czego potrzebujemy.
Twoja rola w tym etapie to szybkie odpowiedzi. Pytanie o regułę rabatu, które czeka tydzień na decyzję, przesuwa cały sprint. W dobrze prowadzonym projekcie jedna osoba po stronie firmy ma prawo decydować i odpisuje w ciągu dnia.
Równolegle powstaje to, czego nie widać na ekranach. Uprawnienia dla każdej roli, kopie zapasowe, logi zmian i zabezpieczenie danych klientów. Aplikacje na zamówienie często przechowują dane osobowe i finansowe, więc te elementy planujemy od pierwszego sprintu, a nie doklejamy przed startem.
Krok 5. Testy z użytkownikami i start
Przed startem aplikację testują ludzie, którzy będą jej używać, na swoich prawdziwych zadaniach. Handlowiec wystawia ofertę, magazynier przyjmuje dostawę, księgowa sprawdza dokumenty. Błędy z tego etapu poprawiamy przed uruchomieniem, a nie po nim.
Start planujemy na spokojny dzień, z przeniesionymi danymi i krótkim szkoleniem dla każdej roli. Często pierwsze tygodnie stary i nowy sposób pracy działają równolegle, żeby nikt nie został bez narzędzia, gdy coś wymaga poprawki.
Po starcie dostajesz kod, dostęp do repozytorium i dokumentację. Aplikacja należy do firmy, więc możesz ją rozwijać z nami albo z innym zespołem.
Krok 6. Pierwsze tygodnie po starcie
Prawdziwe użycie zawsze pokazuje rzeczy, których nie było widać w testach. Przez pierwsze tygodnie zbieramy uwagi, mierzymy efekt ustalony na warsztacie i poprawiamy to, co spowalnia pracę. Dopiero na tych danych planujemy kolejny etap rozwoju.
Po tym okresie aplikacja przechodzi w utrzymanie. Obejmuje ono serwer, kopie zapasowe, aktualizacje bibliotek, poprawki bezpieczeństwa i drobne zmiany zgłaszane przez zespół. Przy systemach webowych na zamówienie to zwykle kilkaset do kilku tysięcy złotych miesięcznie, zależnie od liczby użytkowników i tego, jak szybko ma reagować wsparcie. Większe funkcje wyceniamy osobno, jako kolejne etapy.
Tabela zbiera cały proces w jednym miejscu. Czas budowy ma najszerszy przedział, bo zależy od zakresu pierwszej wersji.
| Etap | Co robisz Ty | Co dostajesz | Orientacyjny czas |
|---|---|---|---|
| Warsztat | opisujesz proces, dajesz przykłady | opis procesu i wymagania | 1 do 2 tyg. |
| Zakres i wycena | wybierasz pierwszą wersję | wycenę etapami i harmonogram | kilka dni |
| Prototyp | testujesz ekrany z zespołem | zatwierdzony projekt aplikacji | 2 do 3 tyg. |
| Budowa | odpowiadasz na pytania, oglądasz wersje | działającą aplikację co 2 tygodnie | 4 do 20 tyg. |
| Testy i start | testujesz na swoich zadaniach | wdrożony system, kod, dokumentację | 1 do 3 tyg. |
| Po starcie | zgłaszasz uwagi | poprawki i plan rozwoju | 4 do 8 tyg. |
Prosty MVP kosztuje zwykle 25 000 do 60 000 zł, rozbudowany system webowy 60 000 do 200 000 zł. Różnicę robi głównie liczba ról i integracji, a nie liczba ekranów. Jeśli zastanawiasz się, czy w ogóle budować, czy wystarczy gotowe narzędzie, rozpisaliśmy to przy okazji usługi oprogramowanie na zamówienie.
Na pierwszą rozmowę przygotuj opis problemu w kilku zdaniach, listę osób, które będą korzystać z systemu, i nazwy programów, z którymi ma się łączyć. Z tym materiałem po rozmowie dostajesz zakres pierwszej wersji, wycenę etapami i harmonogram. Opisz nam swój pomysł, a pokażemy, jak wygląda tworzenie aplikacji na zamówienie w Twoim przypadku.
Przeczytaj również

Bezpieczeństwo aplikacji webowych w 2026
OWASP Top 10, RODO, AI Act — krajobraz zagrożeń się zmienił. SQL injection wciąż istnieje, ale dochodzą podatności specyficzne dla AI i automatyzacji. Oto co naprawdę chroni aplikację.
Dashboard BI na zamówienie vs Power BI — co wybrać
Power BI starcza dla 80% firm. Pozostałe 20% — z danymi z 6 źródeł, własną logiką i wysokim ruchem — potrzebują custom BI. Oto jak ocenić, do której grupy należysz.
Ile kosztuje utrzymanie aplikacji webowej? TCO 2026
Realny TCO: hosting, monitoring, aktualizacje, security, bug fixes. Widełki dla strony 5-podstronowej i dla SaaS-a z 1000 użytkowników.
Aplikacja SaaS — jak zbudować MVP w 8-12 tygodni
Konkretne decyzje, których nie da się odłożyć: multi-tenancy, billing, stack. I czego NIE robić w MVP, choć kuszące.Komentarze
Ładowanie…