Ile kosztuje aplikacja webowa: od czego zależy wycena i jak nie przepłacić za pierwszą wersję

Ile kosztuje aplikacja webowa, da się uczciwie powiedzieć dopiero wtedy, gdy wiadomo, kto będzie z niej korzystał, co ma robić każdy z tych użytkowników i z jakimi systemami aplikacja musi wymieniać dane. Dwa projekty opisane tym samym zdaniem „panel dla klientów” potrafią różnić się zakresem kilkukrotnie. Dlatego poniżej najpierw moje widełki, a dalej to, jak powstaje wycena i które decyzje przesuwają ją w górę albo w dół.

Ile kosztuje aplikacja webowa: siedem czynników, które ustalają cenę

• Role i uprawnienia. Aplikacja z jednym typem użytkownika jest prostsza niż system, w którym klient widzi swoje zlecenia, kierownik wszystkie, a księgowa tylko faktury.
• Ekrany z logiką. Formularz kontaktowy i formularz, który liczy cenę z wymiarów i materiałów, to zupełnie różne zadania. O koszcie decyduje logika, nie liczba podstron.
• Integracje. Płatności, fakturowanie i KSeF, poczta, SMS, API dostawców, kurierzy. Każda integracja oznacza mapowanie danych, obsługę błędów i osobne testy.
• Import danych. Jednorazowe przeniesienie arkusza jest proste. Dwukierunkowa synchronizacja ze starym systemem, który ma działać równolegle, potrafi być największą pozycją w projekcie.
• Raporty. Eksport do pliku CSV to niewiele pracy. Panel z wykresami, filtrami i porównaniem okresów to osobny moduł.
• Wymagania bezpieczeństwa. Aplikacja z danymi osobowymi, płatnościami albo dokumentacją medyczną wymaga więcej zabezpieczeń, logów i testów niż wewnętrzny kalendarz zespołu.
• Praca na telefonie. Widok responsywny wystarcza w większości przypadków. Tryb offline, aparat albo powiadomienia oznaczają aplikację PWA lub mobilną, czyli inny zakres.

Bezpieczeństwo jako osobna pozycja w wycenie

Skalę pracy przy zabezpieczeniach dobrze widać na standardzie OWASP ASVS, czyli liście wymagań używanej przy projektowaniu i testowaniu zabezpieczeń aplikacji webowych. Wersja 5.0.0, wydana w maju 2025 roku, zawiera 345 wymagań, z których tylko 70 należy do pierwszego poziomu. Każdy wyższy poziom dokłada wymagania do wdrożenia i sprawdzenia, czyli godziny pracy. Narzędzie dla pięciu osób z zespołu potrzebuje mniej niż panel z danymi tysięcy klientów. Dobrze, gdy oferta mówi wprost, jaki poziom zabezpieczeń zakłada, zamiast obiecywać „pełne bezpieczeństwo”.

Pierwsza wersja czy pełny system od razu

Przykład: firma serwisowa chce systemu zleceń z panelem klienta, widokiem dla techników, magazynem części i fakturowaniem. Pierwsza wersja może obejmować tylko przyjmowanie zleceń i przydział techników. Magazyn i panel klienta trafiają do kolejnych etapów, wycenianych dopiero wtedy, gdy wiadomo, jak zespół korzysta z pierwszej części. Więcej takich zastosowań zebrałem w tekście aplikacje webowe: przykłady.

Decyzje, które obniżają koszt

• Zacząć od jednego procesu zamiast całej firmy naraz.
• Sięgnąć po gotowe usługi tam, gdzie własne rozwiązanie nie daje przewagi: wysyłka maili, płatności, mapy.
• Wybrać jednorazowy import zamiast synchronizacji ze starym systemem, jeśli ten da się wyłączyć.
• W pierwszej wersji raport jako eksport do arkusza, a panel z wykresami dopiero wtedy, gdy wiadomo, które liczby są naprawdę potrzebne.
• Jedna wersja językowa na start, kolejne po sprawdzeniu, że są potrzebne.

Jeśli proces da się obsłużyć połączeniem narzędzi, które już masz, czasem wystarczy automatyzacja zamiast nowej aplikacji. Rachunek obu dróg w perspektywie kilku lat rozpisałem w tekście oprogramowanie na zamówienie czy SaaS.

Koszty po uruchomieniu

Aplikacja webowa nie kończy się w dniu startu. Stałe pozycje to serwer i baza danych, kopie zapasowe, domena, aktualizacje bibliotek i monitoring błędów. Do tego rozwój: funkcje, które zespół zgłosi po pierwszych tygodniach pracy. W aplikacji na zamówienie nie płacisz za liczbę użytkowników, więc zatrudnienie dziesięciu nowych osób nie zmienia rachunku tak, jak w abonamencie SaaS.

Sygnały ostrzegawcze w ofercie

• Jedna kwota bez listy funkcji, ról i integracji. Nie da się sprawdzić, co jest w cenie.
• Brak etapu analizy. Wycena „na oko” bywa albo zawyżona, albo kończy się dopłatami w trakcie.
• Kod i baza zostają u wykonawcy. Dostajesz tylko dostęp do aplikacji, a zmiana wykonawcy oznacza budowę od nowa.
• Brak środowiska testowego. Nie widzisz postępu, dopóki wszystko nie trafi na produkcję.
• Opłata za użytkownika ukryta w umowie utrzymania. Aplikacja „na zamówienie”, która rozlicza się jak abonament.

Jak opisać projekt, żeby oferty od różnych wykonawców dało się porównać punkt po punkcie, pokazuję w tekście jak przygotować brief. Jeśli dziś proces żyje w arkuszu, punktem wyjścia może być aplikacja zamiast Excela, a pakiet dla swojego zakresu sprawdzisz w wycenie online.

Źródła: OWASP ASVS, Application Security Verification Standard oraz ASVS 5.0: zmiany względem wersji 4.0.