Ile kosztuje aplikacja webowa w 2026 roku: widełki dla portalu klienta, systemu wewnętrznego i platformy SaaS

Prezes firmy dystrybucyjnej ma na biurku trzy oferty na portal dla klientów B2B. Klienci mają w nim składać zamówienia, sprawdzać statusy dostaw, pobierać faktury i reklamować towar, a portal ma rozmawiać z ERP, które firma ma od dziesięciu lat. Pierwsza oferta opiewa na 180 tysięcy złotych, druga na 520 tysięcy, trzecia na 1,4 miliona. Każda wygląda profesjonalnie, każda ma harmonogram i każda obiecuje „nowoczesne technologie”. Zarząd pyta prezesa, ile to w końcu kosztuje, a on nie umie odpowiedzieć, bo nie wie, która oferta liczy to samo, co pozostałe.

Ta sytuacja nie jest wyjątkiem, tylko normą rynku usług programistycznych. Kwota w ofercie jest wynikiem równania, którego dostawca zwykle nie pokazuje: ilu ludzi, jakich ról, przez ile miesięcy i po jakiej stawce. Gdy znasz to równanie, przestajesz porównywać trzy liczby, a zaczynasz porównywać trzy założenia. Wtedy zwykle okazuje się, że najtańsza oferta nie zawiera testów ani integracji z ERP, a najdroższa wycenia rzeczy, których jeszcze nie potrzebujesz.

W tym artykule pokazujemy, ile kosztuje aplikacja webowa w 2026 roku dla trzech typowych projektów: portalu klienta, systemu wewnętrznego i platformy SaaS. Nie podajemy „średnich rynkowych” wziętych znikąd. Każdy przedział wyprowadzamy z jawnych założeń: składu zespołu, czasu trwania i skali stawek opublikowanej w naszym cenniku. Możesz podmienić każde założenie na własne i przeliczyć wynik w arkuszu w pięć minut.

Dlaczego trzy oferty na tę samą aplikację webową różnią się kilkukrotnie?

Bo prawie nigdy nie dotyczą tej samej aplikacji. Zapytanie ofertowe opisuje produkt zdaniami, a dostawca zamienia te zdania na godziny według własnej interpretacji. „Klient widzi swoje faktury” może oznaczać ekran z listą plików PDF wgranych ręcznie albo synchronizację z ERP co pięć minut, z obsługą korekt, wyszukiwarką i uprawnieniami dla kilku osób po stronie klienta. Różnica w pracochłonności między tymi dwiema interpretacjami jest kilkukrotna, a w zapytaniu ofertowym obie mieszczą się w tym samym zdaniu.

Drugie źródło rozrzutu to zakres usług wokół kodu. Jedna oferta wycenia programistów i nic więcej. Druga dodaje inżyniera QA, konfigurację środowisk, ciągłe wdrażanie i kierownika projektu. Trzecia dorzuca analityka, projektanta UX i rezerwę na ryzyko. Wszystkie trzy mówią o „zbudowaniu portalu”, ale tylko jedna buduje go tak, żeby dało się go bezpiecznie utrzymywać przez kolejne lata. Najtańsza oferta często nie jest tańsza, tylko przenosi część pracy na Ciebie albo na później.

Trzecie źródło to stawki i skład zespołu. Zespół złożony głównie z juniorów ma niższą stawkę dzienną, ale potrzebuje więcej dni i więcej nadzoru. Zespół seniorów jest droższy za dzień, ale szybciej podejmuje decyzje architektoniczne, które później trudno odwrócić. Same stawki nie mówią więc, która oferta jest tańsza w sumie.

Czwarte źródło to rezerwa. Dostawca, który bierze na siebie ryzyko stałej ceny przy niejasnym zakresie, musi je wycenić. Dlatego oferty ryczałtowe przy słabo opisanym zakresie bywają wyraźnie droższe od rozliczanych za czas pracy. Szerzej opisaliśmy ten mechanizm w artykule o tym, kto naprawdę płaci za przeniesienie ryzyka w fixed price.

Praktyczny wniosek: zanim porównasz kwoty, poproś każdego dostawcę o rozbicie oferty na role, liczbę osobomiesięcy i stawki. Dopiero wtedy widać, czy różnica wynika z ceny, czy z zakresu.

Jak policzyć koszt aplikacji webowej bez zgadywania?

Koszt budowy aplikacji to iloczyn trzech wielkości: liczby osób w zespole, czasu pracy i stawki. Wszystko inne, czyli technologia, liczba ekranów, integracje i wymagania bezpieczeństwa, wpływa na wynik przez te trzy zmienne. Więcej integracji to więcej osób albo dłuższy czas. Wyższe wymagania bezpieczeństwa to droższe role i dodatkowe testy. Dlatego wycenę zawsze da się sprowadzić do jednego wzoru, a to pozwala ją sprawdzić.

Przyjmujemy w tym artykule następujące założenia, które możesz zmienić:

• Stawki. Używamy przedziału dla seniorów z naszego cennika: senior developer kosztuje 1 440–2 080 zł netto za dzień, czyli 180–260 zł za godzinę. To ta sama skala, którą stosujemy w benchmarku stawek specjalistów IT na 2026 rok. Dla uproszczenia liczymy wszystkie role w tym przedziale. W praktyce frontend bywa nieco tańszy, a architekt i DevOps droższy, więc w zespole mieszanym te różnice częściowo się znoszą.
• Czas. Liczymy 18 fakturowanych dni w miesiącu na pełny etat. Miesiąc ma ok. 21 dni roboczych, ale urlopy, święta i choroby zmniejszają liczbę dni faktycznie przepracowanych i zafakturowanych.
• Koszt osobomiesiąca. Z dwóch powyższych wynika, że jeden osobomiesiąc seniora kosztuje od 1 440 × 18 = 25 920 zł do 2 080 × 18 = 37 440 zł netto.
• Rezerwa. Do kosztu budowy doliczamy osobno 15% rezerwy na wymagania, które wyjaśnią się dopiero, gdy użytkownicy zobaczą działający system.

Dolna granica każdego przedziału to krótszy wariant harmonogramu przy dolnej stawce, górna to dłuższy wariant przy górnej stawce. Zespół z większym udziałem specjalistów mid może zejść poniżej dolnej granicy, bo ich stawki są niższe. Tak liczy też nasz kalkulator kosztów MVP: dolna granica łączy węższy zakres ze stawkami mid, górna pełniejszy zakres ze stawkami seniorów.

Ważne zastrzeżenie: to nie jest cennik ARDURA ani obietnica ceny. To metoda szacowania z jawnymi założeniami. Każdy projekt wyceniamy indywidualnie, a te liczby służą do tego, żebyś przed rozmową z dostawcą wiedział, jakiego rzędu kwot się spodziewać i jak czytać oferty.

Ile kosztuje portal klienta?

Portal klienta to aplikacja webowa, w której Twoi klienci obsługują się sami: składają zamówienia, sprawdzają statusy, pobierają dokumenty, zgłaszają reklamacje. Jej cechą charakterystyczną jest to, że rzadko żyje samodzielnie. Prawie zawsze pokazuje dane z systemów, które już masz: ERP, CRM, systemu magazynowego, systemu fakturowego. Dlatego koszt portalu zależy bardziej od integracji niż od liczby ekranów.

Założenia zespołu. Typowy skład to 4 pełne etaty w ujęciu średnim: dwóch programistów full-stack, inżynier QA w połowie etatu, projektant UX w połowie etatu, analityk lub kierownik projektu w połowie etatu oraz tech lead z kompetencjami DevOps w połowie etatu. Harmonogram: 4–6 miesięcy do wersji produkcyjnej, licząc z fazą discovery.

Arytmetyka. 4 osoby × 4 miesiące = 16 osobomiesięcy. 4 osoby × 6 miesięcy = 24 osobomiesiące.

• Dolna granica: 16 × 25 920 zł = 414 720 zł
• Górna granica: 24 × 37 440 zł = 898 560 zł
• Z rezerwą 15%: ok. 477 tys. – 1,03 mln zł

Co mieści się w tym przedziale: logowanie z kontami firmowymi i kilkoma rolami użytkowników po stronie klienta, katalog z cenami indywidualnymi, składanie zamówień, statusy i historia, faktury, prosty moduł reklamacji, panel administracyjny dla Twoich pracowników, integracja z ERP w obie strony i z jednym dodatkowym systemem, testy automatyczne kluczowych ścieżek oraz środowiska testowe i produkcyjne.

Co przesuwa portal w stronę górnej granicy albo powyżej: ERP bez dokumentowanego API, przez co integrację trzeba budować na plikach, widokach bazy danych lub warstwie pośredniej; złożone cenniki z rabatami progowymi i promocjami; kilka języków i walut; wysokie wymagania dostępności, jeśli portal obsługuje konsumentów. Europejski akt o dostępności (dyrektywa (UE) 2019/882) stosuje się od 28 czerwca 2025 roku m.in. do usług handlu elektronicznego dla konsumentów, więc w portalu B2C dostępność jest wymaganiem prawnym, a nie dodatkiem.

Istnieje też wariant wąski. Portal, który na start tylko pokazuje statusy zamówień i faktury, bez składania zamówień, można zbudować mniejszym zespołem w krótszym czasie. Przy 2,5 etatu i 3 miesiącach to 7,5 osobomiesiąca, czyli ok. 194–281 tys. zł przed rezerwą. To często rozsądny pierwszy krok: sprawdzasz, czy klienci w ogóle chcą się obsługiwać sami, zanim zainwestujesz w pełny moduł zamówień.

Ile kosztuje system wewnętrzny dla firmy?

System wewnętrzny to aplikacja dla Twoich pracowników: obieg wniosków, planowanie zasobów, ewidencja zleceń, panel operacyjny, który zastępuje arkusze kalkulacyjne i maile. Jest zwykle tańszy od portalu klienta z dwóch powodów. Użytkownicy są przeszkoleni i jest ich mniej, więc projekt interfejsu może być prostszy, a wymagania wydajnościowe są skromniejsze. Nie trzeba też walczyć o konwersję ani o pierwsze wrażenie.

Ma jednak dwie pułapki, które podnoszą koszt bardziej, niż się zarządom wydaje. Pierwsza to migracja danych: dane z arkuszy i starych systemów są niespójne, mają duplikaty i braki, a ich oczyszczenie potrafi zająć tyle, co zbudowanie modułu. Druga to reguły biznesowe zapisane w głowach: proces, który „wszyscy znają”, okazuje się mieć kilkanaście wyjątków, które ktoś obsługuje ręcznie. Każdy wyjątek to dodatkowa logika i dodatkowe testy.

Założenia zespołu. 3 pełne etaty w ujęciu średnim: dwóch programistów, inżynier QA w połowie etatu, analityk lub kierownik projektu w połowie etatu. Projekt interfejsu realizuje zespół na bazie gotowej biblioteki komponentów. Harmonogram: 3–5 miesięcy.

Arytmetyka. 3 × 3 = 9 osobomiesięcy. 3 × 5 = 15 osobomiesięcy.

• Dolna granica: 9 × 25 920 zł = 233 280 zł
• Górna granica: 15 × 37 440 zł = 561 600 zł
• Z rezerwą 15%: ok. 268–646 tys. zł

Przed decyzją o budowie systemu wewnętrznego warto zadać pytanie, które dostawca oprogramowania dedykowanego nie zawsze zada: czy tego samego nie da się osiągnąć konfiguracją narzędzia, które już macie, albo gotowym produktem SaaS? Jeśli proces jest typowy, na przykład obsługa urlopów, prosty CRM czy zgłoszenia serwisowe, gotowe narzędzie zwykle wygra kosztem całkowitym. System dedykowany ma sens, gdy proces jest źródłem przewagi albo na tyle nietypowy, że gotowe narzędzia wymuszałyby obejścia. Tę decyzję rozpisaliśmy szczegółowo w przewodniku po oprogramowaniu dedykowanym w 2026 roku, łącznie z porównaniem pięcioletniego kosztu budowy i subskrypcji.

Ile kosztuje platforma SaaS?

Platforma SaaS to produkt, który sprzedajesz wielu klientom w abonamencie. Technicznie jest to najtrudniejszy z trzech typów, bo do funkcji biznesowych dochodzi cała warstwa, której portal i system wewnętrzny nie potrzebują: obsługa wielu najemców z izolacją danych, samodzielna rejestracja i onboarding, rozliczenia abonamentowe, plany i limity, panel administracyjny operatora, audyt działań, a często również API dla klientów. Do tego dochodzą wymagania, które w produkcie sprzedawanym firmom szybko stają się warunkiem zakupu: logowanie jednokrotne (SSO), eksport danych, dziennik zdarzeń i deklarowana dostępność usługi.

Założenia zespołu. 6 pełnych etatów w ujęciu średnim: trzech programistów (backend i frontend), tech lead lub architekt, inżynier QA, projektant UX w połowie etatu oraz product owner lub kierownik projektu w połowie etatu. Inżynier DevOps jest wliczony w czas tech leada i programistów; w produktach o wysokich wymaganiach dostępności warto go wyodrębnić. Harmonogram: 7–10 miesięcy do wersji 1.0, którą można sprzedawać pierwszym klientom płacącym.

Arytmetyka. 6 × 7 = 42 osobomiesiące. 6 × 10 = 60 osobomiesięcy.

• Dolna granica: 42 × 25 920 zł = 1 088 640 zł
• Górna granica: 60 × 37 440 zł = 2 246 400 zł
• Z rezerwą 15%: ok. 1,25–2,58 mln zł

To wersja 1.0, a nie MVP. Jeśli dopiero sprawdzasz, czy ktokolwiek zapłaci za produkt, nie buduj od razu pełnej platformy. Pierwsza wersja dla kilku klientów pilotażowych może pominąć samodzielną rejestrację, rozliczenia automatyczne i rozbudowane uprawnienia, a to skraca harmonogram o kilka miesięcy. Fazy budżetu MVP i typowe pułapki opisaliśmy w przewodniku o tym, jak zaplanować koszt budowy MVP. Nie powtarzamy ich tutaj.

Platforma SaaS ma też koszty operacyjne, których nie mają pozostałe typy. Jeśli pobierasz płatności kartą, operator płatności pobiera prowizję od każdej transakcji. Na przykład Stripe w Polsce podaje w cenniku stawkę 1,5% + 1 zł dla standardowych kart z EOG i wyższe stawki dla kart spoza EOG. Przy abonamencie za 200 zł miesięcznie to ok. 4 zł od każdej płatności, czyli koszt, który trzeba uwzględnić w cenniku produktu, a nie w budżecie budowy.

Jak wyglądają widełki trzech typów aplikacji webowych obok siebie?

Poniższa tabela zbiera założenia i wyniki w jednym miejscu. Służy do porównania rzędów wielkości i do rozmowy z dostawcą, a nie jako cennik. Każdy wiersz możesz przeliczyć na własnych założeniach.

Typ aplikacji	Zespół (etaty)	Czas do wersji produkcyjnej	Osobomiesiące	Koszt budowy netto (bez rezerwy)	Co najmocniej przesuwa cenę	Kiedy wybrać ten typ
System wewnętrzny	3	3–5 mies.	9–15	233–562 tys. zł	Migracja danych, liczba wyjątków w procesie, integracje	Proces nietypowy lub będący przewagą, gotowe narzędzia wymuszają obejścia
Portal klienta (wariant wąski)	2,5	3 mies.	7,5	194–281 tys. zł	Jakość API systemu źródłowego	Chcesz sprawdzić, czy klienci będą się obsługiwać sami
Portal klienta (pełny)	4	4–6 mies.	16–24	415–899 tys. zł	Integracja z ERP, cenniki indywidualne, dostępność (B2C)	Odciążenie obsługi klienta, sprzedaż B2B online
Platforma SaaS 1.0	6	7–10 mies.	42–60	1,09–2,25 mln zł	Wielonajemcowość, rozliczenia, SSO, wymagania klientów enterprise	Produkt sprzedawany wielu klientom w abonamencie

Założenia wspólne: stawka seniora 180–260 zł/h (1 440–2 080 zł/dzień), 18 fakturowanych dni na etat miesięcznie. Do każdego wyniku dolicz rezerwę ok. 15% oraz koszty zewnętrzne opisane niżej.

Dwie obserwacje z tabeli. Po pierwsze, różnica między typami wynika głównie z liczby osobomiesięcy, a nie ze stawek. Stawka zmienia wynik o mniej więcej 45% między dolną a górną granicą przedziału, a zakres zmienia go kilkukrotnie. To oznacza, że negocjowanie stawki ma mniejszy wpływ na budżet niż dyscyplina zakresu. Po drugie, wariant wąski portalu kosztuje mniej niż jedna trzecia pełnego. Jeśli nie masz pewności, czy klienci przyjmą nowy kanał, ta różnica to cena sprawdzenia hipotezy przed dużą inwestycją.

Co najbardziej przesuwa cenę aplikacji webowej w górę lub w dół?

Sześć czynników odpowiada za większość różnic między dolną a górną granicą przedziału. Warto je przejść z dostawcą punkt po punkcie, bo każdy z nich da się opisać przed podpisaniem umowy.

Integracje. Każdy system, z którym aplikacja wymienia dane, to osobny mały projekt: analiza API, mapowanie pól, obsługa błędów, testy na środowisku testowym drugiej strony. Integracja z systemem, który ma udokumentowane REST API i środowisko sandbox, jest kilkakrotnie tańsza niż z systemem, do którego dostęp jest tylko przez bazę danych lub eksport plików. Zapytaj dostawcę, ile dni przewiduje na każdą integrację osobno.

Role i uprawnienia. Aplikacja z jednym typem użytkownika jest prosta. Aplikacja, w której klient ma administratora, kupca i księgową, a każda rola widzi co innego, wymaga przemyślanego modelu uprawnień i testów każdej kombinacji. Liczba ról mnoży liczbę przypadków testowych.

Dane i migracja. Aplikacja startująca z pustą bazą jest tańsza niż ta, która musi przejąć dziesięć lat historii. Migracja wymaga analizy jakości danych, skryptów, kilku przebiegów próbnych i decyzji biznesowych o tym, co zrobić z rekordami niepełnymi.

Wymagania niefunkcjonalne. Wydajność przy dużym ruchu, wysoka dostępność, szyfrowanie, audyt działań, zgodność z RODO, a w usługach dla konsumentów dostępność cyfrowa. Każde z tych wymagań jest uzasadnione, ale każde kosztuje i warto je nazwać liczbowo: ilu użytkowników jednocześnie, jaki czas odpowiedzi, jaka dopuszczalna przerwa.

Projekt interfejsu. Aplikacja zbudowana na gotowej bibliotece komponentów jest wyraźnie tańsza niż ta z indywidualnym systemem projektowym, animacjami i dopracowaniem każdego ekranu. W systemie wewnętrznym gotowe komponenty zwykle wystarczą. W produkcie SaaS walczącym o klientów wygląd może być częścią wartości.

Szybkość decyzji po Twojej stronie. To czynnik najczęściej pomijany. Zespół, który czeka tydzień na odpowiedź o regułę rabatową, dalej kosztuje. Jedna osoba po stronie zamawiającego z prawem do szybkich decyzji o zakresie potrafi skrócić harmonogram bardziej niż dodatkowy programista.

Czego nie ma w wycenie budowy, a pojawi się na fakturach?

Oferta software house’u wycenia pracę zespołu. Na Twoje konto trafią też inne koszty, które warto zaplanować w budżecie od początku, żeby zarząd nie dowiadywał się o nich po starcie.

• Hosting i infrastruktura chmurowa. Środowisko produkcyjne, testowe i deweloperskie, bazy danych, kopie zapasowe, monitoring. Dla małego portalu to kwoty rzędu setek lub niskich tysięcy złotych miesięcznie, dla platformy SaaS z wieloma klientami więcej. Poproś dostawcę o szacunek dla Twojej skali, a nie ogólnik.
• Usługi zewnętrzne. Bramka płatności, wysyłka e-maili i SMS-ów, mapy, weryfikacja tożsamości, usługi AI. Większość rozlicza się od wolumenu, więc rośnie razem z sukcesem produktu.
• Licencje. Komercyjne biblioteki, narzędzia do monitoringu błędów, usługi logowania jednokrotnego, czasem licencja na API systemu, z którym się integrujesz.
• Rezerwa na zmiany. Wspomniane 10–20% budżetu budowy. To nie zapas „na wszelki wypadek”, tylko uczciwe przyznanie, że część wymagań wyjaśni się dopiero po pierwszych demonstracjach.
• Utrzymanie i rozwój po starcie. Aktualizacje bibliotek i frameworków, poprawki bezpieczeństwa, drobne zmiany zgłaszane przez użytkowników, monitoring. W przewodniku po oprogramowaniu dedykowanym przyjęliśmy jako założenie 20% kosztu budowy rocznie od drugiego roku. Twoja wartość może być inna, ale planuj ją jako stały koszt, nie jednorazowy. Modele utrzymania opisuje artykuł o utrzymaniu oprogramowania po wdrożeniu.
• Czas Twoich ludzi. Product owner, eksperci dziedzinowi na warsztatach, testy akceptacyjne. To nie jest pozycja na fakturze dostawcy, ale jest realnym kosztem projektu.

Prosty test oferty: jeśli dostawca nie wspomina o żadnej z tych pozycji, zapytaj, czy po prostu ich nie wycenił, czy zakłada, że to Twój problem.

Fixed price czy time and materials: który model rozliczenia wybrać dla aplikacji webowej?

Wybór modelu rozliczenia zmienia nie tylko sposób płacenia, ale też to, kto ponosi ryzyko nieznanego zakresu i ile za nie płaci. W ARDURA Consulting realizujemy projekty w obu modelach, a w praktyce zasada jest prosta.

Fixed price ma sens, gdy zakres jest opisany na poziomie, który pozwala go zweryfikować przy odbiorze: lista funkcji z kryteriami akceptacji, makiety kluczowych ekranów, opis integracji z konkretnymi API. Taki opis powstaje zwykle w fazie discovery. Stała cena przy takim zakresie daje zarządowi przewidywalność, a dostawcy jasne kryteria. Ceną jest mniejsza elastyczność: każda zmiana to aneks.

Time and materials ma sens, gdy zakres będzie się wyjaśniał w trakcie, co w nowych produktach jest normą. Płacisz za faktycznie przepracowany czas, a kontrolę zapewniasz budżetem na etap, przeglądem po każdym sprincie i prawem do przerwania. Ten model jest tańszy przy niepewnym zakresie, bo dostawca nie musi wliczać wysokiej rezerwy, ale wymaga aktywnego zaangażowania po Twojej stronie.

Najczęstszym błędem jest połączenie zwinnej realizacji z umową o stałej cenie przy niejasnej specyfikacji. Kończy się to sporami o to, co było „w zakresie”, a obie strony mają rację w swojej interpretacji. Rozwiązaniem pośrednim jest stała cena za discovery i pierwszy etap, a potem rozliczenie za czas z limitem budżetu na kolejne etapy. Porównanie modeli z podziałem ryzyka znajdziesz w artykule o abonamencie zespołu, time and materials i fixed price.

Jak sprawdzić, czy oferta software house’u jest realistyczna?

Realistyczna oferta to taka, której arytmetykę da się odtworzyć. Poniższe pytania pozwalają sprowadzić każdą ofertę do wspólnego mianownika i wyłapać założenia, które dostawca przemilczał.

1. Jaki jest skład zespołu i w jakim wymiarze? Poproś o listę ról z procentem etatu dla każdej osoby w każdym etapie. Brak QA, DevOps albo analityka to nie oszczędność, tylko przeniesienie pracy na Ciebie.
2. Ile osobomiesięcy zakładacie i po jakich stawkach? Pomnóż i sprawdź, czy wychodzi kwota z oferty. Jeśli nie wychodzi, zapytaj o różnicę.
3. Co dokładnie obejmuje każda integracja? Kierunek przepływu danych, częstotliwość, obsługa błędów, środowisko testowe drugiej strony, kto dostarcza dostęp do API.
4. Jak testujecie i kto odpowiada za testy akceptacyjne? Testy automatyczne kluczowych ścieżek powinny być częścią budowy, nie opcją.
5. Jaką rezerwę zawiera cena i co się dzieje, gdy się wyczerpie? W fixed price rezerwa jest w cenie, w time and materials powinna być jawna.
6. Kto jest właścicielem kodu i od kiedy? Przeniesienie autorskich praw majątkowych na konkretnych polach eksploatacji, dostęp do repozytorium od pierwszego dnia, dokumentacja.
7. Jak wygląda przekazanie systemu, jeśli zakończymy współpracę? Dokumentacja, okres przejściowy, wsparcie dla nowego zespołu.
8. Jakie koszty zewnętrzne przewidujecie? Hosting, licencje, usługi płatne od wolumenu.

Tę samą arytmetykę można zastosować w odwrotną stronę, do sprawdzenia oferty, która nie ma rozbicia. Wróćmy do prezesa z początku artykułu. Oferta za 180 tysięcy złotych, podzielona przez koszt osobomiesiąca seniora (25 920–37 440 zł), daje ok. 5–7 osobomiesięcy pracy. Przy czterech osobach to niecałe dwa miesiące. Pełny portal z integracją z ERP w obie strony w dwa miesiące jest mało prawdopodobny, więc albo oferta zakłada znacznie węższy zakres, niż prezes myśli, albo zespół złożony głównie z juniorów, albo pominięte pozycje, takie jak testy i integracja. Oferta za 1,4 miliona to z kolei 37–54 osobomiesiące, czyli zakres bliższy platformie niż portalowi. Warto zapytać, co w niej jest ponad potrzeby pierwszej wersji. Oferta za 520 tysięcy mieści się w przedziale pełnego portalu, ale to nie znaczy, że jest dobra. Znaczy tylko, że jej arytmetyka jest wiarygodna i warto sprawdzić pozostałe punkty listy.

Odpowiedzi na te pytania mówią więcej niż prezentacja firmy. Dostawca, który odpowiada konkretnie i z liczbami, zwykle tak samo prowadzi projekt.

Jakie sygnały ostrzegawcze w ofercie powinny zatrzymać podpis?

Kilka wzorców powtarza się w ofertach, które później zamieniają się w drogie problemy. Każdy z nich nie musi oznaczać złej woli, ale każdy wymaga wyjaśnienia przed podpisem.

• Cena bez rozbicia. Jedna kwota za „portal klienta” bez ról, czasu i zakresu. Nie masz jak jej porównać ani rozliczyć zmian.
• Stała cena przy zakresie opisanym jednym akapitem. Albo cena zawiera bardzo dużą rezerwę, albo dostawca zamierza dyskutować z Tobą każdą funkcję przy odbiorze.
• Harmonogram bez fazy discovery. Zespół, który zaczyna programować w pierwszym tygodniu bez analizy integracji i danych, odkryje problemy w trzecim miesiącu, kiedy są drogie.
• Brak testów w wycenie albo testy „po stronie klienta”. To przeniesienie kosztu i ryzyka na Ciebie.
• Kod w repozytorium dostawcy do końca projektu. Bez dostępu do kodu nie wiesz, co powstaje, i nie masz jak zmienić dostawcy.
• Prawa autorskie przechodzą dopiero po zapłacie całości. To częsta i formalnie dopuszczalna klauzula, ale w połączeniu z brakiem dostępu do kodu daje dostawcy dużą przewagę w razie sporu.
• Cena wyraźnie poniżej arytmetyki. Jeśli oferta zakłada 4 osoby przez 5 miesięcy, a kwota odpowiada stawce, za którą seniorów nie da się zatrudnić, zapytaj, kto naprawdę będzie pracował nad projektem.

Jeśli projekt już trwa i widzisz te sygnały w praktyce, a nie tylko w ofercie, to inny problem: wtedy potrzebna jest ocena stanu kodu i plan naprawczy, a nie kolejna oferta.

Jak obniżyć koszt aplikacji webowej bez psucia produktu?

Najskuteczniejsze oszczędności dotyczą zakresu, nie stawek. Stawka seniora różni się między dostawcami o kilkadziesiąt procent, a zakres pierwszej wersji potrafi różnić się kilkukrotnie. Oto dźwignie, które działają.

Zacznij od discovery. Krótka faza analizy kosztuje ułamek budowy, a pozwala usunąć z zakresu funkcje, których nikt nie potrzebuje, i wykryć integracje, które byłyby niespodzianką w trzecim miesiącu. W ARDURA faza discovery trwa 1–2 tygodnie i kończy się opisem zakresu i architektury. Czym jest ten etap i co powinien dać, wyjaśnia hasło proces product discovery w naszym słowniku.

Wytnij do jednej ścieżki użytkownika. Pierwsza wersja portalu nie musi obsługiwać wszystkich scenariuszy. Jeśli 80% kontaktów klientów z obsługą dotyczy statusu zamówienia i faktur, zacznij od tego. Resztę dodasz, gdy dane pokażą, że klienci korzystają.

Kupuj zamiast budować tam, gdzie nie ma przewagi. Logowanie, wysyłka powiadomień, płatności, wyszukiwarka, generowanie dokumentów: na wszystkie te elementy istnieją gotowe usługi. Budowanie ich od zera rzadko się opłaca.

Gotowa biblioteka komponentów zamiast indywidualnego projektu. W systemie wewnętrznym to oszczędność rzędu tygodni pracy projektanta i programisty frontendu, bez widocznej straty dla użytkowników.

Szybkie decyzje. Wyznacz jedną osobę z prawem decyzji o zakresie i daj jej czas na projekt. To nic nie kosztuje, a skraca harmonogram.

Czego nie ciąć: testów automatycznych kluczowych ścieżek, środowiska testowego i dokumentacji integracji. Oszczędność na tych pozycjach wraca z odsetkami w pierwszym roku utrzymania.

Jak przejść od widełek do konkretnej wyceny aplikacji webowej?

Widełki z tego artykułu służą do jednej rzeczy: żebyś wiedział, czy rozmawiasz o projekcie za 300 tysięcy, czy za 2 miliony, zanim zaprosisz dostawców do rozmowy. Konkretna wycena wymaga trzech kroków.

Pierwszy krok to szybki szacunek dla Twojego typu produktu. Nasz kalkulator kosztów MVP pokazuje orientacyjny przedział, czas i skład zespołu dla aplikacji webowej, mobilnej, SaaS lub marketplace w kilka sekund. Nie zna Twoich integracji i danych, ale daje punkt odniesienia.

Drugi krok to spisanie tego, czego kalkulator nie wie: listy systemów do integracji z informacją, czy mają API, liczby ról użytkowników, danych do migracji i wymagań niefunkcjonalnych z liczbami. Ta lista to połowa zapytania ofertowego.

Trzeci krok to discovery, które zamienia przedział w wycenę z rozbiciem na role, osobomiesiące i etapy. Po nim możesz wybrać model rozliczenia świadomie, a nie na ślepo.

Jeśli chcesz przejść te kroki z nami, zespół software development w ARDURA Consulting przygotuje discovery i wycenę z jawną arytmetyką: role, czas, stawki z naszego cennika i rezerwę, którą możesz sprawdzić. Więcej artykułów o planowaniu i budowie oprogramowania znajdziesz w hubie software development.