Aplikacja webowa nie kosztuje od liczby ekranów, tylko od liczby reguł, które ma znać na pamięć. Pytanie „ile kosztuje aplikacja webowa” wraca do mnie w mailach regularnie i prawie zawsze jest zadane od strony wyglądu: ile podstron, jaki panel, czy ma być ładny wykres na starcie. Tymczasem cena rośnie zupełnie gdzie indziej - w miejscach, których nie widać na żadnym zrzucie ekranu. Kto może zatwierdzić rabat. Co się dzieje, gdy magazyn zwróci błąd. Jak wygląda korekta dokumentu wystawionego wczoraj. To są godziny pracy, a nie ekrany.
Poniżej rozkładam to na konkrety: co kryje się pod słowem „aplikacja”, jakie są realne poziomy budżetu, które funkcje najmocniej podbijają wycenę i jak pociąć projekt, żeby nie płacić od razu za wszystko. Jedno zastrzeżenie od razu: nie podaję cudzych cenników w złotówkach, bo w tej kategorii nie ma czegoś takiego jak cena rynkowa - dwie aplikacje o tej samej nazwie potrafią różnić się nakładem pracy dziesięciokrotnie.
Zanim padnie jakakolwiek kwota, warto ustalić, o czym rozmawiamy, bo pod tym słowem najczęściej kryją się trzy różne rzeczy.
Pierwsza to panel dla klientów albo kontrahentów doklejony do istniejącej strony czy sklepu: logowanie, własne dane, historia, dokumenty do pobrania. Druga to narzędzie wewnętrzne, z którego korzysta Twój zespół zamiast arkusza kalkulacyjnego - zlecenia, grafik, obieg zgłoszeń, ewidencja. Trzecia to samodzielny produkt, który ma być sprzedawany innym firmom w abonamencie, z rejestracją, płatnościami i wieloma kontami klienckimi.
To rozróżnienie przesądza o rzędzie wielkości bardziej niż cokolwiek innego. Panel dla kontrahentów korzysta z tego, co już masz. Narzędzie wewnętrzne trzeba zbudować wokół procesu, który dziś żyje w głowach ludzi. Produkt na sprzedaż musi jeszcze obsłużyć przypadki, których sam nigdy nie zobaczysz, bo przyniosą je cudzy klienci. Jeśli w ogóle wahasz się między aplikacją a dobrze zrobioną stroną, tę granicę rozpisałem osobno w tekście o tym, czy firmie potrzebna jest aplikacja, czy wystarczy strona mobilna.
Ile kosztuje aplikacja webowa - trzy poziomy budżetu
W praktyce spotykam trzy poziomy i warto wiedzieć, na którym stoisz, zanim zaczniesz zbierać oferty.
Poziom pierwszy - moduł na istniejącym systemie. Masz WordPressa albo WooCommerce i dokładasz do tego logowanie, własne pola, panel z zamówieniami, generowanie dokumentów. Nie budujesz silnika od zera, tylko dokładasz do niego logikę. To najtańszy sensowny start i taki zakres mieści się zwykle w moich widełkach fixed-bid, czyli około 5000-10 000 zł netto.
Poziom drugi - aplikacja zbudowana wokół jednego procesu. Własna baza, własne role, integracja z jednym czy dwoma systemami, które już masz. Tu kwota wynika wprost z listy funkcji i zawsze podaję ją na piśmie przed startem, rozbitą na pozycje - żeby dało się z niej coś wyjąć, jeśli budżet nie domyka się za pierwszym razem.
Poziom trzeci - system, na którym stoi firma. Wiele ról, rozliczenia, integracje w obie strony, historia zmian, wymagania prawne. To projekt rozliczany etapami, z osobną wyceną każdego etapu, a nie jedną kwotą na wejściu. Uczciwie: jeśli ktoś podaje Ci twardą cenę takiego systemu po jednej rozmowie, wycenił własne wyobrażenie, nie Twój proces.
Do tego dochodzi wybór technologii, który wpływa na stawkę godzinową wykonawcy - porównanie kosztów pracy przy jednym z popularnych frameworków opisałem w tekście o tym, ile kosztuje programista Laravel.
Co najmocniej podbija wycenę
Poniżej lista rzeczy, które w moich wycenach robią największą różnicę, w kolejności od najdroższych. Żadna z nich nie jest widoczna na makiecie.
- Role i uprawnienia. Jeden typ użytkownika jest tani. Cztery typy, z których każdy widzi inne dane i może inne rzeczy zatwierdzić, to osobna warstwa do zaprojektowania, zbudowania i przetestowania. Każda nowa rola mnoży liczbę przypadków do sprawdzenia.
- Integracje z cudzymi systemami. Magazyn, księgowość, kurier, bramka płatności, CRM. Koszt bierze się nie z samego połączenia, tylko z tego, co dzieje się, gdy druga strona nie odpowie, odpowie błędem albo odpowie z opóźnieniem. Aplikacja, która „zwykle działa”, jest znacznie tańsza od takiej, która nie gubi danych nigdy - i to jest realny wybór do podjęcia świadomie.
- Wyjątki od reguł. Najdroższe zdanie w każdym projekcie brzmi „no, prawie zawsze tak, ale…”. Klient hurtowy, który ma inne warunki niż wszyscy pozostali. Zlecenie, które czasem pomija akceptację. Każdy taki wyjątek trzeba opisać w kodzie i pilnować, żeby nie kolidował z resztą.
- Migracja danych. Przeniesienie kilku lat historii z arkuszy i starego programu potrafi zająć więcej czasu niż zbudowanie samej aplikacji. Dane w firmach są niespójne, brakuje im pól, mają literówki w nazwach i duplikaty - i ktoś to musi uporządkować przed importem.
- Dokumenty i wydruki. Oferta, protokół, etykieta, zestawienie do księgowości. To zawsze wygląda na drobiazg, a zawsze okazuje się, że układ musi być dokładnie taki, jak dziś, bo tak przywykli klienci albo tak wymaga księgowa.
- Historia i odpowiedzialność. Zapis, kto co zmienił i kiedy, możliwość cofnięcia zmiany, podgląd stanu sprzed miesiąca. W firmach, gdzie ktoś odpowiada finansowo za wpis w systemie, to nie jest dodatek, tylko podstawa - ale kosztuje osobno.
- Praca w terenie. Aplikacja obsługiwana na telefonie, w hali albo u klienta, gdzie zasięg bywa słaby, to inne wymagania niż panel na biurku.
Zasada, którą stosuję przy każdej rozmowie: policz, ile godzin miesięcznie zjada dziś ręczne robienie tej rzeczy. Funkcja, która nie skraca tego czasu, spokojnie poczeka na drugi etap.
Koszty, o których pamięta się dopiero po starcie
Budżet wdrożenia to nie całość rachunku. Stałe pozycje wyglądają tak:
- Serwer i jego obsługa - aplikacja licząca coś przy każdym kliknięciu potrzebuje więcej niż najtańsze konto współdzielone, a do tego kopii zapasowych, z których naprawdę da się odtworzyć dane.
- Opieka techniczna - u mnie Basic 1000, Pro 2000 i Premium 3500 zł netto miesięcznie, zależnie od tego, czy system ma tylko działać, czy również rosnąć.
- Utrzymanie integracji - to najczęstsze źródło awarii po roku. Dostawca zmienia wersję interfejsu, Twoja aplikacja przestaje się dogadywać z magazynem i ktoś musi to poprawić w ciągu godzin, nie tygodni.
- Zmiany po starcie. Pierwsze tygodnie realnej pracy zawsze przynoszą listę poprawek, bo dopiero wtedy widać, co ludzie robią inaczej, niż deklarowali. Warto zarezerwować na to budżet zamiast udawać, że projekt kończy się w dniu uruchomienia.
- Praca po Twojej stronie - uporządkowanie danych, wpisanie kartotek, przeszkolenie zespołu. Tego nie kupisz, a bez tego najlepszy system pokaże bałagan, który miał uporządkować.
Jak obniżyć cenę, nie okrajając projektu do bezużyteczności
Najtańsza aplikacja to nie ta z najkrótszą listą funkcji, tylko ta, która startuje wąsko i rośnie na podstawie tego, co realnie robią użytkownicy. Kolejność, którą proponuję:
- Jeden proces, od początku do końca. Wybierz tę czynność, która dziś zjada najwięcej czasu, i obsłuż ją w całości. Lepiej mieć jedną rzecz działającą do końca niż pięć zrobionych w połowie.
- Jedna rola na start. Podział uprawnień dokładasz, gdy już wiadomo, kto czego naprawdę używa.
- Import zamiast integracji w pierwszym etapie. Wgrywanie pliku raz dziennie jest wielokrotnie tańsze niż połączenie działające na żywo, a często wystarcza na pierwsze miesiące.
- Gotowe klocki tam, gdzie nie budujesz przewagi. Logowanie, wysyłka maili, płatności, generowanie plików PDF - to rzeczy, których nie ma sensu pisać od zera.
- Odłóż estetykę na koniec. Czytelny, prosty układ wystarczy do pracy. Wygładzanie interfejsu ma sens, gdy wiadomo, które ekrany są używane codziennie.
Po każdym etapie masz działające narzędzie, a nie plac budowy. Jeśli budżet skończy się po etapie drugim, zostaje Ci coś, co pracuje, a nie porzucona inwestycja.
Gotowe narzędzie czy własna aplikacja
Pytanie o koszt prawie zawsze ma drugie dno: czy w ogóle warto budować, skoro na rynku jest gotowy program w abonamencie. Uczciwa odpowiedź brzmi: gotowe narzędzie wygrywa wszędzie tam, gdzie Twój proces jest typowy, a przegrywa tam, gdzie Twoja przewaga polega właśnie na tym, że robisz coś inaczej niż konkurencja.
Praktyczny test: wypisz pięć rzeczy, które musiałbyś obejść w gotowym programie, żeby dało się w nim pracować. Jeśli obejścia sprowadzają się do zmiany przyzwyczajeń, kupuj gotowe. Jeśli oznaczają, że część zespołu i tak zostanie przy arkuszu obok, bo system nie ogarnia Twoich zasad - policz własną aplikację. Ten sam rachunek przy sprzedaży hurtowej rozłożyłem w tekście o wadach i zaletach systemu B2B, a widełki dla konkretnego przypadku platformy handlowej w tekście o kosztach platformy B2B.
Jak wyceniam to u siebie
Zaczynam od bezpłatnej rozmowy o procesie, nie o funkcjach. Pytam, kto dziś co robi, gdzie te dane leżą i w którym miejscu najczęściej coś się gubi. Z tego powstaje lista podzielona na etapy, a przy każdej pozycji stoi kwota - więc widzisz, co ile kosztuje, i możesz coś przesunąć na później zamiast negocjować jedną wielką liczbę.
Projekty fixed-bid mieszczą się zwykle w widełkach 5000-10 000 zł netto, przy szerszym zakresie kwota wynika wprost z listy funkcji. Zawsze na piśmie i zawsze przed startem, więc nie ma sytuacji, w której koszt rośnie w trakcie bez zmiany zakresu. Jeśli po rozmowie okaże się, że Twój problem rozwiązuje gotowe narzędzie za dwieście złotych miesięcznie, powiem to wprost - mam do stracenia jedno zlecenie, Ty masz do stracenia kilka miesięcy.
Najczęstsze pytania
Ile kosztuje prosta aplikacja webowa dla małej firmy? Jeśli „prosta” oznacza panel z logowaniem, własnymi danymi klienta i kilkoma dokumentami do pobrania, dołożony do strony albo sklepu, który już masz - taki zakres mieści się zwykle w widełkach 5000-10 000 zł netto plus koszty serwera i opieki. Kwota rośnie wraz z liczbą ról i integracji, nie wraz z liczbą ekranów.
Czy taniej wyjdzie aplikacja na WordPressie niż pisana od zera? Na starcie zwykle tak, bo część rzeczy jest gotowa: konta, uprawnienia, panel administracyjny, wysyłka maili. Granica przebiega tam, gdzie logiki robi się tyle, że walczysz z systemem zamiast z niego korzystać. Przy narzędziu, w którym ludzie pracują codziennie po kilka godzin, własne rozwiązanie zwykle wychodzi taniej w perspektywie kilku lat.
Ile trwa zbudowanie aplikacji webowej? Pierwszy działający etap to zwykle kwestia tygodni, nie miesięcy - o ile jest wąsko wycięty. Najwięcej czasu zjada nie programowanie, tylko ustalenie reguł i uporządkowanie danych po Twojej stronie, więc realny termin zależy głównie od tego, jak szybko wracają decyzje.
Czy dostanę kod i czy aplikacja będzie moja? Powinna być i u mnie jest. Po zapłacie dostajesz kod, bazę i komplet dostępów, a serwer stoi na Twoim koncie. Przy każdej ofercie na system dedykowany warto zadać to pytanie na piśmie, bo różnica między „masz aplikację” a „masz dostęp do cudzej aplikacji” ujawnia się dopiero w dniu, w którym chcesz zmienić wykonawcę.
Masz do zbudowania aplikację, panel albo integrację, a nie stronę? Piszę systemy B2B na zamówienie - backend, API, panele klienta, moduły rozliczeniowe. Opisz, co ma robić, a odeślę wycenę z zakresem i terminem.