Jak wybrałem firmę do stworzenia aplikacji mobilnej w Polsce - moje doświadczenia

Kiedy zdecydowałem się zlecić budowę własnej aplikacji, byłem przekonany, że najważniejsze będzie porównanie stawek programistów za godzinę. Szybko się przekonałem, że to błąd. Po kilku rozmowach telefonicznych i dwóch spotkaniach na miejscu zrozumiałem, że liczy się coś innego: kompetencje zespołu, sposób prowadzenia projektu, jakość testów, podejście do bezpieczeństwa, doświadczenie tworzenia aplikacji mobilnych i plan utrzymania produktu po publikacji. Wykonawca, z którym ostatecznie zostałem, od razu tłumaczył, dlaczego proponuje konkretną technologię do moich wymagań biznesowych, zamiast po prostu polecać to, co akurat zna najlepiej.

Zanim zacząłem szukać firmy, sprawdziłem też statystyki rynkowe - Android odpowiada za ponad 70% globalnego rynku mobilnych systemów operacyjnych, a iOS za ponad jedną czwartą, choć proporcje różnią się w zależności od kraju i źródła danych. W moim przypadku klienci korzystali głównie z Androida, co od razu zawęziło rozmowy o platformy i urządzenia, na których produkt miał działać.

Od czego zacząć wybór firmy?

Od wymagań, nie od technologii - to wydawało się oczywiste, dopóki nie usiadłem z pierwszym wykonawcą i nie zacząłem odpowiadać na jego pytania. Zanim zdążyłem powiedzieć, jaką platformę wybieram, zapytał mnie o problem biznesowy i grupę odbiorców. Dopiero później rozmawialiśmy o interfejsie, funkcjach i wyborze platformy.
Przed pierwszym spotkaniem przygotowałem sobie notatkę z pięcioma punktami:

- cel biznesowy aplikacji
- najważniejsze funkcjonalności
- grupa użytkowników
- docelowe platformy
- oczekiwany termin i budżet

Wykonawca, z którym ostatecznie podpisałem umowę, zamienił moje odpowiedzi w konkretną specyfikację w ciągu tygodnia. Zwrócił też uwagę na dwie funkcje, które chciałem wrzucić do pierwszej wersji, a które - jego zdaniem - generowały koszt bez realnej wartości dla użytkowników.
Ponieważ mój pomysł był dość ryzykowny, zdecydowałem się na MVP. Zamiast płacić za rozbudowany system, zanim ktokolwiek go przetestował, zebraliśmy pierwsze dane od użytkowników i dopiero na ich podstawie planowaliśmy dalszy rozwój.

Jak ocenić doświadczenie software house'u?

Portfolio, które dostałem na start, wyglądało świetnie - ale szybko zrozumiałem, że ładny ekran nie mówi nic o jakości kodu, bezpieczeństwie ani stabilności aplikacji przy większym ruchu.
Zapytałem więc, czy w zespole są osoby odpowiedzialne za UX/UI, QA oraz architekturę, i czy ktoś z zespołu ma na koncie publikacje w Google Play i App Store. Poprosiłem też o dwa konkretne case'y o podobnej skali do mojego projektu.

Najbardziej przekonała mnie odpowiedź na pytanie, którego wcześniej nawet nie planowałem zadać: "Dlaczego wybraliście React Native, a nie aplikacje natywne?". Osoba prowadząca projekt odpowiedziała bez wahania, wymieniając konkretne ograniczenia wydajnościowe napotkane przy poprzednim kliencie. Inna firma odpowiedziała ogólnikowo, co dość szybko wykluczyło ją z mojej listy.

Zadałem też pytanie, które okazało się dobrym testem: "Co należałoby usunąć z pierwszej wersji produktu?". Zespół, który wybrałem, bez problemu wskazał trzy funkcje do wycięcia. Inny wykonawca odpowiedział, że "wszystko jest potrzebne" - i to był dla mnie sygnał ostrzegawczy.

Native, React Native, Flutter czy rozwiązanie hybrydowe?

Na początku byłem przekonany, że React Native to jedyny sensowny wybór, bo o nim najczęściej czytałem. Zespół programistów szybko mnie z tego wyprowadził.
W moim projekcie potrzebowaliśmy dostępu do aparatu, Bluetooth Low Energy i powiadomień push w tle - i to skłoniło programistów do rekomendacji Fluttera zamiast React Native. Osobne budowanie aplikacji natywnej w Kotlinie i Swifcie dla obu platform przekraczało nasz budżet na start.

Wybraliśmy Flutter, bo pozwalał zbudować interfejs i logikę dla obu platform z jednej bazy kodu, a przy dobrej architekturze wydajność w naszych typowych scenariuszach - przewijanie list, aparat, powiadomienia - była zbliżona do natywnej. Nie oznaczało to jednak, że każdy ekran wyglądał identycznie na iOS i Androidzie - kilka detali trzeba było dostosować osobno.
Przy okazji jeden z wykonawców zaproponował mi Xamarin. Zapytałem, dlaczego, skoro Microsoft zakończył jego wsparcie 1 maja 2024 roku i kieruje projekty w stronę .NET MAUI. Odpowiedź była wymijająca, więc tę firmę też skreśliłem z listy.

Jak powinno wyglądać projektowanie UX/UI?

Pierwszy projekt ekranów, jaki dostałem, wyglądał estetycznie, ale kiedy policzyłem kroki potrzebne do wykonania prostego przelewu w mojej aplikacji finansowej, wyszło dziewięć ekranów. Poczułem to na własnej skórze, klikając w prototyp - każdy dodatkowy krok na telefonie irytuje bardziej niż na komputerze.
Zanim zaakceptowałem projekt, projektanci UX zbadali potrzeby moich docelowych użytkowników, przygotowali architekturę informacji i interaktywny prototyp. Warstwa wizualna powstała dopiero na końcu.

Czy prototyp zostanie sprawdzony przed napisaniem kodu? Przesunięcie przycisku w prototypie zajęło programistce dziesięć minut; ta sama zmiana w gotowej aplikacji wymagałaby przebudowy kilku ekranów.

Czy projekt uwzględnia różne urządzenia? Testowałem prototyp na własnym telefonie, na starszym tablecie i na jednym urządzeniu składanym pożyczonym od znajomego - proporcje ekranów różniły się na tyle, że dwa elementy trzeba było poprawić jeszcze przed startem programowania.

Testowanie mówi więcej o firmie niż prezentacja sprzedażowa

QA w moim projekcie nie zostało zepchnięte na ostatni tydzień - testy szły równolegle z kolejnymi etapami, czego wcześniej nie doceniałem.
Zakres obejmował testy funkcjonalne, wydajnościowe, bezpieczeństwa i użyteczności. Emulator na komputerze programisty wyglądał świetnie, ale realny problem pojawił się dopiero na moim starszym telefonie z Androidem - aplikacja przestawała odpowiadać przy próbie zrobienia zdjęcia przy słabym sygnale sieci. Bez testów na fizycznym urządzeniu ten błąd trafiłby prosto do sklepu.
Do przekazywania kolejnych wersji testerom firma używała Firebase App Distribution - dostawałem powiadomienie, instalowałem build i zgłaszałem uwagi jeszcze tego samego dnia.

Bezpieczeństwo: jakie standardy powinien znać wykonawca?

Nie znałem się na bezpieczeństwie aplikacji mobilnych, więc zapytałem wprost, jakim standardem się kierują. Odpowiedź brzmiała: OWASP Mobile Application Security Verification Standard (MASVS) wraz z Mobile Application Security Testing Guide - i to był dla mnie punkt odniesienia przy kolejnych rozmowach z innymi wykonawcami.
Ponieważ logowanie w aplikacji opierało się na OAuth 2.0, dopytałem o obsługę tokenów i bezpieczny przepływ autoryzacji. Dane moich użytkowników z Unii Europejskiej wymagały też zgodności z RODO.
Jeden z wykonawców w prezentacji wspomniał o ERC-735 jako "standardzie bezpieczeństwa". Sprawdziłem później, że to koncepcja związana z zarządzaniem deklaracjami tożsamości w ekosystemie Ethereum, a nie uniwersalny standard bezpieczeństwa aplikacji - i akurat nie miała nic wspólnego z moim projektem.

Ile trwa i kosztuje stworzenie aplikacji?

Zanim podpisałem umowę, dostałem od jednej firmy cenę bez pytania mnie o cokolwiek - i to był dla mnie sygnał, żeby uciekać. Wiarygodna wycena pojawiła się dopiero po tym, jak zespół poznał liczbę ekranów, integracje, backend, poziom bezpieczeństwa i złożoność logiki.

Nasze MVP, bez płatności i geolokalizacji, było gotowe szybciej, niż zakładałem - mniej więcej w cztery miesiące od podpisania umowy do pierwszej publikacji w sklepie. Branżowy przedział 3-9 miesięcy okazał się sensowną orientacją, choć w moim przypadku dokładny czas zależał od liczby poprawek po testach z pierwszymi użytkownikami.

Flutter ograniczył nam pracę związaną z utrzymywaniem dwóch platform, ale nie obniżył budżetu tak bardzo, jak się spodziewałem - integracja z czytnikiem NFC wymagała dodatkowego kodu natywnego i podniosła koszt o około 15%.

Co powinno wydarzyć się po publikacji?

Publikacja w Google Play nie zakończyła projektu - to było dla mnie zaskoczenie, bo wcześniej traktowałem premierę jako metę.

Jeszcze przed podpisaniem umowy ustaliłem:
1. kto reaguje na awarie produkcyjne
2. jak mierzona jest wydajność
3. kto odpowiada za aktualizacje bibliotek
4. jak wygląda wsparcie techniczne
5. kto posiada kod źródłowy i dokumentację
6. jak rozliczany będzie dalszy rozwój aplikacji
Po trzech miesiącach od premiery dane analityczne pokazały, że użytkownicy porzucali proces rejestracji na trzecim ekranie. Bez tych danych podejmowałbym kolejne decyzje na wyczucie, a nie na podstawie realnego zachowania ludzi.

Jak rozpoznać dobrą ofertę na tworzenie aplikacji?

Porównywałem cztery oferty i tylko dwie z nich wyjaśniały proces, zamiast prezentować samą stawkę godzinową. Szukałem podziału na analizę, projektowanie, programowanie, testowanie, wdrożenie i utrzymanie - bez tego oferta była dla mnie tylko liczbą.

Przy porównaniu pomogła mi prosta tabela, którą sam sobie przygotowałem:


 

Jakie sygnały ostrzegawcze powinny zatrzymać projekt?

Pierwszy sygnał ostrzegawczy zobaczyłem już na pierwszym spotkaniu: dokładna cena i data bez jednego pytania o moich użytkowników. Drugi pojawił się, gdy wykonawca zaproponował technologię, zanim poznał funkcjonalności.
Ostrożności wymagały też projekty bez środowiska testowego, code review, automatycznego wdrożenia czy planu monitoringu. Gdy zapytałem jedną z firm, kto odpowiada za QA, usłyszałem, że "programiści sami testują swój kod" - to wystarczyło, żeby zrezygnować.
Dobry partner, którego ostatecznie wybrałem, nigdy nie obiecywał braku problemów. Pokazywał za to, jak problemy będą wykrywane i rozwiązywane.

FAQ: wybór firmy tworzącej aplikacje mobilne

Czy lepiej wybrać aplikację natywną czy wieloplatformową?
Z mojego doświadczenia zależy to od wymagań. Aplikacje natywne dają bezpośredni dostęp do możliwości platformy i wysoką wydajność. W moim projekcie React Native i Flutter sprawdziłyby się podobnie dobrze, bo najważniejsza była wspólna baza kodu dla iOS i Androida.
Czy sztuczna inteligencja zmniejsza koszt projektu?
W moim przypadku AI przyspieszyło część pracy programistycznej i analitycznej, ale nie zdjęło z zespołu obowiązku projektowania architektury, kontroli bezpieczeństwa, QA ani code review. Wygenerowany kod i tak przechodził przez ręce programisty.
Czy warto od razu budować pełną wersję?
Ja tego nie zrobiłem i nie żałuję. MVP pozwoliło mi sprawdzić hipotezę przy ograniczonym zakresie, a kolejne wdrożenia rozwijałem już na podstawie realnych danych od użytkowników.
Jak długo wybierać wykonawcę?
U mnie zajęło to niecałe trzy tygodnie, ale liczyła się jakość weryfikacji, nie liczba dni. Rozmowa techniczna, sprawdzenie portfolio, analiza procesu QA i bezpieczeństwa oraz doprecyzowanie praw do kodu oszczędziły mi później kosztownej zmiany dostawcy.
Podsumowanie
Kiedy patrzę wstecz, wybór firmy odpowiedzialnej za moją aplikację opierał się na dowodach, a nie na sympatii do konkretnego zespołu: na doświadczeniu, jakości procesu, kompetencjach UX/UI, podejściu do bezpieczeństwa, testach i planie utrzymania produktu.
Technologie okazały się tylko narzędziami. React Native, Flutter, Kotlin, Swift czy Objective-C rozwiązują różne problemy, a w moim projekcie liczyła się trafna analiza wymagań i dobrze zaprojektowany proces.
Jeśli szukasz podobnego wykonawcy, warto zwrócić uwagę na to samo, co ja sprawdzałem, zaczynając od samego tworzenia aplikacji mobilnych - kompetencje zespołu, podejście do testów i jasny plan po publikacji dają silniejszy sygnał niż obietnica dowolnej aplikacji w rekordowym terminie.
Dzięki temu własna aplikacja ma szansę stać się stabilnym produktem, z którego użytkownicy rzeczywiście chcą korzystać.