Aby zlecić aplikację mobilną, przejdź przez sześć kroków: opis problemu i budżetu, brief, wybór wykonawcy, projekt ekranów, budowę w etapach z wersjami testowymi oraz odbiór z publikacją w sklepach. Niezależnie od budżetu pieniądze chroni przede wszystkim dobry brief i odbiór na własnych danych, a nie negocjacja stawki.
Poniżej znajdziesz brief w 12 punktach do skopiowania, kryteria wyboru wykonawcy, przebieg projektu od kick-offu do odbioru, pytania do zadania przed startem i listę kontrolną odbioru. Tekst jest dla osoby, która pierwszy raz ma zlecić aplikację mobilną i nie chce uczyć się na własnym budżecie.
Od czego zacząć zlecenie aplikacji mobilnej?
Od problemu, nie od listy funkcji. Zanim otworzysz edytor, zapisz w dwóch zdaniach, co dziś nie działa i kto na tym traci. Na przykład „Handlowcy tracą dzień w tygodniu na przepisywanie zamówień” to dobry początek, natomiast „Chcemy nowoczesną aplikację” - nie.
Następnie ustal budżet i termin. Nie musisz znać ceny, ale musisz znać granicę. Koszt aplikacji na zamówienie zależy od zakresu, a najtańszym startem jest zwykle MVP, czyli pierwsza wersja z jedną ścieżką użytkownika. Aktualne ceny AppCreo znajdziesz w cenniku.
Podany przedział pozwala wykonawcy zaproponować zakres, zamiast zgadywać. Jeśli pomysł jest nowy i nie wiesz, czy użytkownicy go przyjmą, zacznij od MVP. Jak ocenić pomysł, zanim wydasz pieniądze, piszemy w tekstach ile wart jest pomysł na aplikację i jak zwalidować pomysł.
Nazwa aplikacji - sprawdź ją na początku
Nazwę wybierz przed briefem, bo trafi do sklepów, domeny i materiałów. Sprawdź, czy w App Store i Google Play nie ma aplikacji o podobnej nazwie, i przejrzyj bazy znaków towarowych Urzędu Patentowego RP oraz EUIPO. W obu sklepach nazwa może mieć do 30 znaków.
Jak napisać brief aplikacji mobilnej?
Żeby zlecić aplikację mobilną, nie potrzebujesz specyfikacji technicznej, tylko briefu. To raczej dokument na kilka stron, z którego wykonawca zrozumie cel, użytkowników i ograniczenia. Opisuj sytuacje, a nie gotowe rozwiązania: „kierownik musi w 10 sekund zobaczyć, która ekipa się spóźnia” mówi więcej niż „dashboard z wykresami”.
| Punkt briefu | Co opisać | Przykład (firma serwisowa) |
|---|---|---|
| 1. Cel biznesowy | Jaki problem rozwiązuje aplikacja i po czym poznasz sukces | Zlecenie przyjęte w minuty, nie w godziny |
| 2. Użytkownicy i role | Kto korzysta, ilu jest użytkowników, jakie mają uprawnienia | 40 serwisantów, 3 dyspozytorów, kierownik |
| 3. Kontekst użycia | Gdzie i w jakich warunkach używa się aplikacji | Piwnice i hale bez zasięgu, praca w rękawicach |
| 4. Najważniejsza ścieżka | Jeden scenariusz od początku do końca, krok po kroku | Przyjęcie zlecenia, dojazd, protokół ze zdjęciami, podpis klienta |
| 5. Funkcje z priorytetem | Co musi być w wersji pierwszej, a co może poczekać | Teraz: zlecenia, zdjęcia, podpis. Później: czat, statystyki |
| 6. Platformy i urządzenia | Android, iOS, tablety, sprzęt służbowy lub prywatny | Służbowe telefony z Androidem, tablet u dyspozytora |
| 7. Integracje | Z jakimi systemami aplikacja wymienia dane i czy mają API | ERP (eksport zleceń), program do faktur |
| 8. Panel administracyjny | Kto i co zmienia bez udziału programisty | Dyspozytor przydziela zlecenia i edytuje listę usług |
| 9. Dane i bezpieczeństwo | Jakie dane osobowe, gdzie są przechowywane, kto ma dostęp | Dane klientów i podpisy, serwery w UE |
| 10. Wygląd i materiały | Identyfikacja wizualna, aplikacje, które się podobają i które nie | Księga znaku, prostota aplikacji kurierskiej |
| 11. Budżet i termin | Przedział kwoty i data, od której aplikacja jest potrzebna | Przedział kwoty netto, pilotaż przed sezonem |
| 12. Po wdrożeniu | Kto utrzymuje aplikację, jak zgłaszać błędy, plany rozwoju | Umowa serwisowa, zgłoszenia przez dyspozytora |
Co dołączyć do briefu?
Dołącz też wszystko, co już masz: zrzuty ekranów obecnych narzędzi, wzory dokumentów, eksport danych, nagranie ekranu z procesu. Takie materiały skracają analizę bardziej niż kolejna strona opisu.
Jeśli nie potrafisz wypełnić punktów 5 i 7, to normalne - dobry wykonawca doprecyzuje je na warsztacie. Brak odpowiedzi na punkty 1, 2 i 11 oznacza jednak, że na zlecenie aplikacji mobilnej jest jeszcze za wcześnie.
Komu zlecić aplikację mobilną?
Masz trzy modele: software house, freelancer i platforma no-code, które różnią się ceną, ryzykiem i tym, co zostaje po projekcie. Szczegółowe porównanie trzech modeli opisujemy w tekście software house, freelancer czy no-code.
Następnie wyślij brief do trzech–pięciu firm. Mniej nie da punktu odniesienia, natomiast więcej zamieni wybór w przegląd prezentacji. Na pierwszej rozmowie zwracaj uwagę, czy wykonawca dopytuje o proces i użytkowników, czy od razu mówi o technologii.
Jak porównać oferty
Oferty na tę samą aplikację potrafią różnić się kilkukrotnie. Zwykle nie dlatego, że ktoś oszukuje, tylko dlatego, że każdy wycenił inny zakres. Dlatego sprowadź je do wspólnego mianownika:
- Czy wycena obejmuje projekt UX/UI, backend, panel administracyjny, testy i publikację, czy tylko „aplikację”?
- Jakie przyjęto założenia: liczba ekranów, ról, integracji, wersji językowych?
- Jaki jest model rozliczenia: stała cena za etap czy czas i materiały? Różnice opisujemy w tekście fixed price czy time & material.
- Jaka jest stawka godzinowa i ile godzin przypada na każdy etap?
- Co obejmuje gwarancja, kiedy przechodzą prawa autorskie i kod źródłowy, ile kosztuje utrzymanie?
Jak czytać pozycje wyceny, żeby znaleźć ukryte koszty, pokazujemy w artykule jak czytać wycenę software house’u. Pytania na pierwsze spotkanie i sposób weryfikacji firmy w KRS zebraliśmy natomiast w tekście jak wybrać software house.
Jak wygląda projekt od kick-offu do odbioru?
Dobrze prowadzony projekt nie znika na kilka miesięcy, żeby pojawić się z gotową aplikacją. Zamiast tego postęp widzisz regularnie na własnym telefonie. Typowy przebieg wygląda tak:
- Kick-off i warsztat: najpierw przechodzicie przez brief, ustalacie role, kanał komunikacji i rytm spotkań. Wykonawca dostaje też dostęp do osób, które znają proces.
- Analiza i zakres: powstaje dokument z listą funkcji, ścieżkami użytkowników i podziałem na wersję pierwszą i „później”. To moment na zmiany, które kosztują tylko czas rozmowy.
- Projekt UX/UI: makiety, potem klikalny prototyp wszystkich ekranów do akceptacji. Szczegóły opisujemy w przewodniku projektowanie UX/UI aplikacji mobilnej.
- Budowa w etapach: kod powstaje w krótkich sprintach, zwykle dwutygodniowych. Po każdym dostajesz wersję testową przez TestFlight na iOS i ścieżkę testów wewnętrznych w Google Play.
- Backend i panel: równolegle z aplikacją powstaje serwer, API i panel administracyjny. Integracje z Twoimi systemami testuje się na kopii danych.
- Testy: sprawdzenie na realnych urządzeniach, przy słabym zasięgu i na Twoich danych. Błędy dzieli się na blokujące publikację i te do kolejnej wersji.
- Publikacja: karta aplikacji, zrzuty ekranu, polityka prywatności, formularze o danych i weryfikacja przez Apple oraz Google.
- Odbiór i gwarancja: na koniec protokół odbioru uruchamia okres gwarancji oraz przekazanie kodu, dokumentacji i dostępów.
Harmonogram w tygodniach dla trzech wielkości projektu znajdziesz w tekście ile trwa zbudowanie aplikacji, a to, jak ten proces wygląda u nas, na stronie proces współpracy.
Konta w sklepach zakładaj na własną firmę
Jeśli chcesz zlecić aplikację mobilną, zadbaj, by trafiła na Twoje konto deweloperskie, a nie na konto wykonawcy. Apple Developer Program jest płatny co roku, a konto organizacji wymaga numeru D-U-N-S - złóż wniosek na starcie projektu. Google Play pobiera natomiast jednorazową opłatę rejestracyjną.
Konta osobiste w Google Play założone po 13 listopada 2023 roku muszą przed publikacją przeprowadzić test zamknięty z co najmniej 12 testerami przez 14 dni z rzędu. Konta organizacji tego wymogu jednak nie mają - to kolejny powód, by aplikacja firmowa trafiła na konto firmy.
Opisz aplikację w 3 zdaniach - odsyłamy przedział cenowy w 24 h w dni robocze. Wystarczy: co ma robić, dla kogo i ile osób będzie z niej korzystać. Brief w 12 punktach możesz dosłać później. wypełnij formularz, napisz na biuro@appcreo.pl albo zadzwoń: +48 783 477 243.
Jakie pytania zadać wykonawcy przed startem projektu?
Umowa jest podpisana, ale zanim ruszy pierwszy sprint, ustal zasady codziennej współpracy. Te pytania wyjaśniają większość nieporozumień, zanim się pojawią.
| Pytanie | Dobra odpowiedź | Sygnał ostrzegawczy |
|---|---|---|
| Kto prowadzi projekt po Waszej stronie? | Imiennie wskazana osoba, stały kanał i czas odpowiedzi | „Proszę pisać na ogólny adres” |
| Jak często zobaczę działającą wersję? | Po każdym sprincie, na moim telefonie | Dopiero na końcu projektu |
| Jak zgłaszam zmianę zakresu? | Opis, wycena, akceptacja na piśmie przed pracą | „Dogadamy się w trakcie” |
| Gdzie jest repozytorium kodu? | Moment przekazania kodu i praw autorskich zapisany w umowie | Brak zapisu o przekazaniu kodu w umowie |
| Na czyich kontach będą sklepy, serwery i domeny? | Na kontach klienta, wykonawca jako użytkownik | Na koncie wykonawcy, „dla wygody” |
| Jak testujecie i na jakich urządzeniach? | Lista urządzeń, testy przy słabym zasięgu, raport błędów | „Programiści sami sprawdzają” |
| Kto przygotuje politykę prywatności i dane do sklepów? | Podział zadań ustalony na starcie | Temat pojawia się w dniu publikacji |
| Co obejmuje gwarancja? | Okres, czas reakcji i zakres zapisane w umowie | „Poprawimy, jeśli coś wyjdzie” |
| Co dzieje się po publikacji? | Oferta utrzymania z zakresem i ceną | Brak planu po wdrożeniu |
Zapisy, które warto przenieść z tych odpowiedzi do umowy - prawa autorskie, procedurę zmian, kary i gwarancję - omawiamy w artykule umowa z software housem.
Jak odebrać aplikację mobilną i niczego nie przeoczyć?
Odbiór to moment, w którym tracisz najwięcej siły negocjacyjnej: po podpisaniu protokołu poprawki przechodzą w tryb gwarancji. Dlatego nie podpisuj go po jednym przejrzeniu aplikacji na spotkaniu.
Przygotuj scenariusze testowe z punktu 4 briefu i przejdź je samodzielnie - na własnych danych i na telefonach, których używają Twoi użytkownicy. Zanotuj każdy błąd ze zrzutem ekranu i opisem kroków. Przed podpisaniem protokołu sprawdź też listę:
- wszystkie funkcje z zakresu wersji pierwszej działają na Androidzie i iOS,
- błędy blokujące są usunięte, a pozostałe spisane z terminem poprawki,
- aplikacja jest opublikowana z kont Twojej firmy i przeszła weryfikację sklepów,
- masz dostęp do serwerów, panelu administracyjnego i analityki, a umowa określa termin przekazania repozytorium po zapłacie ostatniej faktury,
- dostałeś dokumentację: architekturę, instrukcję wydania nowej wersji, listę kont,
- działa raportowanie awarii, więc po starcie zobaczysz, co się psuje i u kogo,
- osoby obsługujące panel przeszły szkolenie,
- protokół zawiera datę startu gwarancji i zakres utrzymania.
Szerzej o testach przed odbiorem piszemy w przewodniku testowanie aplikacji mobilnych, a o formalnościach sklepów w tekście publikacja aplikacji w App Store i Google Play.
Pierwsze tygodnie po starcie
Zlecenie aplikacji mobilnej nie kończy się w dniu publikacji, bo po starcie przychodzą zgłoszenia od prawdziwych użytkowników. Zaplanuj budżet i czas zespołu na poprawki, zamiast zamykać projekt w dniu publikacji. Utrzymanie aplikacji kosztuje zwykle 15–25% wartości projektu rocznie.
Jeśli chcesz zlecić aplikację mobilną wykonawcy, który przeprowadzi Cię przez wszystkie te etapy, zobacz, jak prowadzimy tworzenie aplikacji mobilnych, i sprawdź ceny w cenniku.
