Stworzenie aplikacji mobilnej — od czego zacząć

Krótka odpowiedź: zacznij od nazwania jednej czynności, którą aplikacja ma skrócić. Jeśli potrafisz ją opisać w jednym zdaniu — masz fundament projektu. Jeśli nie potrafisz, aplikacja nie jest jeszcze potrzebna. Kod to ostatni etap, nie pierwszy.

Czy na pewno potrzebujesz aplikacji?

To pytanie, którego większość wykonawców nie zada, bo aplikacja jest droższa od strony. My je zadajemy, bo źle dobrane narzędzie to spalony budżet i rozczarowanie.

Aplikacja ma sens, gdy: użytkownik wraca regularnie (codziennie, co tydzień), potrzebujesz aparatu, GPS-u albo pracy bez internetu, chcesz wysyłać powiadomienia, albo Twój zespół pracuje w terenie i potrzebuje narzędzia w kieszeni.

Aplikacja nie ma sensu, gdy: klient skorzysta raz albo dwa razy w roku, a wszystko, czego potrzebujesz, to formularz i katalog. Wtedy dobra strona mobilna zrobi to samo, taniej i bez bariery instalowania czegokolwiek.

Najdroższa aplikacja to ta, którą klient zainstaluje raz, użyje raz i usunie, bo mógł to samo zrobić na stronie w dziesięć sekund.

Cztery etapy, które zawsze wyglądają tak samo

1. Warsztat i zakres

Godzina rozmowy, w której rozbieramy pomysł na czynności: kto, co i po co robi w aplikacji. Efektem jest lista funkcji podzielona na te niezbędne i te „byłoby miło”. Ten podział decyduje o budżecie bardziej niż cokolwiek innego.

2. Klikalna makieta

Zanim powstanie linia kodu, dostajesz makietę, którą klikasz na własnym telefonie. Wyglądem przypomina gotową aplikację, ale w środku jest pusta. To najtańszy moment na zmiany — poprawka na makiecie kosztuje minuty, ta sama poprawka w gotowej aplikacji kosztuje dni.

3. Budowa

Kod, testy na prawdziwych urządzeniach, panel do zarządzania. Dostajesz wersje testowe po drodze, żeby nie okazało się na końcu, że mieliśmy w głowach dwie różne aplikacje.

4. Publikacja i opieka

Konto dewelopera, opisy, zrzuty ekranu, polityka prywatności, weryfikacja w sklepach. Potem aktualizacje przy każdej większej zmianie iOS i Androida.

Co decyduje o koszcie i czasie

• Liczba ekranów, które robią coś nietypowego. Dwadzieścia ekranów z listami jest tańsze niż pięć ekranów z mapą, skanerem i płatnościami.
• Konto użytkownika i role. Sama możliwość logowania to nie problem. Problemem jest to, co kto może zobaczyć i zmienić.
• Praca bez internetu. Jeśli aplikacja ma działać w terenie i synchronizować dane po powrocie do zasięgu, to osobny mechanizm — i jeden z droższych.
• Integracje z Twoimi systemami. Magazyn, faktury, CRM. Koszt zależy nie od Twojej aplikacji, tylko od tego, jak przyjazny jest cudzy system.
• Panel administracyjny. Często zapominany, a to praktycznie druga aplikacja — tyle że w przeglądarce.

Natywnie czy z jednego kodu?

Przez lata aplikację trzeba było budować osobno na iPhone’a i osobno na Androida — dwa zespoły, dwa kody, dwa razy tyle pracy przy każdej zmianie. Dziś w większości projektów biznesowych buduje się obie wersje z jednego kodu. Wygląd i szybkość są nie do odróżnienia dla użytkownika, a Ty płacisz raz i aktualizujesz raz.

Osobne aplikacje natywne nadal mają sens przy zaawansowanej grafice trójwymiarowej, ciężkim przetwarzaniu obrazu w czasie rzeczywistym albo nietypowych funkcjach sprzętowych. W typowej aplikacji dla firmy usługowej to zbędny wydatek.

MVP, czyli czego świadomie nie budować na start

MVP to nie jest „tania wersja aplikacji”. To wersja, która robi jedną rzecz porządnie i pozwala sprawdzić, czy ludzie w ogóle chcą jej używać. Do MVP wchodzi zwykle: jedna główna czynność, logowanie i prosty panel. Poza MVP zostaje wszystko, co brzmi jak „a fajnie by było, gdyby jeszcze…”.

To nie jest oszczędzanie na jakości — to unikanie budowania funkcji, których nikt nie użyje. Pierwsi użytkownicy w tydzień pokażą Ci rzeczy, których nie wymyślisz na żadnym warsztacie.

Publikacja w sklepach — czego się nie spodziewasz

Sama weryfikacja aplikacji zwykle trwa od jednego do kilku dni roboczych. Zaskakuje raczej to, co trzeba przygotować wcześniej: konto dewelopera (osobne dla każdego sklepu, odnawiane co roku), komplet zrzutów ekranu w wymaganych rozmiarach, opis, polityka prywatności pod adresem publicznym i deklaracja, jakie dane aplikacja zbiera.

Odrzucenia zdarzają się najczęściej z powodów formalnych — brakującej polityki prywatności albo niejasnego opisu tego, po co aplikacji dostęp do lokalizacji. To do naprawienia w kilka godzin, ale warto wliczyć ten etap w harmonogram zamiast traktować go jak formalność.

Co po starcie

Aplikacja nie jest projektem z datą końcową, tylko produktem. Systemy mobilne zmieniają się co roku, a wraz z nimi wymagania sklepów. Aplikacja bez aktualizacji po dwóch latach zaczyna działać gorzej, a po trzech potrafi zniknąć ze sklepu. Warto założyć stały roczny koszt utrzymania już na etapie decyzji, żeby nie okazało się, że budżet skończył się w dniu premiery.

Najczęstsze pytania

Czy mogę zacząć od strony, a aplikację zrobić później?

To bardzo często najrozsądniejsza kolejność. Strona zweryfikuje zainteresowanie i zbierze pierwszych klientów, a Ty poznasz ich zachowania, zanim zamrozisz budżet w aplikacji. Wiele funkcji, które wydają się wymagać aplikacji, da się najpierw przetestować na stronie.

Czy aplikacja pomoże mi w Google?

Bezpośrednio nie — aplikacje nie są indeksowane tak jak strony. Widoczność w wyszukiwarkach budujesz treścią na stronie. Aplikacja pracuje na utrzymanie klientów, których już masz, a nie na pozyskiwanie nowych z wyszukiwania.

Kto jest właścicielem kodu?

To pytanie zadaj każdemu wykonawcy przed podpisaniem umowy. U nas kod i konta należą do klienta — bez tego jesteś zakładnikiem jednej firmy przy każdej najdrobniejszej zmianie.

Ile osób musi zainstalować aplikację, żeby się opłaciła?

Przy aplikacji dla firmy zwykle nie liczy się instalacji, tylko zaoszczędzony czas. Jeśli narzędzie skraca wycenę albo pomiar o kwadrans i robisz to codziennie, rachunek zamyka się szybciej, niż wygląda na starcie.