Wycena aplikacji mobilnej — dlaczego „od 30 tys." nic nie znaczy i o co pytać

„Aplikacje mobilne już od 30 000 zł". Widzisz to na stronach software house'ów, w reklamach i w mailach od handlowców. Liczba jest konkretna, brzmi wiarygodnie i natychmiast staje się punktem odniesienia dla całej dalszej rozmowy. Problem w tym, że nie niesie żadnej informacji o Twoim projekcie — a bardzo skutecznie zaburza ocenę wszystkich ofert, które przeczytasz później.

Ten artykuł nie jest o tym, ile kosztuje aplikacja (to opisaliśmy osobno w tekście Ile kosztuje aplikacja mobilna w 2026). Jest o procesie wyceny: jak czytać ofertę, o co dopytać, zanim podpiszesz umowę, i jak porównać dwie propozycje różniące się trzykrotnie.

Dlaczego „od X tysięcy" jest komunikatem marketingowym, nie wyceną

1. To kotwica cenowa, a nie prognoza

Kotwiczenie to najlepiej udokumentowany efekt w psychologii negocjacji: pierwsza usłyszana liczba zmienia ocenę każdej kolejnej. Jeśli zaczniesz od „30 tys.", oferta na 180 tys. zabrzmi jak zdzierstwo — nawet jeśli opisuje sześciokrotnie większy zakres i jest jedyną uczciwą propozycją na stole.

Zwróć uwagę na konstrukcję: „od" nie zobowiązuje do niczego. Wystarczy, że raz w historii firmy powstał projekt za tę kwotę — albo że da się taki teoretycznie policzyć.

2. Nie wiadomo, co obejmuje słowo „aplikacja"

Za tą samą kwotą mogą kryć się skrajnie różne rzeczy:

• aplikacja na jedną platformę albo na obie,
• z gotowym backendem po stronie klienta albo z backendem i API do zbudowania od zera,
• z projektem UI albo na szablonie,
• z testami i wdrożeniem do App Store i Google Play albo z paczką „reszta po Twojej stronie",
• z gwarancją i utrzymaniem albo z zerowym wsparciem po odbiorze.

Różnica między skrajnościami to nie kilkanaście procent, tylko wielokrotność.

3. Najniższa cena zwykle opisuje projekt, którego nie masz

Kwoty „od" pochodzą z najprostszego możliwego przypadku: jedna platforma, kilka ekranów, brak integracji, brak logowania, brak płatności, brak zaplecza administracyjnego. Realny produkt biznesowy prawie zawsze ma logowanie, panel administracyjny, powiadomienia i przynajmniej jedną integrację — a każdy z tych elementów to osobna pozycja w budżecie.

4. Ukrywa to, co decyduje o koszcie: wymagania niefunkcjonalne

Dwie aplikacje z identyczną listą ekranów mogą różnić się kosztem dwukrotnie ze względu na rzeczy, których nie widać na makiecie: tryb offline, synchronizację danych między urządzeniami, wymagania bezpieczeństwa i zgodności, dostępność wg WCAG, wydajność przy dużych zbiorach danych, obsługę starszych urządzeń. To zwykle 20–40% budżetu i najczęstsze źródło różnic między ofertami.

Co naprawdę tworzy koszt

Zanim przejdziemy do pytań, warto ustalić, na co właściwie patrzysz w ofercie. Koszt aplikacji to iloczyn czterech zmiennych:

Technologia — Flutter, React Native, Kotlin Multiplatform czy natywnie — wpływa na koszt znacznie mniej, niż sugerują dyskusje na jej temat. Rozbieramy to w tekście Flutter vs React Native vs Kotlin Multiplatform. Jeśli wykonawca tłumaczy dużą różnicę w cenie „bo my robimy w X" — to zwykle nie jest prawdziwy powód różnicy.

Anatomia uczciwej wyceny

Dobra wycena wygląda nudno: to tabela, nie jedna liczba. Powinna zawierać:

1. Rozbicie na moduły lub funkcje z osobną estymacją każdego. Bez tego nie da się niczego przyciąć — a przycinanie zakresu to jedyna realna dźwignia budżetowa.
2. Widełki, nie punkt. Estymacja „140 tys." jest mniej wiarygodna niż „130–170 tys.". Punktowa liczba przy projekcie, którego nikt jeszcze nie zaprojektował, oznacza, że ktoś albo doliczył duży bufor, albo nie policzył ryzyka.
3. Jawne założenia. Czego wykonawca nie widział, co zakłada po Twojej stronie, co uznaje za dostarczone (treści, dostępy do API, konta deweloperskie).
4. Listę wykluczeń. Co nie jest w cenie — to często ważniejsze niż to, co jest.
5. Podział na etapy z kamieniami milowymi i przypisanym do nich budżetem.
6. Koszty poza projektem: konta deweloperskie (Apple 99 USD/rok, Google jednorazowo 25 USD), hosting, usługi zewnętrzne, licencje.
7. Model utrzymania po wdrożeniu — orientacyjny koszt roczny.

Jeśli dostajesz PDF z jedną liczbą i akapitem opisu, nie masz wyceny. Masz ofertę handlową.

Dwanaście pytań, które warto zadać przed podpisaniem

To lista, którą sami stosujemy — również wtedy, gdy klient przychodzi do nas z ofertą konkurencji i prosi o jej ocenę.

O zakres

1. Co dokładnie obejmuje ta kwota — proszę o rozbicie na funkcje. Odpowiedź „całość projektu" to sygnał ostrzegawczy. Chcesz zobaczyć pozycje: logowanie, panel administracyjny, powiadomienia push, integracja X.

2. Czego w tej cenie nie ma? Najlepsze pojedyncze pytanie w całej rozmowie. Typowe pominięcia: backend, panel administracyjny, projekt graficzny, testy na urządzeniach fizycznych, wdrożenie do sklepów, teksty, tłumaczenia, migracja danych.

3. Czy backend jest w zakresie, czy zakładacie, że dostarczę API? Zaskakująco częsta luka. Jeśli nie masz gotowego API, a oferta go nie obejmuje, brakuje w budżecie zwykle 30–50% kwoty.

4. Kto odpowiada za wdrożenie do App Store i Google Play? Publikacja to nie jest „wrzucenie pliku". To konta deweloperskie, polityka prywatności, formularze o zbieranych danych, opisy, materiały graficzne i realna szansa na odrzucenie przez recenzenta. Zaplanuj na to czas i budżet.

O sposób pracy

5. Jak wycenialiście ten projekt — na podstawie czego? Chcesz usłyszeć, że ktoś rozłożył zakres na zadania i je oszacował. Odpowiedź „z doświadczenia, robiliśmy podobne" oznacza estymację przez analogię — bywa trafna, ale nie da się jej zweryfikować ani przyciąć.

6. Co się stanie, gdy zakres się zmieni? Zmieni się na pewno. Pytaj o konkretny proces: kto wycenia zmianę, w jakim czasie, czy jest bufor w budżecie, jak zmiana wpływa na termin.

7. Kto realnie będzie pisał kod i jakie ma doświadczenie? W ofercie widzisz seniorów, w projekcie bywają stażyści. Poproś o skład zespołu z rolami i wymiarem zaangażowania. Zapytaj wprost, czy prace są podzlecane.

8. Jak często zobaczę działającą wersję? Odpowiedź powinna brzmieć: co dwa tygodnie, na Twoim telefonie. Nie zrzuty ekranu, nie demo na koniec projektu.

O to, co po wdrożeniu

9. Czyją własnością jest kod i gdzie jest repozytorium? Umowa musi przenosić autorskie prawa majątkowe na Ciebie, a repozytorium powinno być dostępne od pierwszego dnia — najlepiej w Twojej organizacji na GitHubie czy GitLabie. Brak dostępu do kodu w trakcie projektu to poważne ryzyko.

10. Co obejmuje gwarancja i jak długo trwa? Rozróżnij naprawę błędów (powinna być bezpłatna, zwykle 3–12 miesięcy) od rozwoju (płatny). Ustalcie, co liczy się jako błąd, a co jako nowa funkcja.

11. Ile kosztuje utrzymanie przez rok? Aplikacja to zobowiązanie ciągłe: aktualizacje systemów iOS i Android, zmiany wymagań sklepów, biblioteki, poprawki. Realistycznie 15–20% budżetu projektu rocznie. Oferta, która milczy na ten temat, ukrywa część kosztu.

12. Co się stanie, jeśli będziemy chcieli zmienić wykonawcę? Pytanie niewygodne i właśnie dlatego wartościowe. Dobry partner odpowie o dokumentacji, standardach kodu i procesie przekazania. Zła odpowiedź to zwykle początek uzależnienia od dostawcy.

Czerwone flagi w ofertach

• Wycena tego samego dnia, bez pytań. Rzetelna estymacja wymaga zrozumienia zakresu. Jeśli nikt o nic nie zapytał, wyceniono wyobrażenie, nie Twój projekt.
• Cena znacząco poniżej rynku. Zwykle oznacza pominięty zakres, który wróci jako change requesty — często drożej niż w ofercie wyższej na starcie.
• Brak podziału na etapy. Płatność „50% z góry, 50% na koniec" przy projekcie na kilka miesięcy przenosi całe ryzyko na Ciebie.
• Termin bez marginesu. „Trzy miesiące" bez wskazania, co jest zależne od Twoich decyzji i dostaw, to termin, który nie przetrwa zderzenia z rzeczywistością.
• Opór przed pokazaniem kodu lub repozytorium.
• „Zrobimy to w AI, więc będzie taniej." Narzędzia AI realnie przyspieszają pracę, ale kod trzeba przeczytać, przetestować i utrzymać. Co znajdujemy w takich projektach, opisujemy w tekście Kod pisany przez AI w produkcji.
• Brak pytań o wymagania niefunkcjonalne. Nikt nie zapytał o offline, bezpieczeństwo, liczbę użytkowników i integracje? Te tematy wrócą — z fakturą.

Jak porównać dwie oferty różniące się trzykrotnie

To najczęstsza sytuacja: 60 tys. i 190 tys. za „to samo". Prawie nigdy nie chodzi o marżę.

Krok 1. Sprowadź obie do wspólnej listy funkcji. Zrób arkusz: wiersze to funkcje, kolumny to oferty. Zwykle po pół godzinie widać, że tańsza oferta nie obejmuje backendu, panelu administracyjnego albo drugiej platformy.

Krok 2. Sprawdź, kto zadał więcej pytań. Liczba i jakość pytań przed wyceną to najlepszy dostępny wskaźnik tego, jak dokładnie policzono zakres.

Krok 3. Policz koszt całkowity w perspektywie dwóch lat. Dodaj utrzymanie, poprawki, hosting i usługi zewnętrzne. Tańsza oferta z niższą jakością kodu potrafi wyprzedzić droższą w drugim roku.

Krok 4. Zapytaj obie strony o to samo pytanie techniczne. Na przykład: „jak zrealizujecie synchronizację danych, gdy użytkownik pracował dwie godziny bez internetu?". Odpowiedzi bardzo szybko różnicują wykonawców.

Krok 5. Poproś o referencje z projektu o podobnej złożoności — i zadzwoń. Pytaj nie o to, czy było dobrze, tylko: co poszło nie tak i jak wykonawca to rozwiązał.

Jeśli decyzja jest duża, a Ty nie masz w zespole nikogo technicznego, rozważ niezależną ocenę oferty. Audyt i konsultacja przed podpisaniem umowy kosztuje ułamek projektu i zwykle jest najlepiej wydaną godziną w całym przedsięwzięciu.

Co zrobić, żeby w ogóle dostać sensowną wycenę

Jakość wyceny zależy od jakości briefu. Przed wysłaniem zapytania przygotuj:

• Problem i użytkownika — jedno zdanie: kto i po co ma używać aplikacji.
• Listę głównych ścieżek — 3–7 rzeczy, które użytkownik ma móc zrobić.
• Platformy — iOS, Android, obie? Jest szansa, że wystarczy aplikacja webowa lub PWA.
• Stan zaplecza — masz backend, API, bazę danych, panel administracyjny? Cokolwiek działającego?
• Integracje — z jakimi systemami aplikacja musi się połączyć, czy mają dokumentację API.
• Wymagania niefunkcjonalne — offline, RODO, dostępność, przewidywana liczba użytkowników.
• Budżet i termin — realne widełki. Podanie budżetu nie oznacza, że „zapłacisz maksymalną kwotę"; oznacza, że dostaniesz propozycję zakresu dopasowaną do tych ram, zamiast oferty niedopasowanej w obie strony.

Nie musisz mieć specyfikacji ani makiet. Musisz mieć jasność co do problemu — resztę dobry wykonawca pomoże doprecyzować, a jeśli tego nie robi, to też jest informacja.

Podsumowanie

„Od 30 tys." nie mówi nic o Twoim projekcie — mówi o strategii sprzedażowej firmy, która to opublikowała. Wartościowa jest dopiero wycena rozbita na funkcje, z podanymi założeniami, wykluczeniami, etapami i kosztem utrzymania.

Trzy rzeczy, które warto zapamiętać:

1. Zawsze pytaj, czego w cenie nie ma. To pojedyncze pytanie ujawnia więcej niż cała reszta rozmowy.
2. Porównuj zakresy, nie liczby. Różnica 3× prawie zawsze siedzi w backendzie, drugiej platformie albo wymaganiach niefunkcjonalnych.
3. Licz koszt dwuletni, nie cenę wdrożenia. Utrzymanie to realnie 15–20% budżetu rocznie i jest nieuniknione.

W Mobilesoft wyceniamy z rozbiciem na etapy i funkcje — razem z listą tego, co świadomie zostawiamy poza zakresem pierwszej wersji. Zobacz, jak podchodzimy do budowy aplikacji mobilnych, sprawdź nasze realizacje albo od razu wyceń swój projekt. Jeśli chcesz najpierw zrozumieć widełki rynkowe, zacznij od tekstów Ile kosztuje aplikacja mobilna w 2026 i Ile kosztuje MVP aplikacji mobilnej. A jeśli masz na biurku ofertę, której nie umiesz ocenić — napisz do nas, przejdziemy przez nią razem.