Najważniejsze w skrócie
Publikowane terminy dla prostej aplikacji wahają się od około miesiąca do trzech. Dla systemu z integracjami wykonawcy podają od 2–4 do 4–8 miesięcy, a dla rozbudowanej platformy — od 3–6 miesięcy do ponad dziewięciu.
Większość opóźnień nie powstaje w kodzie, tylko w czasie oczekiwania: na decyzje, feedback, dostępy do systemów i dane do migracji.
Dokładanie ludzi do spóźnionego projektu zwykle go nie przyspiesza — każda nowa osoba potrzebuje wdrożenia i zwiększa liczbę kanałów komunikacji.
Najskuteczniejszy sposób na skrócenie projektu to węższy zakres pierwszej wersji i jedna osoba decyzyjna po stronie firmy.
Krótka odpowiedź
Zależy, co budujesz — ale da się podać sensowne widełki. Oto, co publikują polscy wykonawcy:
- Prosta aplikacja webowa lub panel: 4–8 tygodni według WaspIT, 2–3 miesiące według MadeByRogal
- System z integracjami API: 8–16 tygodni (WaspIT), aplikacja średniej złożoności 4–8 miesięcy (MadeByRogal)
- Rozbudowana platforma lub system: 3–6 miesięcy (WaspIT), od 9 miesięcy wzwyż (MadeByRogal)
U nas pierwsze działające MVP powstaje zwykle w ciągu miesiąca — ale MVP to nie to samo co pełna wersja produkcyjna.
Dlaczego rozrzut jest tak duży? Bo każdy wykonawca inaczej definiuje „prosty” i „gotowy”. Ten problem rozkładamy na czynniki w przewodniku po oprogramowaniu na zamówienie. Tutaj skupiamy się na czymś innym: z czego składa się harmonogram i co realnie go wydłuża.
Publikowane terminy według skali projektu
Terminy deklarowane przez WaspIT (2026). Inni wykonawcy podają dla podobnych kategorii okresy nawet dwu–trzykrotnie dłuższe — dlatego zawsze pytaj, co dokładnie obejmuje termin:
Z czego składa się harmonogram
Etapy są podobne u większości wykonawców. Przy każdym warto wiedzieć, od czego zależy jego długość:
Analiza
Zrozumienie procesu, priorytetów i ograniczeń. Trwa krócej, gdy po stronie firmy jest jedna osoba, która zna proces i może podejmować decyzje.
Projekt i UX
Makiety, przepływy ekranów, czasem design system. Długość zależy głównie od tempa akceptacji — każda runda poprawek to dni, nie godziny.
Budowa w iteracjach
Najdłuższy etap, ale najbardziej przewidywalny, o ile zakres nie zmienia się w trakcie. Każda integracja z zewnętrznym systemem wydłuża go najbardziej.
Testy i odbiór
Testy wykonawcy i testy akceptacyjne po stronie firmy. Często niedoszacowany etap — Twój zespół musi znaleźć czas, żeby sprawdzić system na realnych scenariuszach.
Wdrożenie i migracja
Przeniesienie danych, szkolenia, uruchomienie. Jakość danych w obecnych systemach potrafi zaskoczyć i dołożyć tygodnie pracy.
Większość opóźnień nie powstaje w kodzie
Kiedy projekt się opóźnia, pierwsze pytanie zwykle brzmi: „dlaczego programiści nie zdążyli?”. Tymczasem sporą część kalendarza zajmuje nie praca, tylko czas oczekiwania.
Weźmy prosty przykład. Zespół pracuje w dwutygodniowych cyklach. Na koniec każdego cyklu pokazuje działającą wersję i potrzebuje decyzji, żeby ruszyć dalej. Jeśli decyzja zapada po trzech dniach roboczych, to przy dziesięciu dniach cyklu blisko jedna trzecia czasu mija na czekaniu — przynajmniej dla zadań zależnych od tej decyzji. Przez pół roku takie „tylko trzy dni” składają się w wiele tygodni opóźnienia.
Podobnie działa oczekiwanie na dostęp do API, konto u dostawcy płatności czy eksport danych z obecnego systemu. Każda z tych rzeczy wygląda na drobiazg, ale blokuje konkretne prace — a zespół nie może ich wykonać wcześniej ani ominąć.
Dlatego najskuteczniejszy sposób na krótszy projekt rzadko polega na „szybszym programowaniu”. Polega na tym, żeby praca nie czekała.
Siedem rzeczy, które najczęściej wydłużają projekt
Przejrzyj tę listę przed startem — przy większości z nich możesz zadziałać zawczasu:
Zmiany zakresu w trakcie — Każda nowa funkcja dopisana w połowie projektu przesuwa termin wszystkiego, co od niej zależy. Dobre pomysły warto zbierać do kolejnej wersji.
Brak jednej osoby decyzyjnej — Gdy decyzje wymagają zgody kilku działów, każda z nich trwa tygodniami zamiast dniami.
Opóźniony feedback — Wersja pokazana na koniec cyklu, która czeka na komentarze tydzień, to tydzień wyjęty z harmonogramu.
Dostępy i konta — Klucze API, konta u dostawców płatności, domeny, konta deweloperskie w sklepach z aplikacjami. Ich założenie potrafi trwać dłużej niż sama integracja.
Dane do migracji — Duplikaty, brakujące pola i niespójne formaty w obecnych systemach wychodzą zwykle dopiero przy przenoszeniu danych.
Integracje z zewnętrznymi systemami — Słaba dokumentacja, brak środowiska testowego albo zespół po drugiej stronie, który odpowiada raz w tygodniu.
Formalności — Umowa powierzenia przetwarzania danych, akceptacja działu bezpieczeństwa, procedury zakupowe. Warto uruchomić je równolegle z analizą, a nie po niej.
Czy da się przyspieszyć, dokładając ludzi?
Intuicja podpowiada, że dwa razy więcej programistów to dwa razy krótszy projekt. W praktyce działa to rzadko — zjawisko opisał już w 1975 roku Fred Brooks w książce „The Mythical Man-Month”, formułując zasadę znaną dziś jako prawo Brooksa: dodanie ludzi do spóźnionego projektu opóźnia go jeszcze bardziej.
Powody są dwa. Po pierwsze, każda nowa osoba musi poznać projekt, a wprowadzają ją ci, którzy w tym czasie nie programują. Po drugie, rośnie liczba kanałów komunikacji: w zespole 3 osób są 3 pary, które muszą się ze sobą porozumiewać, w zespole 6 osób — już 15.
Większy zespół ma sens, gdy projekt da się podzielić na niezależne części i planuje się to od początku. Jako ratunek dla spóźnionego harmonogramu zwykle zawodzi.
Jak realnie skrócić projekt
Cztery rzeczy, które leżą po stronie firmy zamawiającej i dają największy efekt:
Węższa pierwsza wersja
Wybierz jeden proces i najmniejszy zakres, który da się zmierzyć. Kolejne funkcje dodawaj na działającym systemie.
Jedna osoba decyzyjna
Z mandatem do akceptowania makiet i wersji oraz z czasem zarezerwowanym w kalendarzu na projekt.
Dostępy i dane przed startem
Konta, klucze API i przykładowe dane przygotowane, zanim zespół ich potrzebuje.
Stały rytm przeglądów
Stałe spotkanie na koniec każdego cyklu i feedback w ciągu jednego–dwóch dni.
Chcesz realny harmonogram dla swojego projektu?
Opisz, co chcesz zbudować. Rozpiszemy etapy z konkretnym rezultatem każdego z nich i wskażemy, co warto przygotować po Twojej stronie przed startem.
Na co uważać w harmonogramie z oferty
Harmonogram w ofercie to obietnica, którą warto sprawdzić przed podpisaniem umowy. Kilka pytań, które szybko pokazują, czy jest realistyczny:
- Czy termin dotyczy MVP, czy wersji produkcyjnej? To najczęstsze źródło rozczarowań.
- Czy obejmuje testy akceptacyjne i migrację danych? Jeśli nie, doliczy się je później.
- Czy wypisano zależności po Twojej stronie? Dobry harmonogram mówi wprost, kiedy wykonawca potrzebuje decyzji, dostępów i danych.
- Czy etapy kończą się konkretnym rezultatem? „Etap 2 — programowanie” to za mało. „Etap 2 — działający moduł zamówień na środowisku testowym” to już kamień milowy, który da się odebrać.
- Czy jest bufor na ryzyko? Harmonogram bez żadnego zapasu przy projekcie z integracjami to sygnał ostrzegawczy, nie przewaga.
Kamienie milowe warto powiązać z odbiorami i płatnościami w umowie — piszemy o tym w tekście umowa z software house'em — co musi się w niej znaleźć.
Najczęściej zadawane pytania
Ile trwa stworzenie prostej aplikacji?+
Ile trwa zbudowanie MVP?+
Dlaczego projekty IT się opóźniają?+
Czy stała cena gwarantuje dotrzymanie terminu?+
Ile trwa wdrożenie po zakończeniu programowania?+
Masz pomysł na projekt?
Pomożemy go zaprojektować i wdrożyć, od strategii po gotowe rozwiązanie.
