Oprogramowanie na zamówienie – kiedy się opłaca

Oprogramowanie na zamówienie to system budowany pod konkretny proces jednej firmy, zamiast dopasowywania firmy do gotowego produktu. Decyzja o jego zamówieniu rzadko zapada dlatego, że gotowy system jest zły. Zapada wtedy, gdy koszt obchodzenia jego ograniczeń zaczyna przewyższać koszt zbudowania własnego. Ten tekst pokazuje, jak ten moment policzyć zamiast go przeczuwać: co realnie wchodzi do rachunku po obu stronach, gdzie leży próg opłacalności i kiedy uczciwa odpowiedź brzmi “zostań przy gotowym produkcie”.

Disclaimer rynkowy. Ceny licencji oraz widełki budowy podajemy orientacyjnie, jako wartości typowe dla polskiego rynku w sierpniu 2026. Punktem odniesienia jest nasza stawka 150-180 zł netto za godzinę pracy zespołu. Przykład liczbowy w dalszej części jest modelowy i służy pokazaniu mechaniki rachunku, a nie odwzorowaniu konkretnego projektu.

Czym różni się oprogramowanie na zamówienie od gotowego systemu

Różnica sprowadza się do tego, kto się do kogo dopasowuje. Gotowy system narzuca sposób pracy, który wypracował dla setek firm. System dedykowany odwzorowuje proces, który masz. W praktyce rynek oferuje jednak nie dwie, lecz trzy drogi.

• Gotowy produkt z pudełka. Kupujesz abonament i pracujesz tak, jak przewidział producent. Najniższy koszt wejścia, najkrótszy czas startu, zerowa elastyczność w rzeczach, których produkt nie przewiduje.
• Gotowy produkt z konfiguracją i wdrożeniem. Ten sam produkt, ale dostrojony do firmy przez partnera wdrożeniowego: pola, uprawnienia, integracje, czasem drobne rozszerzenia. Koszt rośnie, elastyczność również, choć wciąż w granicach wyznaczonych przez producenta.
• System dedykowany. Budowany od podstaw pod Twój proces. Najwyższy koszt wejścia i najdłuższy czas do startu, natomiast pełna kontrola nad tym, co system robi i dokąd zmierza.

Większość firm ląduje w środkowym wariancie i dobrze się z nim czuje przez lata. Problem pojawia się wtedy, gdy konfiguracja przestaje wystarczać, a zespół zaczyna łatać braki produktu arkuszami kalkulacyjnymi oraz ręcznym przepisywaniem danych. To pierwszy sygnał, że warto policzyć.

Gotowy system nie kosztuje tylko tyle, ile widnieje na fakturze. Kosztuje też tyle, ile zespół dopłaca własną pracą tam, gdzie produkt nie sięga.

Kiedy dedykowany system się opłaca – policzalne kryteria

Odpowiedź daje porównanie pełnego kosztu obu dróg w tym samym horyzoncie czasu. Przyjmujemy pięć lat, bo to typowy okres między poważnymi wymianami systemu w firmie, natomiast to założenie modelu, a nie reguła. Po stronie gotowego produktu do rachunku wchodzą trzy pozycje, a firmy zwykle liczą tylko pierwszą.

1. Abonament razy liczba użytkowników razy liczba lat. Systemy klasy CRM sprzedawane na polskim rynku w modelu za użytkownika mieszczą się zwykle w przedziale 50-300 zł miesięcznie za osobę. Inne klasy produktów, na przykład systemy magazynowe albo produkcyjne, mają własne cenniki i trzeba je sprawdzić osobno.
2. Koszt wdrożenia i konfiguracji. Jednorazowy, ale niemały, a przy zmianie procesu wraca.
3. Koszt obejść. Godziny, które zespół przepala na przepisywanie danych między systemami, ręczne raporty oraz pilnowanie rzeczy, których produkt nie pilnuje. To pozycja niewidoczna w budżecie IT, bo siedzi w wynagrodzeniach działów operacyjnych.

Po stronie systemu dedykowanego rachunek jest krótszy: koszt budowy plus koszt utrzymania rocznie, przyjmowany orientacyjnie na poziomie 10-20 procent wartości projektu. Większy rozwój o nowe funkcje planuje się osobno, natomiast drobne zmiany mogą mieścić się w utrzymaniu, zależnie od zapisów umowy.

Przykład modelowy – gdzie rachunek się przełamuje

Poniższe liczby są modelowe i służą pokazaniu mechaniki. Podstaw pod nie własne, a dostaniesz odpowiedź dla swojej firmy. Założenia: produkt kosztuje 150 zł netto za osobę miesięcznie, wdrożenie i konfiguracja to jednorazowe 30 000 zł, a obejścia zjadają dwie osoby po cztery godziny tygodniowo, co przy koszcie godziny pracy około 55 zł daje mniej więcej 20 000 zł rocznie. Po drugiej stronie: budowa systemu za 200 000 zł oraz utrzymanie po 30 000 zł rocznie, czyli 15 procent wartości projektu.

Rachunek pięcioletni sprowadza się wtedy do prostego wzoru: koszt gotowego produktu = 9000 zł razy liczba użytkowników, plus 30 000 zł wdrożenia, plus 100 000 zł obejść. Kwota 9000 zł to koszt jednego użytkownika przez pięć lat. Po stronie dedykowanej wychodzi 200 000 zł budowy plus cztery lata utrzymania, czyli 320 000 zł niezależnie od liczby osób.

• 25 użytkowników. Gotowy produkt: 225 000 plus 30 000 plus 100 000, razem 355 000 zł. System dedykowany: 320 000 zł. Różnica jest na tyle niewielka, że sam rachunek jeszcze nie rozstrzyga.
• 60 użytkowników. Gotowy produkt: 540 000 plus 30 000 plus 100 000, razem 670 000 zł. System dedykowany dalej 320 000 zł, ponieważ nie ma opłaty za kolejną osobę w firmie.

Przy tych założeniach próg przełamania wypada w okolicach dwudziestu użytkowników. Podstaw własne stawki, a próg przesunie się w jedną albo drugą stronę, natomiast mechanika zostanie ta sama.

I tu leży sedno: próg opłacalności przesuwa liczba użytkowników oraz skala obejść, a nie sama cena wdrożenia. Ważne zastrzeżenie: gdy obie kwoty wypadają blisko siebie, sam rachunek kosztowy nie uzasadnia budowy. Decyzję rozstrzygają wtedy kryteria opisane niżej.

Jeśli chcesz podstawić pod ten wzór swoje liczby i zobaczyć, po której stronie wypada Twoja firma, prześlij nam opis procesu przez formularz wyceny. Odeślemy porównanie obu dróg razem z widełkami budowy dla Twojego zakresu.

Czego nie widać w rachunku po żadnej ze stron

Powyższe liczby zakładają, że warunki się nie zmieniają. W praktyce zmieniają się po obu stronach i warto o tym wiedzieć przed decyzją, a nie po niej.

Przy gotowym produkcie ryzyko leży poza Twoją kontrolą. Producent podnosi cennik, przenosi funkcję z Twojego pakietu do wyższego albo wycofuje plan, z którego korzystasz. Każde z tych zdarzeń zmienia rachunek w trakcie, bez pytania Cię o zdanie. Dochodzi do tego koszt wyjścia, o którym mało kto myśli przy podpisywaniu umowy: przeniesienie kilku lat danych do innego systemu bywa osobnym projektem, a im dłużej korzystasz z produktu, tym ten koszt jest wyższy.

Przy systemie dedykowanym ryzyko jest innego rodzaju. Uzależniasz się nie od producenta, tylko od wykonawcy, który zna Twój kod. Dlatego trzy rzeczy trzeba zapisać w umowie od początku: dostęp do repozytorium kodu od pierwszego dnia, dokumentację techniczną w zakresie umożliwiającym przejęcie projektu oraz warunki przekazania systemu innemu zespołowi. Do tego dochodzi ryzyko wytworzenia: system może powstać z opóźnieniem albo rozminąć się z potrzebą, jeśli po Twojej stronie zabraknie kogoś, kto pilnuje zakresu. Gotowy produkt to ryzyko ogranicza, ale go nie usuwa, bo nieudane wdrożenie i niedopasowanie procesu zdarzają się także po tamtej stronie.

Żadne z tych ryzyk nie przesądza decyzji. Oba warto natomiast wycenić, zamiast udawać, że wybór sprowadza się do kwot z przykładu powyżej.

Trzy pytania kontrolne przed decyzją

Rachunek to jedno, natomiast są sytuacje, w których liczby nie rozstrzygają. Zadaj sobie trzy pytania.

• Czy proces, który chcesz obsłużyć, jest Twoją przewagą? Jeśli tak, oddanie go w ręce produktu, który mają wszyscy konkurenci, kosztuje Cię więcej niż pieniądze.
• Czy dane, które gromadzisz, są dla Ciebie krytyczne? Przy systemie dedykowanym możesz zachować pełną kontrolę nad bazą oraz zasadami dostępu do niej, o ile zapewnią to umowa i wybrana architektura. Nie dzieje się to samo z siebie.
• Czy da się w ogóle kupić to, czego potrzebujesz? Czasem odpowiedź brzmi po prostu nie, bo proces jest zbyt specyficzny. Wtedy rachunek robi się prosty.

Ile kosztuje oprogramowanie na zamówienie

Koszt systemu dedykowanego zależy od tego, ilu ludzi ma obsłużyć oraz jak głęboko wchodzi w procesy firmy. Na polskim rynku sensownie patrzeć na trzy skale.

• Narzędzie wewnętrzne dla jednego zespołu. Obsługa jednego procesu, kilku do kilkunastu osób, prosty panel i raporty. Zwykle kilkadziesiąt tysięcy złotych netto.
• System wspierający kluczowy proces firmy. Wiele ról, uprawnienia, integracje z tym, co już masz, historia zmian. Widełki od stu do kilkuset tysięcy.
• Platforma dla Twoich klientów. System, z którego korzystają odbiorcy zewnętrzni, z wymogami dostępności, bezpieczeństwa oraz skali. Rachunek liczony w setkach tysięcy i wyżej.

Pełne widełki dla różnych typów projektów rozkładamy w przewodniku ile kosztuje aplikacja, a etapy oraz ramy czasowe takiego projektu opisujemy przy okazji tworzenia aplikacji mobilnych. Główne etapy są podobne, choć sposób uruchomienia zależy od rodzaju systemu.

Stała cena czy rozliczenie za czas pracy

To pytanie wraca w każdej rozmowie i nie ma jednej dobrej odpowiedzi. Stała cena daje przewidywalność budżetu, natomiast wymaga zamrożenia zakresu na starcie. Wykonawca dolicza do niej bufor na ryzyko, więc płacisz za pewność. Ten model sprawdza się przy projektach dobrze opisanych, gdzie wiadomo, co ma powstać.

Rozliczenie za czas pracy zespołu daje elastyczność. Zakres może się zmieniać w trakcie, płacisz za faktycznie wykonaną pracę i zwykle nie dokładasz osobnego bufora za ryzyko zamrożonego zakresu. W zamian bierzesz na siebie ryzyko budżetu, dlatego ten model wymaga zaangażowanej osoby po Twojej stronie, która pilnuje priorytetów. W praktyce częstym rozwiązaniem jest podejście mieszane: stała cena za etap analizy oraz projektu, potem rozliczenie za czas pracy przy implementacji.

Prototyp w no-code zanim zamówisz pełny system

Jest jeszcze jedno wyjście, o którym mówi się rzadko, a które potrafi oszczędzić bardzo dużo pieniędzy. Zanim zamówisz system dedykowany, zbuduj prototyp procesu na platformie no-code, czyli takiej, która pozwala złożyć działające narzędzie bez pisania kodu.

Sens jest prosty. Za ułamek budżetu i w kilka tygodni sprawdzasz, czy proces, który masz w głowie, faktycznie działa w praktyce. Zespół używa prototypu przez kwartał, zgłasza uwagi, a Ty wchodzisz do rozmowy o systemie dedykowanym z listą wymagań sprawdzonych w boju zamiast z listą życzeń. To najtańsza znana nam metoda na uniknięcie budowy czegoś, czego nikt potem nie używa.

Bywa też, że prototyp okazuje się rozwiązaniem docelowym. Jeśli obsługuje kilkanaście osób, proces jest stabilny, a wydajność wystarcza, nie ma powodu, żeby cokolwiek przepisywać. Kiedy no-code wystarcza na stałe, a kiedy jest tylko etapem, rozkładamy szczegółowo w tekście o tym, kiedy no-code i low-code mają sens dla firm.

Granica jest w praktyce dość wyraźna. Platformy no-code przestają wystarczać, gdy rośnie liczba użytkowników, pojawiają się nietypowe integracje albo gdy opłaty platformy zaczynają skalować się tak samo niewygodnie jak abonament gotowca. Wtedy wracasz do rachunku z poprzedniej sekcji, tyle że z dużo lepszą wiedzą o własnym procesie.

Kiedy NIE zamawiać dedykowanego systemu

Uczciwa lista sytuacji, w których budowa własnego systemu jest błędem, bywa cenniejsza niż argumenty za. Są cztery takie przypadki.

Proces jeszcze się zmienia. Jeśli sposób pracy zmieniał się w ostatnim półroczu dwa razy, budowa systemu utrwali stan tymczasowy. Najpierw ustabilizuj proces, choćby na arkuszu, potem go zamawiaj.

Nie ma właściciela procesu po Twojej stronie. System dedykowany wymaga jednej osoby z firmy, która zna proces, ma czas i mandat do podejmowania decyzji. Bez niej projekt zamienia się w serię sprzecznych oczekiwań, a wykonawca zaczyna zgadywać. To jedno z głównych ryzyk takich wdrożeń i w naszej praktyce groźniejsze niż problemy techniczne.

Potrzeba jest standardowa. Księgowość, kadry, obsługa poczty, podstawowy magazyn. Rynek rozwiązał te procesy dawno i taniej. Budowanie własnej księgowości to płacenie za wynalezienie koła, do tego z obowiązkiem nadążania za zmianami w przepisach.

Brakuje budżetu na utrzymanie. System dedykowany bez opieki starzeje się szybciej niż gotowiec, bo nikt nie aktualizuje go za Ciebie. Jeśli budżet wystarcza wyłącznie na budowę, lepiej zostać przy abonamencie, który zawiera aktualizacje w cenie.

Jeśli chcesz sprawdzić, po której stronie wypada Twój przypadek, opisz nam proces przez formularz wyceny. Zdarza nam się odradzać budowę, jeśli rachunek wychodzi na korzyść gotowego produktu.

Najczęstsze pytania o oprogramowanie na zamówienie

Poniżej pytania, które wracają najczęściej przy porównywaniu gotowego systemu z dedykowanym.

Czy dedykowany system to zawsze drożej?

Nie, choć prawie zawsze drożej na starcie. Gotowy produkt wygrywa kosztem wejścia oraz czasem uruchomienia, natomiast system dedykowany nie ma opłaty za każdą kolejną osobę w firmie. Dlatego w horyzoncie kilku lat i przy rosnącym zespole rachunek potrafi się odwrócić. Kluczowe jest liczenie pełnego kosztu obu dróg, razem z godzinami, które zespół traci na obchodzenie ograniczeń produktu.

Do kogo należą prawa autorskie i kod źródłowy?

Do tego, co zapisano w umowie, dlatego to jeden z najważniejszych punktów do sprawdzenia przed podpisaniem. Przy oprogramowaniu na zamówienie często umawia się przeniesienie majątkowych praw autorskich na zamawiającego z chwilą odbioru oraz zapłaty. Nie dzieje się to jednak automatycznie: taka umowa wymaga formy pisemnej oraz wyraźnego wskazania pól eksploatacji, czyli sposobów korzystania z programu. Zadbaj też o dostęp do repozytorium kodu od pierwszego dnia projektu, choć sam dostęp to jeszcze nie to samo co nabycie praw. Pamiętaj również, że biblioteki zewnętrzne, z których zbudowany jest każdy współczesny system, pozostają na własnych licencjach. Powyższe to praktyka rynkowa, a nie porada prawna, dlatego zapisy umowy warto potwierdzić z prawnikiem.

Co dzieje się z systemem po odbiorze?

Zaczyna się utrzymanie i warto zaplanować je razem z budową. Obejmuje aktualizacje składników, monitoring, poprawki błędów oraz reakcję na zgłoszenia. Orientacyjnie to 10-20 procent wartości projektu rocznie. Możesz zlecić to wykonawcy, przejąć własnym zespołem albo podzielić się zadaniami. Ważne, żeby decyzja zapadła przed odbiorem, a nie w dniu pierwszej awarii.

Czy dedykowany system musi zastąpić wszystkie moje obecne narzędzia?

Nie i zwykle nie powinien. Najczęstszy sensowny wariant to system dedykowany obsługujący jeden proces, który stanowi Twoją przewagę, spięty integracjami z gotowymi produktami tam, gdzie potrzeba jest standardowa. Księgowość, poczta czy kadry zostają na abonamencie, bo rynek rozwiązał je taniej. Taka hybryda bywa tańsza i bezpieczniejsza niż budowa jednego wielkiego systemu do wszystkiego.

Podsumowanie

Oprogramowanie na zamówienie opłaca się wtedy, gdy pełny koszt gotowego systemu przestaje być niższy od kosztu zbudowania własnego. Do tego rachunku wchodzą trzy rzeczy po stronie gotowca: abonament pomnożony przez liczbę użytkowników i lat, koszt wdrożenia oraz godziny, które zespół przepala na obchodzenie ograniczeń produktu. Po stronie systemu dedykowanego są dwie: koszt budowy oraz utrzymanie rzędu 10-20 procent wartości rocznie. Próg przełamuje się wraz z liczbą użytkowników, ponieważ system własny nie ma opłaty za kolejną osobę w firmie. Zanim jednak zamówisz cokolwiek, sprawdź prototyp na platformie no-code oraz upewnij się, że masz stabilny proces i jego właściciela po swojej stronie. Bez tych dwóch rzeczy nawet dobrze policzona decyzja skończy się źle.

Jeśli chcesz policzyć ten rachunek dla swojej firmy, zostaw brief w formularzu wyceny. Po analizie procesu wracamy z porównaniem obu dróg oraz wyceną budowy.