Zwykle to drugie pytanie. Zaraz po tym o budżet.
Masz pomysł. Zaczynasz myśleć o funkcjach. I w pewnym momencie musisz wiedzieć: ile tak naprawdę trwa zbudowanie aplikacji mobilnej?
Internet powie ci wszystko, od sześciu tygodni do dwóch lat. Obie odpowiedzi są technicznie poprawne. Żadna nie jest zbyt przydatna.
A w 2026 roku to pytanie zrobiło się jeszcze bardziej skomplikowane. Wielu założycieli przychodzi z czymś, co już powstało: z prototypem sklejonym w weekend za pomocą narzędzi AI. Czasem jest solidny. Czasem wygląda na gotowy, ale ma luki, które wychodzą dopiero wtedy, gdy trafi na niego prawdziwy użytkownik.
Tak czy inaczej punkt wyjścia się zmienił. A to zmienia też harmonogram.
Dlaczego każda odpowiedź, którą znajdziesz w sieci, jest inna
Dwie aplikacje mogą brzmieć niemal identycznie, a wymagać zupełnie innego nakładu pracy.
Prosta aplikacja z kilkoma ekranami i bez backendu to zupełnie inny projekt niż aplikacja z kontami użytkowników, płatnościami, integracjami z zewnętrznymi systemami i treściami, którymi trzeba zarządzać. Obie można opisać jako „aplikację mobilną dla mojej firmy”.
Harmonogram jednej może wynosić 8 tygodni. Druga może zająć pół roku.
Najważniejsze zmienne to zakres, złożoność, wybór platformy i, bardziej niż cokolwiek innego, to, jak jasno projekt jest zdefiniowany przed startem developmentu. Właśnie na tym ostatnim większość szacunków czasowych się wykleja.
Trzy projekty. Trzy bardzo różne harmonogramy.
Najlepszy sposób, żeby odpowiedzieć na to pytanie, to prawdziwe przykłady.
Beredt - 8 tygodni
Beredt to aplikacja o gotowości kryzysowej dla norweskich rodzin. Osobisty asystent, który pomaga organizować zapasy, tworzyć plany bezpieczeństwa i być przygotowanym na nieoczekiwane sytuacje.
Klient zgłosił się do nas pod koniec października. Inny zespół developerski zaczął projekt, ale utknął. Cel był jasny: start przed świętami.
Przejrzeliśmy istniejący kod, znaleźliśmy to, czego brakowało, dokończyliśmy kluczowe funkcje, przeprojektowaliśmy interfejs i wystartowaliśmy na iOS i Androidzie.
Osiem tygodni. Sześć osób. Sześćdziesiąt ekranów.
To szybko. Było to możliwe, bo zakres był zdefiniowany, a decyzje już podjęte. Zespół mógł budować, nie zatrzymując się, żeby coś ustalać.
Te osiem tygodni obejmowało drogę do startu MVP. Potem było jeszcze pół roku ulepszeń, nowych funkcji i poprawek na podstawie opinii prawdziwych użytkowników. Pierwotny harmonogram doprowadza cię do startu. Produkt rozwija się dalej.
Więcej o aplikacji Beredt znajdziesz tutaj.
Lengi - 6 miesięcy
Lengi to aplikacja do nauki języków, która wykorzystuje AI do symulowania prawdziwych rozmów z native speakerami. Ćwiczysz mówienie, dostajesz feedback do swoich wiadomości w czasie rzeczywistym i śledzisz postępy dzięki seriom i statystykom.
Zajęliśmy się wszystkim od początku: badaniem rynku, wireframami, prototypowaniem, testami z użytkownikami, integracją AI, architekturą backendu i startem na obu platformach.
Sześć miesięcy. Mały zespół. Po starcie: 3000 pobrań i 12 płatnych subskrypcji w pierwszych tygodniach.
Harmonogram odzwierciedla zakres. Feedback AI w czasie rzeczywistym, wiele ścieżek użytkownika, model subskrypcyjny, sprawdzanie poprawności w różnych językach. Dobre zbudowanie takich rzeczy wymaga czasu. Pośpiech byłby widoczny w efekcie.
Więcej o aplikacji Lengi znajdziesz tutaj.
Pelican - 24 tygodnie
Pelican to aplikacja do edukacji finansowej, która pomaga użytkownikom zrozumieć pieniądze, oszczędności i inwestycje, z wbudowanym wsparciem AI.
Zbudowaliśmy ją najpierw jako aplikację webową, a potem przeszliśmy na mobile. MVP obejmowało spersonalizowany dashboard finansowy, centrum wiedzy z artykułami i podcastami oraz fundamenty modelu subskrypcyjnego.
Sześć osób. Trzydzieści ekranów. Dwadzieścia cztery tygodnie na pierwszą fazę. Produkt wciąż rośnie, a nowe funkcje dochodzą na podstawie prawdziwych danych o użytkownikach.
Więcej o aplikacji Pelican znajdziesz tutaj
Co pokazują te liczby
Trzy projekty. 8 tygodni, 6 miesięcy, 24 tygodnie.
Beredt był szybki, bo zakres był skupiony, a termin sztywny. Nie było miejsca na „a może jeszcze dorzucimy…” w trakcie budowy. Ograniczenia pomogły.
Lengi zajęło więcej czasu, bo powstawało od zera ze złożonymi funkcjami AI, które musiały działać dobrze od pierwszego dnia. Ten harmonogram wynikał ze złożoności.
Pelican jest gdzieś pośrodku. Produkt z prawdziwą głębią, budowany w fazach, zaczynając od webu, żeby ograniczyć wczesne ryzyko.
Inne produkty, inne harmonogramy. Wszystkie rozsądne jak na to, czym były.
Wspólne miały jedno: żaden z nich nie zaskoczył nikogo czasem realizacji. Bo zakres był jasny, zanim ruszył pierwszy sprint.
Gdzie naprawdę ucieka czas
Rzadko jest to sam development.
Zakres, który ciągle rośnie. Nowa funkcja dochodzi w trakcie sprintu. Zmienia się priorytet. Ktoś zmienia zdanie co do kluczowego flow. Każda zmiana w trakcie budowy kosztuje więcej czasu niż ta sama zmiana przed startem developmentu.
Wymagania, które nie zostały zdefiniowane na początku. Kiedy zespół musi stanąć i czekać na decyzję, która powinna zapaść w pierwszym tygodniu, praca zwalnia. Czasem zatrzymuje się całkiem.
Kod wygenerowany przez AI, który wyglądał na gotowy, ale nie był. Założyciel buduje prototyp narzędziami AI, przekazuje go zespołowi developerskiemu, a zespół odkrywa, że kluczowe flow, rejestracja, płatności i przypadki brzegowe nigdy nie zostały porządnie dokończone. Kod działa, ale nie nadaje się na produkcję. Zanim zacznie się budować dalej, ktoś musi wrócić do tego, co już jest. To nieplanowany czas, którego nikt nie uwzględnił w budżecie.
Integracje, które wyglądały prosto. Połączenie z dostawcą płatności, CRM-em czy zewnętrznym źródłem danych prawie zawsze trwa dłużej, niż zakładał plan. API są różnie udokumentowane. Przypadki brzegowe się mnożą.
Przeciągające się cykle feedbacku. Dwutygodniowe opóźnienie przeglądu designu, powtórzone trzy razy, to sześć tygodni więcej w harmonogramie. To jedna z najczęstszych i najłatwiejszych do uniknięcia przyczyn opóźnień.
Jeden krok, który przesądza o wszystkim innym
Projekty, które zaczynają się od jasnej specyfikacji, kończą się szybciej.
Nie trochę szybciej. Konsekwentnie, wymiernie szybciej, z mniejszą liczbą niespodzianek i mniejszą liczbą kosztów, których nie było w pierwotnym planie.
Jeśli budujesz aplikację mobilną, ta jasność liczy się jeszcze bardziej: projekty mobilne mają więcej zmiennych niż większość innych.
Jasna specyfikacja to uzgodniona lista funkcji pierwszej wersji, udokumentowane ścieżki użytkowników, zdefiniowane ograniczenia techniczne i wspólne rozumienie tego, jak wygląda sukces w dniu startu. Nie za pół roku. W pierwszym dniu.
Do tego służy Discovery Workshop.
Zanim ruszy jakakolwiek budowa, wspólnie przepracowujemy produkt. Co zostanie zbudowane, w jakiej kolejności i co poczeka na wersję drugą. Jaka platforma ma sens. Jakie integracje są potrzebne od pierwszego dnia, a jakie później. Gdzie są ryzyka. Wychodzisz z dokumentem: nie z prezentacją sprzedażową, tylko z prawdziwą specyfikacją, na której może pracować zespół developerski.
To krok, który większość projektów pomija. I ten, którego najbardziej żalują projekty spóźnione i przekraczające budżet.
Chcesz wiedzieć, ile naprawdę zajmie twoja aplikacja? Zacznij tutaj.
