Projekt aplikacji mobilnej na zamówienie przechodzi cztery fazy: diagnozę, projekt, wdrożenie i optymalizację. W każdej zapada inna decyzja: czy aplikacja jest w ogóle potrzebna, co trafi do pierwszej wersji, w jakiej technologii powstanie i kto będzie ją utrzymywał po starcie. Poniżej opisujemy, co powstaje na każdym etapie i na czym projekty tracą najwięcej czasu.
Diagnoza: czy aplikacja mobilna jest potrzebna
Pierwsze pytanie, które zadajemy na starcie, dotyczy samego kanału. Aplikacja natywna ma sens, gdy produkt korzysta z funkcji telefonu (aparat, powiadomienia push, praca bez sieci, Bluetooth) albo gdy użytkownik wraca do niego kilka razy w tygodniu. Jeżeli kontakt z produktem jest rzadki, a treść da się obsłużyć w przeglądarce, tańsza w budowie i utrzymaniu będzie responsywna aplikacja webowa. Ta decyzja kosztuje jedną rozmowę. Podjęta po roku prac kosztuje cały budżet wdrożenia.
Wynik: decyzja, czy powstaje aplikacja mobilna, aplikacja webowa, czy oba kanały w ustalonej kolejności.
Warsztat produktowy
Gdy kanał jest wybrany, zakres pierwszej wersji ustalamy na warsztacie produktowym. Pracujemy na trzech narzędziach:
- persony, czyli opis typów użytkowników, ich celów i ograniczeń,
- user story mapping, czyli mapa czynności użytkownika, na której zaznacza się, co wchodzi do pierwszej wersji, a co czeka na kolejne,
- customer journey, czyli ścieżka od pierwszego kontaktu z produktem do regularnego korzystania.
Warsztat rozstrzyga spory, które bez niego wracają w połowie wdrożenia: która grupa użytkowników jest najważniejsza i z których funkcji można zrezygnować. Osoba odpowiedzialna za budżet dostaje zakres, który da się wycenić i obronić przed zarządem. Przy produktach ze złożonym procesem biznesowym dochodzi do tego warsztat Event Storming.
Wynik: lista funkcji pierwszej wersji z priorytetami, persony i mapa ścieżek użytkownika.
Projekt: od przepływów do prototypu
Projektowanie zaczynamy od przepływów, a kolory i typografia przychodzą później. User flow pokazuje kolejne kroki użytkownika i miejsca, w których może się zgubić. Na tej podstawie powstają makiety (wireframes), czyli szkieletowe wersje ekranów bez warstwy graficznej. Na makietach zmiana układu zajmuje godzinę, w kodzie kilka dni.
Kolejny krok to projekt interfejsu: typografia, kolor, komponenty i stany ekranów (pusty, ładowanie, błąd). Przy większych produktach powstaje od razu design system, czyli biblioteka komponentów i zasad, z której korzystają projektanci i programiści. Im wcześniej powstanie, tym mniej poprawek przy każdej kolejnej funkcji.
Przed wdrożeniem budujemy klikalny prototyp i pokazujemy go użytkownikom. Kilka rozmów z prototypem w ręku ujawnia problemy, których zespół nie widzi, bo zna produkt zbyt dobrze. Prototyp w Squares kosztuje od 8 000 zł netto, a kwota zależy od liczby ekranów i zakresu walidacji.
Na tym etapie zapada też decyzja o dostępności. Od 28 czerwca 2025 r. część usług cyfrowych dla konsumentów, między innymi handel elektroniczny i bankowość, musi spełniać wymagania dostępności wynikające z European Accessibility Act. Kontrast, wielkość pól dotyku i obsługę czytników ekranu taniej jest zaprojektować od początku, niż poprawiać po audycie. Zakres obowiązku opisujemy we wpisie o tym, kogo dotyczy EAA.
Wynik: projekt wszystkich ekranów pierwszej wersji, prototyp sprawdzony z użytkownikami i specyfikacja dla zespołu wdrożeniowego.
Wdrożenie: technologia, krótkie cykle i testy
Wybór technologii
Aplikacje mobilne budujemy we Flutterze. To zestaw narzędzi Google, który pozwala z jednego kodu źródłowego zbudować aplikację na Androida i iOS, a także wersję webową i desktopową. Jeden kod oznacza jeden zespół i jedną listę poprawek zamiast dwóch. Technologie natywne (Kotlin, Swift) wybiera się wtedy, gdy produkt mocno zależy od funkcji konkretnego systemu albo firma ma już zespół natywny. Kryteria wyboru opisujemy osobno we wpisie o technologiach aplikacji mobilnych.
Budowa w cyklach
Przed startem ustalamy zakres, kolejność prac i kryteria odbioru. Budujemy w dwutygodniowych cyklach, a każdy kończy się przeglądem działającej części produktu. Zmiany priorytetów wprowadzamy między cyklami, dzięki czemu nie przerywają pracy w toku. Product Owner po każdym przeglądzie wie, ile zakresu jest gotowe i ile budżetu zostało.
Testy
Każdą część testujemy ręcznie i automatycznie, zanim trafi do użytkowników: funkcje, wydajność, bezpieczeństwo i zgodność z projektem. Błąd znaleziony przed publikacją kosztuje godzinę pracy. Ten sam błąd po publikacji kosztuje dodatkowo oceny w sklepie i zgłoszenia do obsługi klienta. Jak udostępnić wersję próbną wybranym osobom przed publikacją, opisujemy we wpisie o testach beta w TestFlight i Google Play.
Publikacja w sklepach
Publikacja w App Store i Google Play ma własne formalności, które warto zacząć wcześniej niż w ostatnim tygodniu projektu. Firma zapisująca się do programu deweloperskiego Apple musi podać numer D-U-N-S przypisany do swojego podmiotu prawnego. Do tego dochodzą konta deweloperskie, opisy, zrzuty ekranu i deklaracje dotyczące danych. Weryfikacja konta i pierwsza recenzja aplikacji potrafią przesunąć start, jeśli zostaną na koniec.
Wynik: działająca aplikacja w obu sklepach, zbudowana zgodnie z projektem i udostępniana etapami.
Optymalizacja: co dzieje się po publikacji
Publikacja otwiera najdłuższą fazę projektu. Po starcie zbieramy dane o zachowaniach i opinie użytkowników, poprawiamy błędy i planujemy kolejne funkcje. Klient ma dostęp do panelu zgłoszeń, w którym widzi zgłoszone błędy i sugestie oraz stan prac nad nimi. Rozwój prowadzimy w ustalonej puli godzin miesięcznie, więc koszt jest przewidywalny.
Aplikacja mobilna wymaga też stałej obsługi technicznej: nowe wersje Androida i iOS, zmiany wymagań sklepów, aktualizacje bibliotek. Gdy od dostępności produktu zależy sprzedaż albo obsługa klientów, czas reakcji na awarię warto zapisać w umowie. Służy do tego usługa Opieka i SLA, rozliczana stałą opłatą miesięczną.
Wynik: produkt monitorowany i rozwijany na podstawie danych, z ustalonym czasem reakcji na awarie.
Ile kosztuje i ile trwa aplikacja mobilna na zamówienie?
Koszt zależy przede wszystkim od zakresu pierwszej wersji: liczby ekranów, integracji z innymi systemami, ról użytkowników i wymagań bezpieczeństwa. W Squares prototyp kosztuje od 8 000 zł netto, a wdrożenie zaczyna się od 20 000 zł netto. Wdrożenie wyceniamy z góry albo rozliczamy za przepracowany czas w stawce 250 zł netto za godzinę. Czas jest znany po etapie przygotowania, w którym ustalamy zakres i kryteria odbioru. Czynniki wpływające na cenę rozkładamy na części we wpisie o koszcie aplikacji mobilnej.
Budżet najczęściej przekraczają projekty, w których pominięto diagnozę. Zakres rośnie wtedy w trakcie wdrożenia, a każda zmiana jest wyceniana osobno.
Aplikacje mobilne w Squares
Aplikacje mobilne na zamówienie projektujemy i budujemy w jednym zespole, od warsztatu po utrzymanie, więc decyzje projektowe nie giną w drodze do kodu. Zakres i sposób rozliczenia opisuje strona usługi Wdrożenie. Zacznijmy od rozmowy o zakresie: porozmawiajmy o projekcie.
Najczęstsze pytania
Ile trwa stworzenie aplikacji mobilnej na zamówienie?
Czas zależy od zakresu pierwszej wersji i jest znany po etapie przygotowania, w którym ustalamy zakres i kryteria odbioru. Budowa przebiega w dwutygodniowych cyklach, a każdy kończy się przeglądem działającej części produktu. Start potrafią przesunąć formalności w App Store i Google Play, dlatego zaczyna się je wcześniej niż w ostatnim tygodniu projektu.
Od czego zacząć projekt aplikacji mobilnej?
Od diagnozy, czyli pytania, czy aplikacja mobilna jest w ogóle potrzebna, czy wystarczy responsywna aplikacja webowa. Kolejne etapy tworzenia aplikacji mobilnej to warsztat produktowy, na którym powstaje zakres pierwszej wersji, projekt z klikalnym prototypem, wdrożenie i optymalizacja po publikacji. Projekty bez diagnozy najczęściej przekraczają budżet.
