Firma nie potrzebuje systemu dedykowanego dlatego, że obecny interfejs wygląda staro. Potrzebuje go wtedy, gdy pracownicy codziennie przepisują te same dane, zamówienia przechodzą przez kilka arkuszy, a ważne decyzje zależą od pliku przechowywanego na komputerze jednej osoby. Oprogramowanie szyte na miarę ma sens, gdy usuwa konkretny koszt operacyjny albo pozwala obsłużyć proces, którego gotowe platformy nie potrafią odwzorować bez serii ręcznych obejść.
Nie jest to jednak automatycznie lepsza alternatywa dla systemu abonamentowego. Faktury, standardowy CRM, prowadzenie newslettera, ewidencję czasu czy prosty magazyn zwykle taniej i szybciej obsłuży gotowe rozwiązanie. Budowanie własnej kopii popularnego SaaS-u za kilkaset tysięcy złotych rzadko ma ekonomiczne uzasadnienie.
Dedykowana aplikacja zaczyna wygrywać tam, gdzie firma ma własne reguły sprzedaży, produkcji, logistyki lub obsługi klienta. Przykładowo dystrybutor nie potrzebuje kolejnej bazy kontaktów. Potrzebuje systemu, który przed potwierdzeniem zamówienia sprawdzi stany w kilku magazynach, rezerwacje handlowców, limit kredytowy klienta, termin dostawy od producenta i możliwość skompletowania przesyłki. To właśnie taki proces — trudny do odtworzenia w gotowym programie — uzasadnia inwestycję.
Kiedy własny system jest inwestycją, a kiedy drogim kaprysem
Najczęstszy błąd pojawia się jeszcze przed wyborem wykonawcy. Firma stwierdza, że „obecne narzędzia ograniczają rozwój”, ale nie potrafi wskazać, ile czasu, pieniędzy lub zamówień traci z tego powodu. Bez takiej informacji projekt łatwo zmienia się w kosztowną listę życzeń.
Przed zamówieniem aplikacji trzeba przeanalizować jeden pełny przebieg procesu — od momentu powstania danych do końcowej decyzji lub wykonania usługi. W praktyce warto zmierzyć:
- ile razy w miesiącu wykonywana jest dana operacja,
- ile minut zajmuje jej ręczna obsługa,
- ilu pracowników bierze w niej udział,
- jak często pojawiają się pomyłki i reklamacje,
- ile systemów oraz arkuszy uczestniczy w obiegu danych,
- ile kosztuje opóźnienie, błąd albo niewykonane zamówienie.
Jeżeli pięć osób po 40 godzin miesięcznie przepisuje dane między programami, firma zużywa na tę czynność 200 roboczogodzin miesięcznie. Przy pełnym koszcie pracy na poziomie 70–100 zł za godzinę oznacza to 14–20 tys. zł miesięcznie, czyli 168–240 tys. zł rocznie. W takim przypadku integracja lub dedykowany moduł za 100–200 tys. zł może mieć sens, o ile faktycznie usuwa większość tej pracy.
Sygnałami uzasadniającymi budowę własnego rozwiązania są przede wszystkim:
- regularne kopiowanie danych między CRM-em, ERP-em, magazynem i arkuszami,
- ręczne sprawdzanie warunków, które można zapisać jako reguły biznesowe,
- brak wiarygodnego raportu bez kilkugodzinnego składania danych,
- używanie kilku płatnych narzędzi o częściowo powtarzających się funkcjach,
- konieczność obsługi dużej liczby wyjątków,
- brak API lub możliwości konfiguracji w obecnym systemie,
- proces stanowiący faktyczne źródło przewagi konkurencyjnej firmy.
Trzeba przy tym oddzielić problem technologiczny od organizacyjnego. Program nie naprawi procesu, w którym nikt nie odpowiada za jakość danych, każdy dział inaczej definiuje status „zrealizowane”, a kluczowe decyzje są podejmowane telefonicznie i nigdzie nie rejestrowane. Automatyzacja chaosu daje szybszy chaos.
Przed budową warto sprawdzić trzy tańsze warianty: konfigurację obecnego narzędzia, połączenie systemów przez API oraz automatyzację typu low-code lub no-code, np. przy użyciu Microsoft Power Automate, Make albo n8n. Dopiero gdy te opcje nie obsługują skali, bezpieczeństwa lub złożoności procesu, oprogramowanie dedykowane staje się rozwiązaniem pierwszego wyboru.
Ile kosztuje projekt i co naprawdę powinno znaleźć się w wycenie
Cena zależy przede wszystkim od liczby ról użytkowników, integracji, ekranów, reguł biznesowych, wymagań bezpieczeństwa oraz jakości danych przeznaczonych do migracji. Sama liczba funkcji mówi niewiele. Jeden ekran obsługujący skomplikowane wyliczenia może wymagać więcej pracy niż dziesięć prostych formularzy.
Na polskim rynku stawki software house’ów najczęściej mieszczą się w granicach 150–400 zł netto za godzinę, zależnie od kompetencji zespołu, technologii i modelu współpracy. Zagraniczne zestawienia dla polskich wykonawców wskazują zwykle około 45–70 dolarów za godzinę. Nie oznacza to jednak, że najtańszy zespół przygotuje najtańszy system. Niska stawka połączona ze słabą analizą, dużą liczbą poprawek i brakiem testów potrafi podwoić całkowity budżet.
Orientacyjne widełki dla projektów realizowanych w Polsce wyglądają następująco:
- analiza przedwdrożeniowa i prototyp: około 15–50 tys. zł netto,
- prosta aplikacja wewnętrzna: około 50–120 tys. zł netto,
- produkcyjne MVP z panelem administracyjnym i kilkoma integracjami: około 100–300 tys. zł netto,
- rozbudowany system obsługujący sprzedaż, klientów, dokumenty i raportowanie: około 300–800 tys. zł netto,
- platforma wielomodułowa, aplikacja mobilna lub system o wysokich wymaganiach bezpieczeństwa: od 600 tys. zł do ponad 1,5 mln zł netto.
Pierwsza użyteczna wersja prostszej aplikacji powstaje zwykle w ciągu 3–5 miesięcy. System z migracją danych, kilkoma rolami, rozbudowanymi integracjami i testami bezpieczeństwa wymaga zazwyczaj 6–12 miesięcy. Projekty obejmujące wiele oddziałów, aplikacje mobilne, rozliczenia finansowe albo zaawansowaną logistykę nierzadko trwają 12–24 miesiące.
Rzetelna wycena nie może obejmować wyłącznie programowania. Powinna uwzględniać:
- analizę biznesową i techniczną,
- projekt UX oraz interfejsu,
- architekturę systemu,
- development części serwerowej i interfejsu,
- testy funkcjonalne, integracyjne i bezpieczeństwa,
- konfigurację infrastruktury,
- migrację oraz czyszczenie danych,
- dokumentację techniczną i użytkową,
- szkolenia,
- zarządzanie projektem,
- wdrożenie i stabilizację systemu.
Dużym problemem są integracje wyceniane na podstawie deklaracji, a nie dokumentacji. Informacja, że „ERP ma API”, nie wystarcza. Trzeba sprawdzić, czy API udostępnia potrzebne dane, jakie ma limity, jak wygląda uwierzytelnianie, czy środowisko testowe jest dostępne i kto odpowiada za błędy po stronie zewnętrznego dostawcy. Integracja ze starym systemem magazynowym potrafi kosztować więcej niż wykonanie całego nowego panelu.
Podobnie wygląda migracja. Stare bazy zawierają duplikaty, niepełne adresy, różne formaty kodów produktów i rekordy, których nikt nie używa od dekady. Przeniesienie danych „jeden do jednego” tylko przenosi bałagan do nowej aplikacji. W budżecie trzeba przewidzieć czas na profilowanie danych, czyszczenie, próbne migracje i uzgodnienie zasad odrzucania błędnych rekordów.
Po uruchomieniu systemu dochodzi koszt utrzymania. Przy mniejszych aplikacjach trzeba zakładać co najmniej 2–8 tys. zł netto miesięcznie, a przy systemach obsługujących krytyczne procesy — 10–40 tys. zł lub więcej. Koszt obejmuje infrastrukturę, monitoring, kopie zapasowe, aktualizacje bibliotek, usuwanie błędów i niewielkie zmiany. Stały rozwój nowych funkcji rozlicza się zwykle osobno.
Jak zbudować system, którego firma nie będzie chciała wyrzucić po dwóch latach
Najważniejszą decyzją nie jest wybór języka programowania. Jest nią ograniczenie zakresu pierwszej wersji. Firma, która od razu zamawia CRM, ERP, portal klienta, aplikację mobilną, hurtownię danych i moduł AI, zwykle kończy z długim projektem, rosnącym budżetem oraz zespołem nadal pracującym w Excelu.
Pierwsza wersja powinna obejmować jeden proces mający największy wpływ na przychód, koszt lub jakość obsługi. Może to być automatyczne ofertowanie, przyjmowanie zamówień, planowanie produkcji, obsługa reklamacji albo raportowanie rentowności. Funkcja powinna być wystarczająco kompletna, aby dało się na niej normalnie pracować, ale pozbawiona dodatków, które nie są konieczne do osiągnięcia mierzalnego efektu.
Dobry backlog dzieli się na trzy grupy:
- konieczne na start — bez nich proces nie działa albo system nie spełnia wymagań prawnych i bezpieczeństwa,
- ważne po uruchomieniu — zwiększają wygodę lub automatyzują kolejne etapy,
- do rozważenia później — raporty specjalne, dodatkowe widoki, aplikacja mobilna czy zaawansowane funkcje AI.
W praktyce najwięcej kłopotów powodują nie efektowne funkcje, lecz zaniedbane podstawy: uprawnienia, logowanie zdarzeń, kopie zapasowe, procedura odtwarzania danych i monitoring integracji. System może działać bez animowanego dashboardu. Nie powinien działać bez informacji, kto zmienił cenę, usunął dokument albo zatwierdził nietypową transakcję.
Szczególnie dokładnie trzeba ustalić:
- własność kodu i repozytorium — klient powinien mieć dostęp do aktualnego kodu oraz historii zmian,
- prawa autorskie — umowa musi określać pola eksploatacji i moment przeniesienia praw,
- dokumentację — minimum to opis architektury, uruchomienia, integracji, bazy danych i procedury wdrożenia,
- SLA — czas reakcji i usunięcia awarii powinien zależeć od jej wpływu na działalność,
- zasady odbioru — funkcje muszą być sprawdzane na konkretnych scenariuszach biznesowych,
- procedurę wyjścia — trzeba ustalić, jak kod, dane i infrastruktura zostaną przekazane innemu zespołowi,
- bezpieczeństwo — obejmujące role, szyfrowanie, dzienniki zdarzeń, testy, kopie zapasowe i zarządzanie podatnościami.
Niebezpieczna jest sytuacja, w której całą wiedzę o aplikacji ma jeden programista. Jego odejście może zatrzymać rozwój na tygodnie. Minimalnym zabezpieczeniem są przeglądy kodu, aktualna dokumentacja, automatyczne wdrożenia i co najmniej dwie osoby znające krytyczne elementy systemu.
Kolejne ryzyko to bezrefleksyjne dodawanie AI. Model językowy może klasyfikować zgłoszenia, tworzyć szkice odpowiedzi albo wydobywać informacje z dokumentów, ale nie powinien samodzielnie podejmować decyzji finansowych lub kadrowych bez kontroli, rejestrowania działania i oceny ryzyka. System trzeba zaprojektować tak, aby można było ustalić, na jakich danych pracował model, kto zatwierdził wynik i co stanie się po błędnej odpowiedzi.
Najbardziej irytujący problem ujawnia się jednak po wdrożeniu: pracownicy wracają do starych arkuszy, ponieważ nowa aplikacja wymaga zbyt wielu kliknięć albo nie obsługuje codziennych wyjątków. Dlatego testów akceptacyjnych nie mogą prowadzić wyłącznie menedżerowie i wykonawca. System muszą sprawdzić osoby faktycznie realizujące zamówienia, wystawiające dokumenty, planujące produkcję i obsługujące reklamacje. Powinny przejść pełne scenariusze, również te nietypowe i błędne.
FAQ
Czy oprogramowanie dedykowane zawsze kosztuje więcej niż gotowy system?
Na początku zazwyczaj tak. Może być tańsze w kilkuletniej perspektywie, gdy zastępuje kilka abonamentów, usuwa setki godzin ręcznej pracy albo pozwala obsłużyć większą liczbę klientów bez proporcjonalnego zatrudniania kolejnych osób. Porównywać trzeba co najmniej trzyletni całkowity koszt, a nie samą cenę wdrożenia.
Czy kod powinien należeć do zamawiającej firmy?
Przy systemie krytycznym dla działalności — tak. Firma powinna mieć prawa pozwalające rozwijać aplikację z innym wykonawcą, dostęp do repozytorium, dokumentacji i infrastruktury. Sam zapis „klient otrzymuje system” nie daje takiej ochrony.
Lepiej wybrać rozliczenie fixed price czy time and material?
Fixed price sprawdza się przy małym, dobrze opisanym i stabilnym zakresie. Time and material jest bezpieczniejszy przy projektach rozwijanych etapami, integracjach i wymaganiach, które będą doprecyzowywane po testach. Sztywna cena przy niejasnym zakresie zwykle kończy się wysokim marginesem bezpieczeństwa albo konfliktem o każdą zmianę.
Ile trwa przygotowanie MVP?
Najczęściej 3–6 miesięcy. Krótszy termin jest realny przy prostym procesie i niewielkiej liczbie integracji. Jeżeli projekt wymaga migracji dużej bazy, aplikacji mobilnej, wielu poziomów uprawnień lub połączenia ze starymi systemami, pół roku może wystarczyć jedynie na pierwszy moduł.
Czy można rozwijać system z innym software house’em?
Tak, ale tylko wtedy, gdy kod jest dostępny, dokumentacja aktualna, infrastruktura nie zależy od prywatnych kont wykonawcy, a popularność użytej technologii pozwala znaleźć kolejny zespół. Aplikacja oparta na egzotycznym frameworku i wiedzy jednej osoby skutecznie przywiązuje klienta do dostawcy.
Od czego zacząć przed wysłaniem zapytania o wycenę?
Od jednego procesu. Należy zapisać jego etapy, uczestników, wykorzystywane systemy, liczbę operacji miesięcznie, czas ręcznej pracy, koszt błędów i oczekiwany wynik po wdrożeniu. Jeżeli firma nie umie tego opisać, pierwszym zakupem nie powinien być development, lecz analiza procesu.
Pierwszy błąd do usunięcia to zamawianie „systemu dla całej firmy”. Najpierw wybierz proces, który generuje największą stratę czasu albo najczęściej blokuje sprzedaż. Policz jego roczny koszt, sprawdź możliwość konfiguracji lub integracji gotowych narzędzi, a dopiero potem zleć analizę pierwszego modułu. Własne oprogramowanie opłaca się wtedy, gdy usuwa policzalny problem — nie wtedy, gdy jedynie dobrze wygląda na prezentacji.
