Ile kosztuje aplikacja webowa dla firmy i od czego zależy cena

„Ile kosztuje aplikacja webowa?" to pytanie, które słyszymy na prawie każdej pierwszej rozmowie. Uczciwa odpowiedź brzmi „to zależy", ale sama w sobie jest bezużyteczna. Użyteczne jest dopiero to, od czego zależy, bo wtedy możesz świadomie zdecydować, za co chcesz zapłacić, a z czego zrezygnować.

Poniżej rozkładamy cenę na czynniki, które realnie ją ustalają. Na przykładach z naszych projektów, a nie z abstrakcyjnego cennika.

Co naprawdę ustala cenę aplikacji webowej?

Klienci często zakładają, że płacą za ekrany: formularze, tabele, przyciski. Tymczasem ekran to warstwa, którą widać. Większość pracy dzieje się pod nią.

1. Liczba ról i stron systemu

Aplikacja dla jednego typu użytkownika to inny projekt niż system, w którym każda grupa widzi coś innego. Platforma, którą zbudowaliśmy dla Medby, obsługuje naraz cztery strony: strefę klienta, panel dostawcy, narzędzia handlowca i centrum zarządzania platformą. Każda ma własne uprawnienia, własne widoki i własne reguły. To jest ten sam system, ale praca projektowa i testowa rośnie z każdą rolą.

2. Integracje z innymi systemami

Każde połączenie z zewnętrznym systemem to osobny mały projekt, bo każdy dostawca API ma swoje zasady. Przy naszym panelu operacyjnym bank przez open banking pozwala na około 4 zapytania na konto dziennie, więc transakcje trzeba przechowywać we własnej bazie. Rządowy KSeF przyjmuje zapytania o maksymalnie 3 miesiące naraz, więc dłuższe okresy dzielimy na okna 89-dniowe. Takie rzeczy wychodzą dopiero przy budowie i właśnie dlatego integracje wycenia się osobno.

3. Logika biznesowa

To najczęściej niedoszacowany czynnik. Formularz zamówienia wygląda tak samo w prostym sklepie i w platformie B2B, ale pod spodem to dwa różne światy. W Medby cena końcowa składa się z 8 dźwigni cenowych w 56 możliwych kombinacjach (rabaty dostawcy i platformy, marże, ceny indywidualne, progi ilościowe, rabaty na zamówienie i na koszyk), a kalkulator pilnuje, żeby żadna kombinacja nie zeszła poniżej kosztu zakupu. Ekran pokazuje jedną liczbę. Za tą liczbą stoi silnik, który trzeba zaprojektować, zbudować i przetestować.

4. Migracja danych

Jeśli aplikacja zastępuje stary system, dane muszą przejść razem z nią. Przy Medby przenieśliśmy bazę z WooCommerce razem z historią zamówień i dopasowaliśmy ją po SKU do nowego katalogu, dzięki czemu klienci od pierwszego dnia mogli ponowić wcześniejsze zakupy jednym kliknięciem. Migracja rzadko jest widowiskowa, ale źle zrobiona potrafi zniweczyć cały projekt.

5. Bezpieczeństwo i izolacja danych

Gdy do systemu logują się klienci z zewnątrz, każdy musi widzieć wyłącznie swoje dane. W naszym portalu klienta identyfikator klienta jest brany zawsze z sesji, nigdy z żądania, więc podmiana parametru w adresie niczego nie odsłoni. Takie zabezpieczenia projektuje się od pierwszego dnia, a nie dokleja na końcu, i to też jest pozycja w wycenie.

Czy AI w aplikacji podnosi cenę?

Podnosi koszt budowy o tyle, ile trzeba zaprojektować wokół modelu: dane, kontekst, zabezpieczenia i testy. Ale ważniejszy jest koszt działania, bo model płaci się za użycie. Dlatego w naszych projektach dobieramy model do zadania: tani i szybki do masowej klasyfikacji maili i streszczeń, mocniejszy tylko tam, gdzie liczy się jakość, na przykład przy pisaniu ofert. I jedna zasada, od której nie robimy wyjątków: sumy, marże i terminy liczy kod, nie model. Modele językowe liczą kiepsko, a tu chodzi o pieniądze.

Koszt budowy to nie cały koszt

Porównując aplikację na zamówienie z gotowym oprogramowaniem, większość firm zestawia cenę budowy z miesięcznym abonamentem. To porównanie jest niepełne z obu stron. Po stronie aplikacji dochodzi hosting, utrzymanie i rozwój. Po stronie gotowców dochodzą licencje, z których nikt nie korzysta. Według Zylo firmy realnie używają około 49% wykupionych licencji SaaS (Zylo, 2025, dane dostawcy). Szerzej rozpisaliśmy to w tekście „Płacisz za 300 aplikacji, używasz połowy".

Sami przeszliśmy ten rachunek na własnej skórze. Nasz wewnętrzny panel zastąpił nam osobny CRM, fakturowanie, helpdesk, narzędzie do maili i arkusze finansowe. Zamiast kilku rosnących abonamentów mamy jeden system, który znamy do ostatniej linijki.

Jak wygląda wycena fixed price etapami?

Nie rozliczamy się za godziny. W czasach AI liczba przepracowanych godzin coraz mniej mówi o wartości, a klient chce wiedzieć, ile zapłaci, zanim podpisze umowę. Dlatego każdy projekt wygląda tak:

1. Rozmowa i audyt. Ustalamy, jaki problem biznesowy ma rozwiązać aplikacja i jak dziś wygląda proces.
2. Podział na etapy. Projekt rozkładamy na części, z których każda sama w sobie daje wartość.
3. Wycena każdego etapu z góry. Znasz koszt i termin każdej części, zanim cokolwiek ruszy.
4. Decyzja: budować czy użyć gotowego. Wspólnie ustalamy, gdzie opłaca się rozwiązanie na miarę, a gdzie taniej i szybciej sięgnąć po gotowe narzędzie.

Dla orientacji w czasie: proste automatyzacje wdrażamy w około tydzień, a rozbudowane systemy, jak automatyzacja całej firmy czy rozwiązanie na autorskich algorytmach, zajmują od 4 do 8 miesięcy razem z audytem, planowaniem, budową i testami.

Gdzie firmy najczęściej przepłacają?

• Pełny system od razu. Budowanie wszystkiego naraz, zanim pierwsza część zdąży pokazać, czy działa. Etapy chronią przed płaceniem za funkcje, które okażą się zbędne.
• Budowanie tego, co gotowce robią dobrze. Płatności, wysyłka maili czy mapy to rzeczy, które lepiej podłączyć niż pisać od zera.
• Brak własności kodu. Aplikacja, której kodu nie masz, wiąże Cię z jednym wykonawcą. Upewnij się, że kod i dokumentacja są Twoje.
• Koszt działania pominięty w decyzji. Szczególnie przy AI: tani w budowie system może być drogi w utrzymaniu, jeśli każde kliknięcie woła najdroższy model.

Kiedy aplikacja na zamówienie się zwraca?

Najczęściej w jednej z trzech sytuacji: gdy zastępuje kilka płatnych narzędzi, gdy odzyskuje godziny powtarzalnej pracy albo gdy robi coś, czego gotowe narzędzia nie robią w ogóle albo robią za drogo. Przykład tej trzeciej sytuacji: dla klienta B2B autorskim algorytmem uzupełniliśmy bazę 100 000 kontaktów o 80 000 numerów telefonów i 50 000 adresów e-mail, za mniej niż 10% ceny gotowych narzędzi przy tej skali (case study).

Jeśli chcesz sprawdzić, jak taki podział na etapy wyglądałby w Twoim przypadku, zobacz, jak podchodzimy do aplikacji webowych i systemów szytych na miarę, albo opisz nam swój pomysł na bezpłatnej konsultacji.

Źródła

1. LUNOLAB, case study: platforma e-commerce B2B Medby.
2. LUNOLAB, case study: panel operacyjny firmy.
3. LUNOLAB, case study: uzupełnienie bazy kontaktów B2B.
4. Zylo, „2025 SaaS Management Index" (40 mln licencji, dane dostawcy).