Żeby rzetelnie czytać wycenę aplikacji, sprawdź w niej 9 pozycji: analizę, projekt UX/UI, aplikację, backend i panel, integracje, testy, wdrożenie, zarządzanie projektem oraz gwarancję z kosztami po wdrożeniu. Tam chowają się koszty, które wychodzą dopiero po podpisaniu umowy. Każda godzina różnicy w jednej pozycji mnoży się przez stawkę, więc rozbieżność rzędu 100 godzin wyraźnie zmienia budżet. Niżej: co sprawdzić, 12 pytań do wykonawcy i porównanie ofert krok po kroku.
Według tych samych zasad możesz czytać wycenę aplikacji mobilnej, webowej albo systemu na zamówienie. Jeśli dopiero szukasz wykonawcy, zacznij od tekstu o tym, jak wybrać software house.
Jakie 9 pozycji musi zawierać wycena aplikacji?
Rzetelna wycena rozbija projekt na etapy i opisuje rezultat każdego z nich. Jeśli któraś z pozycji poniżej nie występuje w ofercie, zapytaj, czy jest ukryta w innej, czy po prostu jej nie ma.
| Pozycja | Co powinna obejmować | Co sprawdzić | Sygnał ostrzegawczy |
|---|---|---|---|
| 1. Analiza i specyfikacja | Warsztaty, lista funkcji, makiety, kryteria odbioru | Czy wynik analizy należy do Ciebie | „Analiza w cenie” bez opisu rezultatu |
| 2. Projekt UX/UI | Ścieżki użytkownika, projekt wszystkich ekranów, rundy poprawek | Liczbę ekranów i iteracji, stany błędów i puste widoki | „Projekt graficzny” bez liczby ekranów |
| 3. Aplikacja | Ekrany i logika na wskazanych platformach | Platformy (iOS, Android, web) i minimalne wersje systemów | Jedna kwota za „aplikację” bez podziału na moduły |
| 4. Backend i panel administracyjny | API, baza danych, panel do zarządzania treścią i użytkownikami | Kto i gdzie wprowadza dane, jakie role ma panel | Brak panelu w ofercie |
| 5. Integracje | ERP, CRM, płatności, kurierzy, logowanie | Założenia o API po drugiej stronie i kto płaci za dostęp | „Integracja z systemem X” jednym zdaniem |
| 6. Testy | Testy funkcjonalne, na urządzeniach, automatyczne, bezpieczeństwa | Liczbę godzin, listę urządzeń, zakres testów bezpieczeństwa | Testy „w cenie” bez godzin |
| 7. Wdrożenie i publikacja | Serwery, publikacja w sklepach, migracja danych | Na czyich kontach i kto odpowiada za review w sklepach | Brak migracji przy zastępowaniu starego systemu |
| 8. Zarządzanie projektem | Planowanie, spotkania, raporty, kontakt z Tobą | Liczbę godzin, częstotliwość raportów, osobę kontaktową | Procent doliczany bez limitu albo brak pozycji |
| 9. Gwarancja i koszty po wdrożeniu | Okres gwarancji, hosting, licencje, konta w sklepach | Definicję błędu, datę startu płatności za serwery | Oferta kończy się na dniu wdrożenia |
Koszty po wdrożeniu, o których łatwo zapomnieć
Pozycja dziewiąta jest najczęściej pomijana, bo nie dotyczy budowy. Tymczasem konto Apple Developer Program jest płatne co roku, a konto Google Play jednorazowo. Także hosting i utrzymanie to wydatek, który wraca co roku.
Czym różni się orientacyjna wycena aplikacji od wiążącej?
Zanim zaczniesz czytać wycenę aplikacji, sprawdź, czy jest orientacyjna, czy wiążąca. Wycena orientacyjna to przedział cenowy na podstawie krótkiego opisu. Służy do decyzji, czy projekt mieści się w budżecie. Nie nadaje się do podpisania umowy, bo nie ma w niej zakresu.
Wycena wiążąca powstaje natomiast po analizie: lista funkcji, makiety, założenia o integracjach. Dopiero ją porównujesz pozycja po pozycji. Jeśli wykonawca podaje jedną kwotę po pierwszej rozmowie, to nadal jest wycena orientacyjna, niezależnie od nazwy dokumentu.
Dlaczego widełki się zawężają
Każda decyzja podjęta w analizie usuwa ryzyko z wyceny. Czy integracja z ERP ma działać w obie strony? Czy aplikacja musi pracować offline? Panel ma mieć trzy role czy dziesięć? Dobra wycena wiążąca ma więc węższe widełki niż orientacyjna - albo jedną kwotę z listą założeń.
W których pozycjach wycena aplikacji najczęściej ukrywa koszty?
Kiedy będziesz czytać wycenę aplikacji, zwróć uwagę na pięć miejsc, w których oferta wygląda dobrze, a projekt kończy się aneksem.
Integracje opisane jednym zdaniem
Integracja, która w ofercie ma 16 godzin, a po drugiej stronie nie ma dokumentacji API, potrafi zająć znacznie więcej. W raporcie Postman State of the API 2024 (ponad 5600 badanych) 39% programistów wskazuje niespójną dokumentację jako największą przeszkodę, a problemy z dokumentacją opóźniają integracje. Zapytaj, jakie dane płyną w którą stronę i co się dzieje, gdy tamten system nie odpowiada.
Testy i poprawki bez godzin
„Testy w cenie” bez liczby godzin zwykle oznaczają, że testuje programista, który napisał kod. Poproś o listę urządzeń, zakres testów automatycznych i informację, czy aplikacja przechodzi testy bezpieczeństwa według uznanego standardu, na przykład OWASP MASVS dla aplikacji mobilnych.
Zarządzanie projektem liczone procentem
Zarządzanie projektem to stała część pracy zespołu, która rośnie razem z wielkością projektu. Problem zaczyna się, gdy jest doliczane procentowo do każdej zmiany bez limitu albo gdy nie ma go wcale - wtedy harmonogramu pilnujesz Ty.
Stawka zamiast liczby godzin
Porównuj godziny, nie tylko stawki. Oferta z niższą stawką i 800 godzinami pracy może w sumie kosztować więcej niż oferta z wyższą stawką i 550 godzinami. Niższa stawka z większą liczbą godzin często oznacza mniej doświadczony zespół.
Założenia i wyłączenia, których nie ma na piśmie
Każda wycena stoi na założeniach: że API klienta działa, że treści dostarczy zamawiający, że aplikacja obsługuje jeden język. Jeśli założeń i listy wyłączeń nie ma w ofercie, zmienią się w aneksy. Dlatego poproś o nie wprost - to jedno zdanie w mailu.
Czy najtańsza wycena aplikacji naprawdę jest najtańsza?
Nie zawsze, bo często jest tańsza o pozycje, których w niej nie ma. Poniżej przykład modelowy: dwie oferty na tę samą aplikację mobilną z panelem. Przykład jest ilustracyjny i nie pochodzi z oferty konkretnej firmy.
| Pozycja | Oferta A | Oferta B |
|---|---|---|
| Analiza i projekt UX/UI | niski | średni |
| Aplikacja na iOS i Android | wysoki | wysoki |
| Backend i panel administracyjny | brak w ofercie | średni |
| Testy, publikacja, zarządzanie projektem | „w cenie” | niski |
| Razem w ofercie | wyraźnie mniej niż B | więcej niż A |
| Po doliczeniu brakujących pozycji | tyle co B albo więcej | bez zmian |
Oferta A jest tańsza tylko na papierze - widać to, gdy zaczniesz czytać wycenę aplikacji pozycja po pozycji. Najwięcej trzeba dołożyć za brakujący panel, mniej za analizę robioną w trakcie projektu, a najmniej za testy i publikację.
W efekcie po uzupełnieniu obie oferty kosztują podobnie. Różnica polega na tym, że w ofercie A dopłaty przychodzą aneksami, gdy projekt już trwa i trudno zmienić wykonawcę.
Pięć cech rzetelnej wyceny
- Rozbicie na etapy i pozycje z opisem rezultatu każdej z nich.
- Lista założeń i lista rzeczy, których w projekcie nie ma.
- Szacunek godzin albo przynajmniej udział każdej pozycji w kwocie.
- Harmonogram płatności powiązany z odbiorami etapów.
- Koszt utrzymania po wdrożeniu i koszty zewnętrzne: hosting, licencje, konta w sklepach.
Jak czytać wycenę aplikacji i porównać oferty krok po kroku?
Porównanie dwóch lub trzech ofert zajmuje popołudnie. Wykonaj te kroki w tej kolejności, zanim spojrzysz na sumy.
- Sprowadź oferty do wspólnych 9 pozycji: przepisz każdą ofertę do tabeli z pozycjami z tego tekstu. Puste pola zaznacz potem na czerwono.
- Wypisz założenia i wyłączenia: dla każdej oferty osobno - co wykonawca zakłada o integracjach, treściach, liczbie języków i platform.
- Porównaj godziny w każdej pozycji: duża różnica w jednej pozycji oznacza inne rozumienie zakresu. Dlatego zapytaj obu wykonawców, skąd się bierze.
- Uwzględnij model rozliczenia: kwota ryczałtowa zawiera bufor na ryzyko, natomiast rozliczenie godzinowe przenosi ryzyko na Ciebie. Porównanie modeli znajdziesz w tekście o umowie z software housem.
- Dolicz koszty po wdrożeniu: utrzymanie, hosting i licencje przez co najmniej trzy lata. Z czego się składają, opisaliśmy w tekście o tym, ile kosztuje utrzymanie aplikacji.
- Sprawdź, co dostajesz na własność: prawa autorskie, kod źródłowy, repozytorium i konta w sklepach. Prawa majątkowe przechodzą tylko na polach eksploatacji wymienionych w umowie (art. 41 ust. 2 ustawy o prawie autorskim).
- Zadaj każdemu wykonawcy te same 12 pytań: lista jest w następnej sekcji. Porównuj konkretność odpowiedzi, nie ich długość.
- Porównaj harmonogramy płatności: płatność z góry za cały projekt to ryzyko; płatności za odebrane etapy chronią obie strony.
- Policz koszt całkowity w trzech latach: budowa plus utrzymanie plus Twój czas. Jak liczyć taki koszt, pokazaliśmy na przykładzie w tekście system dedykowany czy SaaS.
Opisz aplikację w 3 zdaniach - odsyłamy przedział cenowy w 24 h w dni robocze. Jeśli masz już ofertę innej firmy, możesz ją dołączyć - pokażemy, których pozycji w niej brakuje. wypełnij formularz, napisz na biuro@appcreo.pl albo zadzwoń: +48 783 477 243.
Jakie 12 pytań o wycenę aplikacji zadać wykonawcy przed podpisem?
Dobra odpowiedź jest konkretna i na piśmie. Odpowiedź „to się ustali w trakcie” przy pytaniach 1, 2 i 12 to sygnał ostrzegawczy.
Zakres
- Które funkcje są w wycenie, a które poza nią - czy mogę dostać listę wyłączeń?
- Na jakich założeniach opiera się wycena integracji i co się stanie, jeśli okażą się nieprawdziwe?
- Ile ekranów i ile rund poprawek obejmuje projekt interfejsu?
- Na jakich urządzeniach i wersjach systemów aplikacja będzie testowana?
Zespół i proces
- Kto konkretnie będzie pracował nad projektem i czy są podwykonawcy?
- Jak często zobaczę działającą wersję i jak wygląda odbiór etapu?
- Jak wyceniacie zmiany zakresu i ile trwa przygotowanie takiej wyceny?
- Kto jest moim kontaktem i ile godzin zarządzania projektem jest w ofercie?
Pieniądze i prawa
- Jaki jest harmonogram płatności i czy jest powiązany z odbiorami?
- Co obejmuje gwarancja, jak długo trwa i co jest błędem, a co nową funkcją?
- Ile kosztuje utrzymanie po wdrożeniu i co jest w jego cenie?
- Kiedy przechodzą na mnie prawa autorskie, repozytorium i konta w sklepach?
Jeśli po tych pytaniach nadal nie wiesz, która oferta jest lepsza, poproś obu wykonawców o płatną analizę pierwszego etapu. Jak wygląda analiza i kolejne etapy u nas, opisujemy na stronie o procesie współpracy, a ceny typowych projektów znajdziesz w cenniku i na stronie o tworzeniu aplikacji mobilnych.
