Prawie w każdej firmie, która do nas trafia, istnieje ten sam plik. Arkusz, który ktoś prowadzi „na boku”, bo dwa systemy nie chcą ze sobą rozmawiać. Wszyscy o nim wiedzą, nikt go nie lubi, a jego autor stał się przypadkiem najważniejszą osobą w procesie — bo tylko on wie, dlaczego w kolumnie H jest ta jedna dziwna formuła.
Ten plik to zwykle pierwszy sygnał, że gotowe narzędzie przestało wystarczać. Sam sygnał niczego jednak nie rozstrzyga. Irytacja to za mało, żeby wydać sto tysięcy złotych, a „u konkurencji mają własny system” to jeszcze gorszy powód.
Ten przewodnik daje rachunek, który przeprowadzisz na własnych liczbach w kilkanaście minut — plus publikowane widełki kosztów i terminów, żebyś wiedział, czego oczekiwać, zanim zaczniesz rozmawiać z wykonawcami.
Najważniejsze w skrócie
Dedykowany system opłaca się wtedy, gdy roczny koszt licencji, pracy na obejściach i procesów, których gotowe narzędzie nie obsługuje, zaczyna przewyższać koszt zbudowania i utrzymania własnego rozwiązania. To rachunek, nie kwestia gustu.
Publikowane widełki na polskim rynku sięgają od 15–35 tys. zł za prostą aplikację webową do 80–200 tys. zł za rozbudowaną platformę B2B (WaspIT, 2026).
Utrzymanie to osobna, powtarzalna pozycja w budżecie — w publikowanych przykładach rzędu 15% wartości wdrożenia rocznie.
Zakres projektu to czynnik ryzyka, który kontrolujesz. Zacznij od jednego procesu, który boli najbardziej, i dopiero potem rozszerzaj.
Czym właściwie jest oprogramowanie na zamówienie
Oprogramowanie na zamówienie to system budowany pod konkretny proces w konkretnej firmie. W odróżnieniu od gotowego produktu kupowanego w abonamencie to nie Ty dopasowujesz się do narzędzia, tylko narzędzie do Ciebie.
Bezpośrednich danych o rynku oprogramowania dedykowanego w Polsce nie ma, ale adopcja systemów klasy ERP jest rozsądnym przybliżeniem — pokazuje, ile firm w ogóle wyszło poza arkusze kalkulacyjne. Według danych GUS w 2025 roku z systemów ERP korzystało 40,5% polskich przedsiębiorstw, o 4,5 punktu procentowego więcej niż w 2023 roku. Udział firm używających CRM spadł w tym czasie do 25% (CRN Polska, 2026).
Dla porównania w całej Unii Europejskiej specjalistycznego oprogramowania e-biznesowego (ERP, CRM lub BI) używało w 2025 roku 53% przedsiębiorstw — w Danii i Finlandii po 73% (Eurostat, maj 2026). Te same dane pokazują, że z ERP korzysta 41% małych firm w UE wobec 89% dużych.
Wniosek: jeśli rozważasz dedykowany system, nie jesteś ani pionierem, ani spóźnialskim. Jesteś w części rynku, która właśnie przechodzi z arkuszy na systemy — i to jest moment, w którym decyzja „gotowe czy własne” ma największe znaczenie. Jeśli rozpoznajesz u siebie opisany wyżej objaw, rozwijamy ten wątek w tekście o tym, dlaczego gotowe aplikacje blokują rozwój firmy.
Trzy modele, które łatwo pomylić
Różnica między nimi decyduje o koszcie, elastyczności i o tym, kto jest właścicielem rozwiązania.
Gotowy produkt (SaaS)
Abonament, to samo dla wszystkich klientów. Wdrożenie w dniach, koszt przewidywalny, elastyczność minimalna.
Gotowy produkt z konfiguracją
ERP lub CRM dostosowany polami, workflowami i integracjami. Wciąż cudzy produkt, ale nagięty do Twoich procesów. Koszt wdrożenia bywa porównywalny z małym projektem dedykowanym.
System dedykowany
Budowany pod Twój proces. Ty decydujesz o zakresie i jesteś właścicielem kodu — ale też Ty ponosisz koszt utrzymania i rozwoju.
Ile kosztuje zostawienie wszystkiego tak, jak jest
Dedykowany system opłaca się, gdy roczny koszt obecnego stanu przekracza roczny koszt własnego rozwiązania. Większość firm liczy tylko pierwszą z czterech pozycji:
Licencje — Wszystkie abonamenty za narzędzia obsługujące dany proces, łącznie z tymi, za które płaci inny dział. WaspIT wskazuje sumaryczne licencje SaaS powyżej 2–3 tys. zł miesięcznie jako moment, w którym warto zacząć liczyć alternatywę.
Praca na obejściach — Ręczne przenoszenie danych, eksporty do Excela, poprawianie tego, co się rozjechało. Policz: liczba osób × godziny tygodniowo × 52 tygodnie × koszt godziny pracy.
Procesy, których nie realizujecie — Raport, którego nikt nie robi, bo zajmuje dwa dni. Klient, którego nie obsłużyliście, bo system nie pozwalał. Najtrudniejsza do policzenia pozycja i zwykle większa niż licencje.
Ryzyko koncentracji wiedzy — Arkusz, który rozumie jedna osoba. Realne ryzyko operacyjne, nawet jeśli trudno przypisać mu kwotę.
Ile kosztuje posiadanie własnego systemu
Tu również są cztery pozycje, ale rozkładają się inaczej w czasie:
Budowa — Jednorazowo, w widełkach opisanych niżej.
Utrzymanie — Co roku. W przykładzie opisanym przez Devstock system wart 200 tys. zł generuje około 30 tys. zł kosztów utrzymania rocznie — około 15% wartości wdrożenia.
Hosting i infrastruktura — Od kilkuset złotych miesięcznie dla prostej aplikacji po istotnie wyższe kwoty przy dużym ruchu.
Rozwój — System, którego nikt nie rozwija, po dwóch latach staje się kolejnym problemem do rozwiązania.
Gdzie te dwa rachunki się przecinają
Mechanika jest zawsze ta sama: koszt gotowego rozwiązania rośnie liniowo i nigdy się nie kończy, a koszt własnego systemu ma wysoki próg wejścia i łagodniejsze nachylenie. Zobaczmy to na przykładzie. To model poglądowy, nie dane pomiarowe — podstaw własne liczby.
Założenia: licencje 4 tys. zł miesięcznie (48 tys. zł rocznie) i praca na obejściach dwóch osób po 5 godzin tygodniowo przy koszcie 115 zł za godzinę (około 60 tys. zł rocznie). Po drugiej stronie budowa za 200 tys. zł i utrzymanie 30 tys. zł rocznie — wartości zbliżone do przykładu z Devstock.
- Po roku: obecny stan 108 tys. zł, własny system 230 tys. zł
- Po dwóch latach: 216 tys. zł wobec 260 tys. zł
- Po trzech latach: 324 tys. zł wobec 290 tys. zł — własny system jest już tańszy
- Po pięciu latach: 540 tys. zł wobec 350 tys. zł
W tym modelu próg opłacalności wypada po około dwóch i pół roku. U Ciebie może to być rok albo siedem lat — dlatego liczy się rachunek, a nie przeczucie. Budowę warto rozkładać na co najmniej trzy lata użytkowania; przy krótszym horyzoncie dedykowany system rzadko wygrywa.
Jeśli wynik wychodzi na korzyść własnego systemu tylko niewielką różnicą, poczekaj. Przy wąskim marginesie ryzyko projektu zjada całą przewagę.
Trzy pytania kontrolne przed decyzją
Nawet dobry wynik rachunku nic nie znaczy, jeśli którakolwiek z odpowiedzi brzmi „nie”:
Czy proces jest stabilny? — Jeśli zmienia się co kwartał, budujesz na ruchomym gruncie.
Czy masz właściciela projektu po swojej stronie? — Nie chodzi o kompetencje techniczne, tylko o decyzyjność i czas.
Czy stać Cię na budowę i dwa lata utrzymania? — Jeśli budżet kończy się na wdrożeniu, wynik rachunku nie ma znaczenia.
Publikowane widełki kosztów
Przedziały z cennika jednego z polskich wykonawców (WaspIT, 2026), kwoty netto. To wykonawca, a nie niezależny badacz, więc traktuj je jako punkt odniesienia do rozmowy, nie wynik badania rynku:
Co zawiera wycena — a czego w niej nie ma
Dwie liczby pomagają zrozumieć strukturę każdej wyceny. Stawka godzinowa zespołu na polskim rynku to orientacyjnie 150–180 zł netto za godzinę (Devstock, 2026) — jeśli wycena jest podana w roboczogodzinach, pozwala sprawdzić, czy szacunek zakresu jest realistyczny. Utrzymanie to w publikowanych przykładach około 15% wartości wdrożenia rocznie.
Czego zwykle nie ma w podanej kwocie, a pojawi się na fakturze: hosting i infrastruktura, integracje z systemami zewnętrznymi, za które dostawca liczy osobno, migracja danych, szkolenia zespołu i zmiany zgłoszone po odbiorze. Pytanie „co dokładnie zawiera ta kwota” jest ważniejsze niż sama kwota.
Sposób rozliczenia też wpływa na cenę: przy stałej cenie wykonawca musi doliczyć bufor na ryzyko, a przy rozliczeniu za czas ryzyko jest widoczne, ale spoczywa po Twojej stronie. Oba modele porównujemy szczegółowo w tekście stała cena czy time & materials. Więcej o tym, jakie typy systemów mieszczą się w poszczególnych przedziałach, znajdziesz w artykule o aplikacjach na zamówienie dla firmy.
Chcesz sprawdzić swój próg opłacalności?
Opisz proces, który chcesz usprawnić. Pomożemy zweryfikować założenia rachunku — również wtedy, gdy wniosek będzie taki, że lepiej zostać przy gotowym narzędziu.
Ile to trwa — i dlaczego szacunki tak się różnią
Zestawmy publiczne deklaracje polskich wykonawców dla tego samego typu projektu — „prostej aplikacji”:
- MadeByRogal: 2–3 miesiące
- WaspIT: 4–8 tygodni
- Just Site: pierwsze działające MVP zwykle do miesiąca
Nawet przy porównaniu „jabłek do jabłek” rozrzut jest dwu–trzykrotny: od miesiąca do trzech dla projektu opisywanego tym samym słowem.
Łatwo tu o pomyłkę jeszcze większego kalibru. Deklarujemy też, że prosta strona może powstać nawet w 7 dni — i gdyby zestawić te 7 dni z trzema miesiącami dla aplikacji, wyszłaby różnica kilkunastokrotna. Takie porównanie nie miałoby jednak sensu: strona wizytówkowa i aplikacja z logiką biznesową to dwa różne produkty.
Najczęstszym źródłem nieporozumień przy porównywaniu ofert nie jest cena, tylko niedopowiedziane definicje. Najpierw ustal, czy mówicie o tym samym produkcie. Potem — czy termin dotyczy działającego MVP, czy wersji produkcyjnej. Dopiero wtedy liczby w ofertach mają wspólną jednostkę. Szczegółowy rozkład terminów opisujemy w tekście ile trwa stworzenie oprogramowania.
Cztery zmienne, które decydują o terminie
Za praktycznie całą różnicę między ofertami odpowiadają te same cztery czynniki:
Zakres
„Prosta aplikacja” może oznaczać jeden formularz albo panel z rolami, uprawnieniami i raportami. Dwa różne światy pod jedną nazwą.
Integracje
Każdy zewnętrzny system to dokumentacja cudzego API, limity, obsługa błędów i testy na środowisku, którego nie kontrolujesz. Jedna integracja potrafi podwoić czas prostego projektu.
Projekt graficzny
Wycena zakładająca gotowe makiety i wycena z warsztatami, UX i design systemem to różnica kilku tygodni.
Definicja „gotowe”
MVP do pokazania zarządowi powstaje szybko. Wersja produkcyjna z monitoringiem, kopiami zapasowymi i obsługą przypadków brzegowych to zupełnie inny termin.
Jak wygląda proces od rozmowy do wdrożenia
Etapy u większości wykonawców są podobne. Różnice tkwią w tym, ile Twojego czasu wymaga każdy z nich:
Analiza i strategia
Rozmowa o procesie, nie o technologii. Dobry wykonawca próbuje na tym etapie zmniejszyć zakres. Po Twojej stronie: kilka godzin i dostęp do osób, które znają proces.
Projekt i UX
Makiety i przepływy ekranów, zanim powstanie kod. Najtańszy moment na zmianę zdania. Po Twojej stronie: decyzje, nie opinie.
Budowa w iteracjach
Krótkie cykle zakończone działającą wersją. Im częściej widzisz efekt, tym wcześniej możesz zmienić kierunek, zanim koszt zmiany urośnie.
Testy i wdrożenie
Migracja danych, szkolenie zespołu, uruchomienie. Etap, na którym najczęściej wychodzą sprawy, o których nikt wcześniej nie pomyślał.
Utrzymanie i rozwój
Zaczyna się w dniu uruchomienia i trwa tak długo, jak system jest używany.
Wyniki projektów IT: dekada bez zmian
Udział projektów w każdej kategorii w latach 2020–2024 według analizy opublikowanej w PM World Journal (styczeń 2026) na podstawie danych Standish Group CHAOS. W latach 2015–2017 sukcesem kończyło się około 29% projektów:
Największe ryzyko: zbyt duży zakres na start
Te dane wymagają dwóch zastrzeżeń. Po pierwsze, metodologia raportów CHAOS bywa w literaturze kwestionowana, więc wartości warto traktować jako wskazanie kierunku, a nie precyzyjny pomiar. Po drugie, definicja sukcesu jest wąska — projekt spóźniony o miesiąc, który przyniósł firmie realną wartość, trafia do kategorii „problematycznych”.
Ważniejsza od samych odsetków jest obserwacja o skali. Autor analizy (PM World Journal, styczeń 2026), powołując się na badania Flyvbjerga i Gardnera z 2023 roku, wskazuje, że przy stabilnych średnich wskaźnikach wzrosła dotkliwość niepowodzeń dużych projektów. Rozrost zakresu w projektach IT pozostaje niewidoczny do momentu, w którym staje się finansowo dotkliwy.
Wniosek jest sprzeczny z intuicją wielu zarządów: nie zaczynaj od „systemu do wszystkiego”. Zacznij od jednego procesu, zmierz efekt i dopiero potem rozszerzaj. Mniejszy zakres to nie mniejsza ambicja, tylko mniejsza powierzchnia ryzyka. Tak powstał na przykład sklep Bezuma, którego pierwsza działająca wersja była gotowa w trzy tygodnie.
Podobnie jest z wdrożeniami AI: według analiz przywołanych w tym samym opracowaniu większość projektów opartych na generatywnej sztucznej inteligencji nie wychodzi poza fazę pilotażu. Autor wskazuje, że główne przyczyny porażek przesunęły się z samego wykonania na dopasowanie do celów biznesowych i jakość danych — co w praktyce oznacza to samo: najpierw konkretny proces i mierzalny efekt, potem technologia.
Co się dzieje po wdrożeniu
Wdrożenie nie jest ostatnią fakturą, a planowanie budżetu tak, jakby było, to najczęstszy błąd finansowy w takich projektach.
Utrzymanie — w publikowanych przykładach rzędu 15% wartości wdrożenia rocznie. Obejmuje aktualizacje zależności, łatanie podatności i reagowanie na awarie. System bez utrzymania po dwóch latach staje się ryzykiem bezpieczeństwa.
Hosting i infrastruktura — ustal na starcie, kto jest właścicielem konta u dostawcy chmury. Odpowiedź „wykonawca” bywa źródłem bardzo nieprzyjemnych rozmów przy rozstaniu.
Własność kodu — zapytaj wprost i uzyskaj odpowiedź na piśmie: czy po zapłacie kod należy do Ciebie, czy dostajesz licencję? Czy masz dostęp do repozytorium i możesz przekazać projekt innemu wykonawcy? Zapisy, które warto mieć w umowie, omawiamy w tekście umowa z software house'em — co musi się w niej znaleźć.
Rozwój — dobry system po roku wygląda inaczej niż w dniu odbioru, bo firma się zmienia. Zaplanuj na to budżet albo świadomie zdecyduj, że system ma pozostać zamrożony.
Kiedy NIE zamawiać dedykowanego oprogramowania
Są sytuacje, w których uczciwa odpowiedź brzmi „kup gotowe rozwiązanie” — i lepiej usłyszeć ją przed podpisaniem umowy niż po.
Twój proces jest standardowy
Księgowość, kadry, fakturowanie czy podstawowy CRM mają dojrzałe, tanie produkty. Budowanie własnego to płacenie dziesiątek tysięcy za odtworzenie czegoś, co kosztuje niewielki abonament.
Skala jest za mała
Jeśli proces dotyczy dwóch osób i zajmuje im godzinę tygodniowo, rachunek nigdy nie wyjdzie na Twoją korzyść. Automatyzacja w gotowym narzędziu wystarczy.
Nie masz właściciela projektu
Bez osoby, która podejmuje decyzje i ma na to czas, projekt utknie na etapie „musimy to jeszcze przemyśleć”, a koszt będzie rósł.
Proces się jeszcze nie ustabilizował
Budowanie systemu pod sposób pracy, który za pół roku będzie wyglądał inaczej, to najdroższy sposób na naukę.
Budżet starcza na budowę, ale nie na utrzymanie
System bez budżetu utrzymaniowego po dwóch latach staje się dokładnie tym problemem, który miał rozwiązać.
Podsumowanie
- Decyzja jest rachunkiem. Zsumuj licencje, godziny tracone na obejściach i koszt procesów, których nie realizujecie. Po drugiej stronie postaw budowę i utrzymanie.
- Publikowane widełki istnieją: od 15–35 tys. zł za prostą aplikację do 80–200 tys. zł za platformę B2B, plus utrzymanie rzędu 15% wartości wdrożenia rocznie.
- Rozbieżne terminy nie oznaczają, że ktoś kłamie — oznaczają, że „prosty” i „gotowy” nie zostały zdefiniowane. Poproś o rozpisanie etapów z konkretnym rezultatem każdego z nich.
- Zakres to Twoja główna dźwignia ryzyka. Jeden proces, zmierzony efekt, dopiero potem rozbudowa.
- Czasem odpowiedź brzmi „kup gotowe” — i to też jest dobra decyzja.
Jeśli planujesz aplikację mobilną, analogiczny rozkład kosztów znajdziesz w tekście ile kosztuje aplikacja mobilna.
Najczęściej zadawane pytania
Ile kosztuje oprogramowanie na zamówienie?+
Kiedy dedykowany system opłaca się bardziej niż gotowy SaaS?+
Czy po zakończeniu projektu kod należy do mnie?+
Jak długo trwa stworzenie systemu dla firmy?+
Od czego zacząć, jeśli nie wiem, czego dokładnie potrzebuję?+
Masz pomysł na projekt?
Pomożemy go zaprojektować i wdrożyć, od strategii po gotowe rozwiązanie.
