Ile trwa stworzenie aplikacji mobilnej i co decyduje o terminie

Ile trwa stworzenie aplikacji mobilnej — na to pytanie nie ma jednej liczby, bo o terminie decyduje nie objętość kodu, tylko tempo decyzji, dostępność materiałów i weryfikacja po stronie sklepów. Ten sam zestaw funkcji potrafi powstawać dwa razy dłużej, jeśli akceptacja makiet czeka tydzień na wolne okienko w kalendarzu zarządu. Dlatego harmonogram rozkładam poniżej na etapy w procentach całości projektu: procent jest odporny na skalę i działa tak samo dla aplikacji z trzema ekranami, jak i z trzydziestoma.

Od czego zależy czas budowy aplikacji i dlaczego jedna liczba nie istnieje

Czas projektu wyznaczają cztery zmienne: zakres pierwszej wersji, liczba integracji z systemami trzecich stron, tempo akceptacji po stronie zamawiającego oraz wymagania sklepów z aplikacjami. Tylko pierwsza z nich jest w pełni po stronie zespołu wykonawczego, a i ona zależy od tego, jak szybko zamkniesz listę funkcji.

Widełki w rodzaju „od dwóch tygodni do trzech miesięcy” są bezużyteczne, bo nie mówią, gdzie leży ryzyko obsuwy. Termin rzadko sypie się na kodowaniu — najczęściej na czekaniu: na decyzję, na materiały, na dostęp do cudzego API, na wynik weryfikacji w sklepie. Zanim zapytasz kogokolwiek o datę, zamknij zakres pierwszej wersji, czyli MVP, bo bez tego każdy termin jest zgadywanką.

Harmonogram w procentach: gdzie realnie idzie czas

Rozbicie harmonogramu na udziały procentowe pokazuje ryzyko lepiej niż widełki w tygodniach, bo proporcje między etapami zmieniają się wolniej niż całkowita długość projektu. Poniższy rozkład to model do rozmowy z wykonawcą, a nie dane branżowe — użyj go, żeby zapytać, ile w twoim projekcie ważą etapy, o których nikt nie pamięta.

Proporcja jest tu ważniejsza od pojedynczych liczb: samo programowanie zajmuje mniej więcej dwie piąte czasu. Pozostała część to decyzje, materiały, testy i procedury, czyli obszar, na który jako zamawiający masz największy wpływ. Cały proces budowy aplikacji mobilnej krok po kroku to osobny temat; tutaj interesuje nas wyłącznie zegar.

Czas, którego nikt nie liczy, bo to nie jest programowanie

Największa część obsuw bierze się z pracy, która nie jest pisaniem kodu i dlatego nie trafia do wyceny godzinowej. Warto wypisać ją wprost, zanim ktokolwiek poda datę premiery:

• Weryfikacja w sklepach. Apple sprawdza aplikacje ręcznie w ramach App Review, Google Play opiera się w większym stopniu na weryfikacji automatycznej. Odrzucenie oznacza poprawkę i kolejną turę weryfikacji od początku.
• Akceptacje po twojej stronie. Jedna nieodebrana decyzja o wyglądzie ekranu potrafi zatrzymać cały sprint, bo zespół nie buduje czegoś, co może się jeszcze zmienić.
• Zbieranie materiałów. Treści, zdjęcia produktów, regulamin, polityka prywatności i dane startowe do bazy. To praca twoich ludzi, nie wykonawcy.
• Integracje zależne od trzeciej strony. Dostęp do API, konta testowe, limity zapytań, zgody i podpisane umowy powierzenia. Procedura u dostawcy bywa dłuższa niż sama implementacja.
• Testy akceptacyjne i poprawki po nich. Ktoś po twojej stronie musi realnie klikać aplikację, a zgłoszone uwagi wracają do zespołu jako dodatkowa praca.
• Wymuszone aktualizacje. Sklepy narzucają terminy targetowania API niezależnie od twojego zakresu, o czym niżej.

Pięć rzeczy po stronie zamawiającego, które wydłużają projekt

Każdą z nich da się zdjąć z drogi krytycznej jedną decyzją podjętą przed startem, a nie w trakcie.

1. Decyzja bez właściciela. Ustal jedną osobę z prawem akceptacji makiet i tekstów, z imienia i nazwiska, oraz zastępcę na czas urlopu.
2. Akceptacja przez komitet. Zbierz uwagi wewnętrznie i przekaż zespołowi jedną, uzgodnioną listę zamiast sprzecznych komentarzy od czterech osób.
3. Materiały „na później”. Nadaj każdemu pakietowi treści konkretną datę dostarczenia i właściciela, tak samo jak zadaniu programistycznemu.
4. Dostępy zamawiane w ostatniej chwili. Klucze API i konta testowe zamów na etapie architektury, a nie w dniu, w którym zaczyna się integracja.
5. Zmiana zakresu w trakcie sprintu. Nowe pomysły zapisuj na liście kolejnego wydania; wstrzymanie trwającego sprintu kosztuje więcej niż odłożenie funkcji o dwa tygodnie.

Różnica między deklaracją a zobowiązaniem wygląda w praktyce tak:

Jeśli chcesz uporządkować to wszystko przed pierwszą rozmową, opisz projekt w kreatorze briefu — sześć kroków, na końcu gotowa wiadomość z tym, co zespół musi wiedzieć, żeby w ogóle mówić o terminie.

Publikacja: co realnie trwa przy wejściu do App Store i Google Play

Publikacja to osobny etap projektu z własnym ryzykiem, nie formalność wykonywana w dniu wysyłki buildu. Apple weryfikuje aplikacje ręcznie, więc czas nie jest gwarantowany, a odrzucenie cofa cię do kolejki po naniesieniu poprawek. Google Play w większym stopniu polega na weryfikacji automatycznej, ale i tam trzeba przejść przez konfigurację listingu, deklaracje dotyczące danych i zasady treści. Jeśli data premiery jest twarda, ten etap można ominąć, wydając najpierw PWA na iOS i Androidzie — instalowaną z przeglądarki, bez kolejki w sklepie, ale i bez części funkcji urządzenia.

Do tego dochodzą procedury administracyjne po stronie właściciela konta. Google może wymagać weryfikacji tożsamości dewelopera — to zadanie dla twojego działu prawnego albo księgowości, nie dla zespołu programistów, i lepiej mieć je zamknięte na długo przed premierą.

Osobno zaplanuj testy zewnętrzne. TestFlight pozwala zaprosić do 10 000 testerów spoza organizacji, ale build udostępniany tej grupie przechodzi osobną weryfikację po stronie Apple. Jeśli planujesz pilotaż na prawdziwych użytkownikach przed premierą, to nie jest jeden krok, tylko dwa przejścia przez weryfikację.

Terminy, które sklepy narzucają niezależnie od twojego zakresu

Google Play wymaga, żeby od 31 sierpnia 2026 nowe aplikacje i aktualizacje targetowały Androida 16 (API 36) lub wyższy, a aplikacje już opublikowane — co najmniej Androida 15 (API 35). W Play Console można wnioskować o przedłużenie terminu do 1 listopada 2026. To praca, której nikt nie zamawiał, ale która musi się zmieścić w planie, jeśli okno projektu obejmuje tę datę.

Ten sam mechanizm działa co roku i dotyczy również aplikacji utrzymywanych po premierze. Przy planowaniu budżetu na rozwój — temat, który rozwijamy przy okazji tego, ile kosztuje aplikacja mobilna — traktuj wymuszone aktualizacje jako pozycję stałą, nie awarię.

Jak rozmawiać o terminie, żeby obie strony wiedziały, na czym stoją

Zamiast pytać „na kiedy będzie gotowe”, zapytaj o trzy rzeczy: jaki zakres mieści się w tej dacie, które etapy zależą od twoich decyzji i co się stanie z terminem, gdy akceptacja spóźni się o tydzień. Odpowiedzi na te pytania są weryfikowalne, a data podana bez nich nie jest.

Praca zwykle toczy się w sprintach dwutygodniowych, a przegląd na koniec sprintu jest naturalnym momentem odbioru cząstkowego — wtedy widać, czy proporcje z tabeli się zgadzają. Typowy skład zespołu to project manager, analityk, projektant UX/UI, developerzy iOS, Android i backendu oraz QA; im więcej ról musi czekać na jedną twoją decyzję, tym drożej kosztuje każdy dzień zwłoki. Kolejność etapów wdrożenia aplikacji warto mieć przed oczami już przy pierwszej rozmowie o terminie, bo to ona pokazuje, gdzie w kalendarzu wypadają twoje zadania.