Ile kosztuje aplikacja mobilna w 2026 roku: natywna, cross-platform (Flutter, React Native) czy PWA

Dyrektor zarządzający sieci czterdziestu klubów fitness dostał od agencji marketingowej rekomendację: „Potrzebujecie aplikacji mobilnej”. Członkowie mają w niej rezerwować zajęcia, płacić za karnety, zbierać punkty i dostawać powiadomienia o zwolnionych miejscach. Pierwsza wycena, od software house’u specjalizującego się w aplikacjach natywnych, opiewa na 1,3 miliona złotych. Druga, od zespołu pracującego we Flutterze, na 700 tysięcy. Trzecia, od agencji, która proponuje progresywną aplikację webową, na 350 tysięcy. Każdy dostawca przekonuje, że jego podejście jest właściwe, i każdy ma w tym trochę racji.

Zarząd nie potrzebuje wykładu o technologiach. Potrzebuje odpowiedzi na trzy pytania: skąd bierze się prawie czterokrotna różnica, co tracimy, wybierając tańszy wariant, i ile będzie nas to kosztować co roku po premierze. Na pierwsze dwa pytania odpowiedź da się policzyć. Trzecie jest najczęściej pomijane w ofertach, a w aplikacjach mobilnych ma większe znaczenie niż w webowych, bo Apple i Google co roku zmieniają zasady, do których aplikacja musi się dostosować, żeby pozostać w sklepie.

W tym artykule pokazujemy, ile kosztuje aplikacja mobilna w 2026 roku w trzech wariantach: natywnym (Swift na iOS, Kotlin na Androida), cross-platform (Flutter lub React Native) i PWA. Liczymy ten sam produkt trzema sposobami, z jawnym składem zespołu, czasem i stawkami z naszego cennika, a potem dokładamy opłaty sklepowe i koszt utrzymania. Każde założenie możesz podmienić na własne.

Dlaczego pytanie „ile kosztuje aplikacja mobilna” nie ma jednej odpowiedzi?

Bo „aplikacja mobilna” to nazwa kategorii, a nie produktu. Pod tą samą nazwą kryje się aplikacja z trzema ekranami pokazująca treści z istniejącej strony i aplikacja bankowa z biometrią, płatnościami i trybem offline. Różnica w koszcie między nimi jest kilkunastokrotna. Żaden rzetelny dostawca nie poda ceny „aplikacji mobilnej” bez zrozumienia, co ma robić.

Ale nawet dla tego samego zakresu funkcji koszt zależy od decyzji technologicznej, i to tej decyzji dotyczy rozrzut w ofertach z przykładu. Aplikacja natywna to w praktyce dwie aplikacje, osobno na iOS i Androida, pisane przez dwa zespoły w dwóch językach. Aplikacja cross-platform to jeden kod, z którego powstają obie wersje. PWA to aplikacja webowa, którą użytkownik może „zainstalować” z przeglądarki, bez sklepu. Każde z tych podejść ma inny koszt budowy, inny koszt utrzymania i inne ograniczenia.

Trzecia zmienna to backend. Prawie każda aplikacja mobilna potrzebuje serwera: kont użytkowników, logiki biznesowej, płatności, wysyłki powiadomień, panelu administracyjnego. Ta część kosztuje tyle samo niezależnie od tego, jak zbudujesz warstwę mobilną. Dlatego wybór technologii mobilnej nigdy nie zmienia kosztu o połowę, nawet jeśli dostawca tak sugeruje.

Wreszcie aplikacja mobilna, w odróżnieniu od webowej, żyje w ekosystemie, który kontrolują dwie firmy. Apple i Google ustalają opłaty, prowizje, zasady recenzji i terminy obowiązkowych aktualizacji. To koszt, którego nie negocjujesz, ale który musisz zaplanować.

Czym w praktyce różnią się aplikacja natywna, cross-platform i PWA?

Aplikacja natywna jest pisana osobno dla każdej platformy w jej języku i narzędziach: Swift i SwiftUI na iOS, Kotlin i Jetpack Compose na Androida. Daje pełny dostęp do funkcji urządzenia, najlepszą wydajność i interfejs zgodny z konwencjami każdej platformy. Ceną jest podwójna praca warstwy mobilnej: każda funkcja jest implementowana i testowana dwa razy, a zespół potrzebuje specjalistów obu platform.

Aplikacja cross-platform powstaje z jednego kodu, z którego framework buduje wersje na iOS i Androida. Dwa dominujące frameworki to Flutter (język Dart, od Google) i React Native (JavaScript lub TypeScript, od Meta). Jeden zespół obsługuje obie platformy, a większość logiki i interfejsu jest wspólna. Funkcje wymagające głębokiego dostępu do urządzenia albo nietypowych bibliotek natywnych wciąż trzeba czasem pisać natywnie, przez tzw. moduły natywne. Charakterystykę obu frameworków dla decydentów opisują nasze artykuły o tym, czym jest Flutter, oraz encyklopedia React Native dla liderów IT.

PWA (progressive web app) to aplikacja webowa, która zachowuje się podobnie do aplikacji mobilnej: można ją dodać do ekranu głównego, działa częściowo bez sieci i może wysyłać powiadomienia. Nie trafia do App Store ani Google Play, więc nie płacisz opłat sklepowych i nie przechodzisz recenzji, ale też nie korzystasz z widoczności w sklepach. Na iPhone’ach ma istotne ograniczenia: powiadomienia web push działają od iOS 16.4 i tylko dla aplikacji dodanych do ekranu głównego, co potwierdza zespół WebKit. Część interfejsów urządzenia dostępnych dla aplikacji natywnych w przeglądarce Safari nie jest dostępna albo działa inaczej, więc każdą funkcję sprzętową, której potrzebujesz, trzeba sprawdzić osobno.

Ważna uwaga dla zarządu: wybór między tymi podejściami nie jest pytaniem technologicznym, tylko biznesowym. Odpowiedź zależy od tego, jak często użytkownicy będą otwierać aplikację, czy powiadomienia są kluczowe, czy obecność w sklepie ma znaczenie marketingowe i ile funkcji telefonu potrzebujesz.

Jak liczymy koszt aplikacji mobilnej?

Metoda jest ta sama, co w naszym artykule o tym, ile kosztuje aplikacja webowa w 2026 roku: koszt budowy to liczba osób × czas × stawka. Założenia:

• Stawki programistów mobilnych. Senior mobile developer w naszym cenniku to 1 600–2 240 zł netto za dzień, czyli 200–280 zł za godzinę. To nieco więcej niż senior backend lub frontend.
• Stawki pozostałych ról. Backend, QA, projekt interfejsu i zarządzanie projektem liczymy w przedziale seniora z naszego benchmarku: 1 440–2 080 zł za dzień (180–260 zł za godzinę). Projektanta UX nie ma w opublikowanym cenniku, więc dla niego przyjmujemy ten sam przedział jako założenie.
• Czas. 18 fakturowanych dni w miesiącu na pełny etat, po odliczeniu urlopów, świąt i chorób.
• Koszt osobomiesiąca. Mobile senior: 1 600 × 18 = 28 800 zł do 2 240 × 18 = 40 320 zł. Pozostałe role: 25 920–37 440 zł.
• Rezerwa. Osobno 15% na wymagania, które wyjaśnią się po pierwszych testach z użytkownikami.

Wyliczamy jeden produkt w trzech wariantach: aplikację dla członków sieci klubów z przykładu. Zakres: rejestracja i logowanie, profil, rezerwacja zajęć z listą oczekujących, płatność za karnet kartą, program punktowy, powiadomienia push, prosta historia aktywności oraz backend z panelem administracyjnym dla recepcji i integracją z istniejącym systemem rezerwacji. Dolna granica każdego przedziału to krótszy harmonogram przy dolnych stawkach, górna to dłuższy przy górnych.

Zespół z większym udziałem specjalistów mid zejdzie poniżej dolnej granicy. Nasz kalkulator kosztów MVP liczy w ten sposób dolny koniec przedziału. To nie jest cennik ARDURA, tylko metoda szacowania z jawnymi założeniami, które służą do czytania ofert.

Ile kosztuje aplikacja natywna na iOS i Androida?

Założenia zespołu. 6 pełnych etatów w ujęciu średnim: 1,5 etatu programisty iOS, 1,5 etatu programisty Androida, programista backendu, inżynier QA testujący obie platformy, projektant UX w połowie etatu, kierownik projektu w połowie etatu. Harmonogram: 5–6 miesięcy do publikacji w obu sklepach.

Arytmetyka. Warstwa mobilna to 3 etaty, pozostałe role to 3 etaty.

• Dolna granica: 5 miesięcy × (3 × 28 800 zł + 3 × 25 920 zł) = 5 × 164 160 zł = 820 800 zł
• Górna granica: 6 miesięcy × (3 × 40 320 zł + 3 × 37 440 zł) = 6 × 233 280 zł = 1 399 680 zł
• Z rezerwą 15%: ok. 944 tys. – 1,61 mln zł

Kiedy wariant natywny jest wart tej ceny: gdy aplikacja jest głównym produktem firmy, a nie dodatkowym kanałem; gdy intensywnie korzysta z funkcji urządzenia (aparat z przetwarzaniem obrazu, Bluetooth z urządzeniami zewnętrznymi, praca w tle, integracje z HealthKit lub Google Health Connect); gdy wydajność i płynność interfejsu są częścią przewagi konkurencyjnej; gdy nowe funkcje systemów Apple i Google, na przykład widżety czy integracje z asystentami, chcesz wdrażać zaraz po ich premierze.

Jest też koszt, który ujawnia się dopiero po premierze: każda nowa funkcja jest budowana dwa razy. Jeśli plan rozwoju produktu jest ambitny, różnica między natywnym a cross-platform w kosztach rozwoju będzie rosła z każdym rokiem.

Dochodzi koszt koordynacji, którego nie widać w arytmetyce stawek. Dwa zespoły platformowe muszą utrzymywać zgodność funkcji: ta sama reguła rezerwacji, te same komunikaty błędów, ten sam termin wydania. W praktyce jedna platforma prawie zawsze wyprzedza drugą, a ktoś musi pilnować, żeby użytkownicy iPhone’ów i Androida nie dostawali różnych wersji produktu. To zadanie kierownika projektu i QA, a jego czas jest wliczony w nasz skład zespołu tylko częściowo. Jeśli oferta na aplikację natywną nie przewiduje osoby odpowiedzialnej za spójność obu platform, zapytaj, kto będzie to robił. W aplikacjach, w których ta spójność ma znaczenie prawne lub finansowe, na przykład przy naliczaniu opłat albo zgodach marketingowych, rozjazd między platformami to nie problem estetyczny, tylko ryzyko reklamacji.

Ile kosztuje aplikacja w Flutterze lub React Native?

Założenia zespołu. 4,75 etatu w ujęciu średnim: 2 programistów Fluttera lub React Native, programista backendu, inżynier QA w 3/4 etatu, projektant UX w połowie etatu, kierownik projektu w połowie etatu. Harmonogram: 4–5 miesięcy.

Arytmetyka. Warstwa mobilna to 2 etaty, pozostałe role to 2,75 etatu.

• Dolna granica: 4 × (2 × 28 800 zł + 2,75 × 25 920 zł) = 4 × 128 880 zł = 515 520 zł
• Górna granica: 5 × (2 × 40 320 zł + 2,75 × 37 440 zł) = 5 × 183 600 zł = 918 000 zł
• Z rezerwą 15%: ok. 593 tys. – 1,06 mln zł

Wariant cross-platform kosztuje w tym wyliczeniu ok. jedną trzecią (34–37%) mniej niż natywny, a nie połowę. Powód jest widoczny w arytmetyce: backend, testy, projekt i zarządzanie pozostają, a testy wciąż trzeba wykonać na obu platformach i na wielu urządzeniach. Oszczędność dotyczy przede wszystkim warstwy mobilnej.

Flutter czy React Native? Z perspektywy kosztu różnice są mniejsze niż z perspektywy zespołu. React Native korzysta z JavaScriptu i TypeScriptu, więc łatwiej znaleźć ludzi i współdzielić wiedzę z zespołem webowym pracującym w React. Flutter daje bardzo spójny interfejs na obu platformach i własny silnik renderowania. Ważniejsze od wyboru frameworka jest to, czy dostawca ma w nim doświadczenie produkcyjne i czy Twój zespół będzie w stanie kod utrzymać, jeśli współpraca się skończy. Dostępność specjalistów i ich stawki w Polsce opisuje artykuł o stawkach mobile developerów w 2026 roku.

Kiedy cross-platform jest właściwym wyborem: gdy aplikacja ma być na obu platformach od pierwszego dnia, budżet jest ograniczony, a funkcje urządzenia ograniczają się do typowych (aparat, lokalizacja, powiadomienia, płatności, biometria). To opis większości aplikacji klienckich w handlu, usługach i programach lojalnościowych, łącznie z naszym przykładem sieci klubów.

Ile kosztuje PWA i czego nie zrobi na iPhonie?

Założenia zespołu. 3,75 etatu w ujęciu średnim: 1,5 etatu programisty frontendu, programista backendu, inżynier QA w połowie etatu, projektant UX w połowie etatu, kierownik projektu w 1/4 etatu. Harmonogram: 3–4 miesiące. Wszystkie role liczymy w przedziale 1 440–2 080 zł dziennie.

Arytmetyka. 3,75 etatu × 3 miesiące = 11,25 osobomiesiąca; × 4 miesiące = 15 osobomiesięcy.

• Dolna granica: 11,25 × 25 920 zł = 291 600 zł
• Górna granica: 15 × 37 440 zł = 561 600 zł
• Z rezerwą 15%: ok. 335–646 tys. zł

PWA kosztuje ok. 57–61% wariantu cross-platform i 35–40% natywnego. Dochodzi do tego zaleta, o której oferty rzadko mówią: aktualizacja PWA trafia do wszystkich użytkowników od razu, bez recenzji w sklepie i bez czekania, aż użytkownik zaktualizuje aplikację.

Czego PWA nie zrobi dobrze w przykładzie sieci klubów? Kluczową funkcją są powiadomienia o zwolnionych miejscach na zajęciach. Na Androidzie działają one w PWA bez większych problemów. Na iPhonie działają tylko wtedy, gdy użytkownik najpierw doda aplikację do ekranu głównego, a większość użytkowników tego nie robi bez wyraźnej zachęty. Jeśli znaczna część członków sieci korzysta z iPhone’ów, a powiadomienia są sercem wartości aplikacji, PWA będzie tańsza, ale gorzej spełni cel biznesowy.

PWA ma też mniej widoczny koszt: brak obecności w sklepach. Część klientów szuka aplikacji marki właśnie w App Store lub Google Play i nie znajdzie jej tam. Dla aplikacji używanej okazjonalnie, na przykład do sprawdzenia statusu zamówienia albo wypełnienia formularza, nie ma to znaczenia. Dla aplikacji, która ma budować codzienny nawyk, może mieć.

Jak wygląda porównanie trzech podejść do aplikacji mobilnej?

Tabela zbiera wyliczenia dla jednego produktu w trzech wariantach, razem z kryteriami wyboru. To narzędzie do rozmowy z dostawcami i zarządem, nie cennik.

Kryterium	PWA	Cross-platform (Flutter / React Native)	Natywna (Swift + Kotlin)
Zespół (etaty)	3,75	4,75	6
Czas do premiery	3–4 mies.	4–5 mies.	5–6 mies.
Koszt budowy netto (bez rezerwy)	292–562 tys. zł	516–918 tys. zł	821 tys. – 1,40 mln zł
Obecność w App Store i Google Play	Nie	Tak	Tak
Powiadomienia push na iPhonie	Tylko po dodaniu do ekranu głównego (iOS 16.4+)	Tak	Tak
Dostęp do funkcji urządzenia	Ograniczony, zależny od przeglądarki	Typowe funkcje tak, nietypowe przez moduły natywne	Pełny
Koszt kolejnych funkcji	Jedna implementacja	Jedna implementacja, czasem z dodatkami natywnymi	Dwie implementacje
Coroczne dostosowanie do iOS i Androida	Brak cyklu sklepowego, testy w przeglądarkach	Aktualizacja frameworka i obu platform	Osobno na każdej platformie
Kiedy wybrać	Użycie okazjonalne, push nieistotny, szybki test pomysłu	Aplikacja kliencka na obu platformach przy typowych funkcjach	Aplikacja jako główny produkt, intensywne użycie funkcji urządzenia

Założenia: senior mobile 1 600–2 240 zł/dzień, pozostałe role 1 440–2 080 zł/dzień, 18 fakturowanych dni w miesiącu. Do każdej kwoty dolicz rezerwę ok. 15% i koszty zewnętrzne.

Najważniejszy wniosek z tabeli: różnica między wariantami jest mniejsza, niż sugerowały oferty z przykładu, a każdy wariant ma przypadki, w których jest najlepszy. Oferta za 1,3 miliona za aplikację natywną mieści się w naszym przedziale, podobnie jak 700 tysięcy za Fluttera. Oferta za 350 tysięcy za PWA również. Żadna nie jest więc podejrzana cenowo. Wybór sprowadza się do pytania, czy powiadomienia na iPhone’ach i obecność w sklepach są warte różnicy kilkuset tysięcy złotych.

Ile kosztują sklepy z aplikacjami: konta deweloperskie i prowizje?

Same konta są tanie. Apple Developer Program kosztuje 99 USD rocznie dla firm i osób prywatnych. Rejestracja konta w Google Play Console to jednorazowe 25 USD. Konto Apple trzeba odnawiać, inaczej aplikacja znika ze sklepu, więc warto przypisać je do firmy, a nie do prywatnego konta programisty.

Większe znaczenie mają prowizje, ale tylko dla części aplikacji. Prowizje sklepów dotyczą sprzedaży treści i funkcji cyfrowych w aplikacji: subskrypcji premium, odblokowania funkcji, wirtualnych walut. Apple w ramach App Store Small Business Program pobiera 15% od deweloperów, których przychody nie przekraczają 1 mln USD rocznie. Google Play pobiera 15% od pierwszego miliona dolarów przychodu rocznie i 30% powyżej tego progu, a dla subskrypcji 15%; w EOG, Wielkiej Brytanii i kilku innych rynkach obowiązuje inna struktura opłat. Warunki zmieniają się co jakiś czas, więc przed zaprojektowaniem modelu przychodów sprawdź aktualne zasady dla swojego rynku.

Dla aplikacji z przykładu ważniejsza jest inna reguła. Według wytycznych App Store (punkt 3.1.3(e)) aplikacja, która sprzedaje towary fizyczne lub usługi wykorzystywane poza aplikacją, musi używać innych metod płatności niż zakupy w aplikacji, na przykład Apple Pay lub płatności kartą. Karnet na siłownię to usługa realizowana poza aplikacją, więc płatność przechodzi przez operatora płatności, a nie przez Apple. Płacisz wtedy prowizję operatora płatności, a nie sklepu. Ta różnica potrafi zmienić opłacalność całego modelu biznesowego, dlatego warto ją ustalić przed wyborem funkcji płatniczych.

Ile kosztuje utrzymanie aplikacji mobilnej po premierze?

To pozycja najczęściej pomijana w ofertach i najczęściej zaskakująca zarządy. Aplikacja webowa może działać latami z rzadkimi aktualizacjami. Aplikacja mobilna nie, bo platformy wymuszają aktualizacje w stałym rytmie.

Dwa przykłady z 2026 roku. Apple od 28 kwietnia 2026 roku wymaga, by aplikacje przesyłane do App Store Connect były budowane w Xcode 26 lub nowszym z SDK dla iOS 26, co wynika z listy nadchodzących wymagań Apple. Google od 31 sierpnia 2026 roku wymaga, by nowe aplikacje i aktualizacje w Google Play celowały w Androida 16 (API 36), a istniejące aplikacje, które nie celują co najmniej w Androida 15 (API 35), przestają być dostępne dla nowych użytkowników na nowszych wersjach systemu. To nie jest jednorazowa zmiana. Oba wymagania przesuwają się co roku, a każda nowa wersja systemu zmienia zachowanie uprawnień, pracy w tle albo powiadomień.

Ile to kosztuje? Nie ma publicznego źródła, które by to mierzyło, więc podajemy nasz szacunek z czynnikami. Samo coroczne dostosowanie do nowej wersji systemu, czyli aktualizacja SDK i zależności, testy na nowej wersji i poprawki zmian w zachowaniu, to orientacyjnie 10–20 osobodni na platformę rocznie w aplikacji o typowych funkcjach. Dla aplikacji natywnej na dwie platformy daje to 20–40 osobodni, czyli ok. 32–90 tys. zł przy stawkach mobile seniora. Dla aplikacji cross-platform szacujemy 15–30 osobodni, bo do pracy na obu platformach dochodzi aktualizacja samego frameworka. PWA nie ma cyklu sklepowego, ale wymaga testów na nowych wersjach przeglądarek. Szacunek rośnie z liczbą funkcji urządzenia, liczbą bibliotek zewnętrznych i liczbą obsługiwanych wersji systemu.

To tylko część utrzymania. Dochodzą poprawki błędów, monitoring awarii, drobny rozwój i utrzymanie backendu. Jako punkt wyjścia budżetu przyjmij 15–20% kosztu budowy rocznie i skoryguj go po pierwszym roku na podstawie faktycznych zgłoszeń. Modele utrzymania i poziomy wsparcia opisuje nasz artykuł o utrzymaniu oprogramowania po wdrożeniu.

Co to oznacza w perspektywie trzech lat? Policzmy koszt budowy plus dwa lata utrzymania, przyjmując 15% kosztu budowy rocznie w wariancie dolnym i 20% w górnym (bez rezerwy i kosztów zewnętrznych):

• Natywna: budowa 820 800 – 1 399 680 zł plus utrzymanie 246 240 – 559 872 zł, razem ok. 1,07–1,96 mln zł.
• Cross-platform: budowa 515 520 – 918 000 zł plus utrzymanie 154 656 – 367 200 zł, razem ok. 670 tys. – 1,29 mln zł.
• PWA: budowa 291 600 – 561 600 zł plus utrzymanie 87 480 – 224 640 zł, razem ok. 379–786 tys. zł.

To wyliczenie jest ostrożne wobec wariantu natywnego, bo zakłada ten sam procent utrzymania dla wszystkich wariantów. W praktyce rozwój aplikacji natywnej jest droższy, bo każda nowa funkcja powstaje dwa razy, a cykl aktualizacji systemów obsługuje się osobno na każdej platformie. Jeśli Twój plan rozwoju przewiduje kilka większych funkcji rocznie, różnica w trzyletnim koszcie między natywną a cross-platform będzie większa niż w samej budowie. Zarząd powinien zobaczyć tę liczbę obok kosztu budowy, a nie dopiero w drugim roku.

Który wariant aplikacji mobilnej wybrać dla Twojego produktu?

Zamiast zaczynać od technologii, odpowiedz na pięć pytań biznesowych. Odpowiedzi zwykle wskazują wariant jednoznacznie.

1. Jak często użytkownik otworzy aplikację? Codziennie lub kilka razy w tygodniu przemawia za aplikacją ze sklepu. Kilka razy w roku przemawia za PWA albo po prostu dobrą stroną mobilną.
2. Czy powiadomienia push są sercem wartości? Jeśli tak, a znaczna część użytkowników ma iPhone’y, PWA odpada. Udział iOS i Androida wśród Twoich klientów sprawdzisz w analityce strony; o różnicach między użytkownikami obu platform pisaliśmy w artykule o strategii iOS vs Android.
3. Jakich funkcji urządzenia potrzebujesz? Aparat, lokalizacja, biometria i płatności to standard dla cross-platform. Bluetooth z urządzeniami zewnętrznymi, intensywna praca w tle czy przetwarzanie obrazu w czasie rzeczywistym przemawiają za natywną.
4. Czy aplikacja jest produktem, czy kanałem? Jeśli firma zarabia na aplikacji i konkuruje jakością doświadczenia, inwestycja w natywną może się zwrócić. Jeśli aplikacja jest dodatkowym kanałem obsługi, cross-platform zwykle wystarczy.
5. Kto będzie utrzymywał kod za trzy lata? Jeśli masz zespół webowy w React, React Native obniży koszt utrzymania. Jeśli planujesz przejęcie kodu przez własny zespół, wybierz technologię, w której łatwo zatrudnić.

Zanim w ogóle wybierzesz wariant, warto zadać pytanie zerowe: czy potrzebujesz aplikacji, czy dobrej strony mobilnej? Jeśli Twoja strona nie działa dobrze na telefonie, a klienci i tak trafiają na nią z wyszukiwarki, poprawa wersji mobilnej strony może przynieść więcej niż aplikacja, której nikt nie zainstaluje. Aplikacja ma sens, gdy daje użytkownikowi coś, czego strona dać nie może: powiadomienia, szybki dostęp z ekranu głównego, pracę bez sieci, funkcje telefonu. Jeśli na żadne z tych pytań nie odpowiadasz „tak”, najtańsza aplikacja wciąż jest droższa od dobrej strony.

Jest też wariant pośredni, często najrozsądniejszy na start: PWA lub prosta aplikacja cross-platform jako pierwszy krok, z pomiarem, ilu użytkowników z niej korzysta i jak często. Decyzja o droższym wariancie zapada wtedy na podstawie danych, a nie przekonań agencji.

O co zapytać dostawcę aplikacji mobilnej przed podpisaniem umowy?

Poza pytaniami wspólnymi dla każdego projektu (skład zespołu, osobomiesiące, stawki, własność kodu) aplikacje mobilne mają własną listę.

• Na jakich urządzeniach i wersjach systemu testujecie? Poproś o listę: modele, wersje iOS i Androida, rozdzielczości. Zakres testów mobilnych opisuje hasło testowanie mobilne w naszym słowniku.
• Czyje są konta w sklepach? Konta deweloperskie powinny należeć do Twojej firmy od pierwszego dnia. Aplikacja opublikowana z konta dostawcy to problem przy zmianie dostawcy.
• Kto przygotowuje publikację i przechodzi recenzję? Opisy, zrzuty ekranu, deklaracje prywatności, odpowiedzi na odrzucenia przez recenzentów. To kilka dni pracy przy każdej premierze.
• Jak wygląda coroczna aktualizacja do nowych wersji iOS i Androida i ile kosztuje? Jeśli dostawca nie umie odpowiedzieć, nie planował tego kosztu.
• Które funkcje wymagają kodu natywnego w wariancie cross-platform? Lista z szacunkiem dni. Brak takiej listy przy aplikacji z nietypowymi funkcjami to sygnał ostrzegawczy.
• Jak wygląda monitoring awarii po premierze? Narzędzie, kto reaguje i w jakim czasie.
• Jak rozliczane są płatności w aplikacji? Czy produkt podlega zasadom zakupów w aplikacji, czy płatnościom zewnętrznym, i jak to wpływa na marżę.

Sygnały ostrzegawcze: wycena bez backendu („zakładamy, że API już macie”), brak QA na urządzeniach fizycznych, konto w sklepie na dostawcę, brak słowa o utrzymaniu oraz obietnica, że cross-platform „kosztuje połowę natywnej”. Arytmetyka z tego artykułu pokazuje, dlaczego to ostatnie zdanie zwykle nie jest prawdą.

Jak obniżyć koszt aplikacji mobilnej bez utraty jakości?

Największe oszczędności daje dyscyplina zakresu pierwszej wersji. Aplikacja z przykładu nie musi mieć na start programu punktowego ani historii aktywności. Rezerwacja, płatność i powiadomienie o zwolnionym miejscu to rdzeń wartości. Reszta może przyjść w drugiej wersji, gdy dane pokażą, jak członkowie korzystają z aplikacji. Wycięcie dwóch modułów skraca harmonogram o kilka tygodni.

Druga dźwignia to wykorzystanie istniejącego backendu. Jeśli sieć ma system rezerwacji z API, aplikacja może z niego korzystać, zamiast duplikować logikę. Wtedy budujesz głównie warstwę mobilną, a koszt backendu spada.

Trzecia to gotowe usługi zamiast własnych: logowanie, powiadomienia, płatności, analityka i raportowanie awarii mają dojrzałe usługi zewnętrzne, które kosztują mniej niż budowa i utrzymanie własnych.

Czwarta to zaplanowanie testów na urządzeniach z głową: zamiast testować na wszystkim, ustal listę urządzeń i wersji systemu na podstawie danych o Twoich użytkownikach. Jeśli potrzebujesz wsparcia w tym obszarze, nasz zespół testowania oprogramowania obejmuje także testy aplikacji mobilnych.

Czego nie ciąć: testów na fizycznych urządzeniach obu platform, monitoringu awarii i budżetu na coroczne aktualizacje. Aplikacja, która zawiesza się na popularnym modelu telefonu albo znika ze sklepu po zmianie wymagań, kosztuje więcej niż te oszczędności.

Od czego zacząć, żeby dostać wiarygodną wycenę aplikacji mobilnej?

Najpierw szybki punkt odniesienia. Nasz kalkulator kosztów MVP pozwala wybrać aplikację mobilną, platformy i kluczowe funkcje i w kilka sekund pokazuje orientacyjny przedział kosztu, czas i skład zespołu. Fazy budżetu pierwszej wersji produktu opisuje przewodnik o tym, jak zaplanować koszt budowy MVP.

Potem spisz odpowiedzi na pięć pytań z sekcji o wyborze wariantu, listę systemów, z którymi aplikacja ma się łączyć, i model przychodów. To wystarczy, żeby dostawcy wyceniali to samo.

Na końcu discovery. W ARDURA Consulting trwa 1–2 tygodnie i kończy się rekomendacją wariantu (natywny, cross-platform lub PWA) z uzasadnieniem, zakresem pierwszej wersji i wyceną z jawną arytmetyką: rolami, czasem, stawkami z naszego cennika i budżetem utrzymania na pierwszy rok. Nasz zespół software development buduje aplikacje natywne na iOS i Androida oraz w React Native i Flutterze, więc rekomendacja nie jest z góry przesądzona przez jedną technologię. Opisz swój produkt, a wrócimy z konkretną propozycją.