Własny system czy gotowy program

Kiedy abonament za gotowe narzędzie jest najtańszą drogą, a kiedy przepłacasz za funkcje, których nie używasz. Praktyczne kryteria, koszty jednego i drugiego rozwiązania oraz pytania, które warto zadać, zanim cokolwiek zamówisz.

  • Aktualizacja: 17 sierpnia 2026
  • Łukasz Gąsiecki
  • 8 zagadnień

Kiedy gotowy program wystarczy

Zacznę od strony, na której zarabiam mniej, bo to uczciwsze. W większości przypadków gotowe oprogramowanie jest lepszym wyborem i odradzanie go byłoby naciąganiem.

Gotowy program ma trzy przewagi, których nie da się przebić: działa od jutra, kosztuje kilkadziesiąt złotych miesięcznie zamiast kilkudziesięciu tysięcy jednorazowo i był już przetestowany przez tysiące firm, które znalazły w nim błędy przed Tobą. Za te pieniądze nikt nie napisze Ci niczego lepszego.

  • Twój proces wygląda tak samo jak w setkach innych firm z branży
  • Chodzi o obszar uregulowany przepisami – księgowość, kadry, fakturowanie
  • Potrzebujesz tego na już, a nie za trzy miesiące
  • Nie masz jeszcze pewności, jak dokładnie ma wyglądać docelowy proces
  • Gotowe rozwiązanie pokrywa osiemdziesiąt procent potrzeb, a reszta to wygoda

Zasada praktyczna: jeśli potrafisz wskazać gotowy program, który robi to, czego potrzebujesz, i nie musisz przy tym mówić „prawie” ani „tylko trzeba by” – kup go. Własne narzędzie zaczyna mieć sens dopiero wtedy, gdy takiej odpowiedzi nie ma.

Warto też pamiętać, że wybór nie jest zerojedynkowy. Częstym rozwiązaniem jest zostawienie księgowości i magazynu w gotowym programie, a zbudowanie własnego narzędzia tylko do tego jednego procesu, który jest w Twojej firmie nietypowy – i połączenie obu.

Sygnały, że czas na własne narzędzie

Rzadko przychodzi jeden moment, w którym wszystko staje się jasne. Zwykle przez rok narastają drobne objawy, które osobno wyglądają na normalne uciążliwości.

  • Płacisz abonament za pakiet, z którego używasz trzech funkcji
  • Dopłata za brakujący moduł kosztuje więcej niż napisanie samego modułu
  • Kilka osób prowadzi ten sam arkusz i regularnie nadpisuje sobie zmiany
  • Przepisujesz dane z jednego programu do drugiego ręcznie
  • Najważniejsza wiedza o kliencie siedzi w telefonie jednej osoby
  • Twój proces jest przewagą nad konkurencją, a program zmusza Cię do jego spłaszczenia
  • Co miesiąc powtarzasz tę samą godzinną robotę, bo „tak już jest”

Najmocniejszy z tych sygnałów jest przedostatni. Jeśli sposób, w jaki obsługujesz klienta, jest powodem, dla którego wybiera Ciebie, a gotowy program każe Ci go uprościć, to nie jest oszczędność – to oddawanie własnej przewagi za abonament.

Sygnał, który myli najczęściej

Zniechęcenie do obecnego programu bywa mylone z potrzebą własnego. Zanim zamówisz cokolwiek, sprawdź, czy problemem jest narzędzie, czy sposób, w jaki zostało wdrożone. Bardzo często wystarczy jednodniowa porządna konfiguracja i szkolenie zespołu, żeby narzekanie ucichło. To kosztuje ułamek tego, co nowy system.

Ile to naprawdę kosztuje

Porównanie „99 zł miesięcznie kontra 30 000 zł jednorazowo” jest bez sensu, bo zestawia dwie różne rzeczy. Policzmy to uczciwie, w perspektywie pięciu lat.

Po stronie gotowego programu koszt to abonament pomnożony przez liczbę stanowisk i przez sześćdziesiąt miesięcy. Do tego dochodzą podwyżki, które przy oprogramowaniu w modelu abonamentowym są regułą, dopłaty za moduły oraz czas ludzi tracony na obejścia – te ostatnie rzadko ktoś wycenia, choć bywają największą pozycją.

Po stronie własnego narzędzia koszt to budowa plus utrzymanie: serwer, kopie zapasowe, aktualizacje bezpieczeństwa i drobne poprawki. Utrzymanie zwykle mieści się w kilku procentach kosztu budowy rocznie. Do rachunku trzeba też uczciwie dopisać ryzyko, że pierwsza wersja nie trafi w potrzebę i będzie wymagała przeróbek.

Punkt zwrotny wypada zwykle między trzecim a piątym rokiem i przesuwa się w stronę własnego narzędzia wraz z liczbą stanowisk. Przy trzech osobach gotowy program prawie zawsze wygrywa. Przy dwudziestu rachunek bywa odwrotny.

Jest jeszcze koszt, którego nie widać w żadnej z tych kolumn: co się stanie, jeśli dostawca gotowego programu podniesie cenę o połowę, zamknie usługę albo zmieni ją w coś, czego nie chcesz. Przy własnym narzędziu ten scenariusz nie istnieje, bo to Ty decydujesz o jego losie. Przy abonamencie jest realny i widziałem, jak firmy przenosiły dane w trybie awaryjnym.

Arkusz kalkulacyjny jako system

Najczęstszym systemem w małej firmie jest arkusz i wcale nie jest to powód do wstydu. Arkusz jest znakomity – do momentu, w którym przestaje być.

Zaletą arkusza jest to, że każdy potrafi go zmienić bez pytania kogokolwiek o zgodę. To samo jest jego największą wadą, bo każdy potrafi go zepsuć bez pytania kogokolwiek o zgodę. Dopóki pracuje na nim jedna osoba, przewaga wygrywa. Przy trzech osobach zaczyna przegrywać.

Objawy, że arkusz przestał wystarczać

  • Istnieje więcej niż jedna wersja pliku i ktoś musi je scalać
  • W nazwie pliku pojawiło się słowo „ostateczny” albo data
  • Ktoś przypadkiem usunął formułę i nikt tego nie zauważył przez tydzień
  • Wpisanie jednej informacji wymaga otwarcia trzech zakładek
  • Nie da się sprawdzić, kto i kiedy coś zmienił
  • Dane, które nie powinny być dostępne dla wszystkich, są dostępne dla wszystkich

Ostatni punkt ma wymiar prawny. Jeśli w arkuszu leżą dane osobowe klientów albo pracowników, a plik krąży po skrzynkach mailowych i pendrive’ach, trudno mówić o spełnieniu wymogów RODO dotyczących kontroli dostępu. To bywa mocniejszym argumentem za systemem niż wygoda.

Dobra wiadomość: arkusz, który wymknął się spod kontroli, jest najlepszym możliwym punktem wyjścia do budowy systemu. Zawiera gotową listę potrzebnych pól, realny sposób pracy i historię decyzji. Przyjście na pierwszą rozmowę z takim plikiem skraca etap analizy o połowę.

Jak opisać, czego potrzebujesz

Nie musisz umieć pisać specyfikacji i nikt rozsądny tego od Ciebie nie oczekuje. Musisz natomiast umieć opisać swoją pracę, a to potrafisz lepiej niż ktokolwiek inny.

Najskuteczniejszy sposób to opowiedzenie jednego konkretnego przypadku od początku do końca: przychodzi zapytanie, co się dzieje dalej, kto co robi, gdzie zapisuje, komu przekazuje, co idzie nie tak. Godzina takiej opowieści daje więcej niż dziesięć stron wymagań, bo pokazuje wyjątki – a to w wyjątkach siedzi cała trudność.

Co warto przynieść na pierwszą rozmowę

  • Arkusz albo zeszyt, w którym dziś prowadzisz tę robotę
  • Przykładowy dokument, który powstaje na końcu procesu
  • Listę osób, które będą z narzędzia korzystać, i tego, co każda ma widzieć
  • Trzy rzeczy, które irytują Cię najbardziej
  • Informację, z jakimi programami to musi się dogadać

Osobno warto nazwać rzecz, o której łatwo zapomnieć: po czym poznasz, że narzędzie działa. „Wystawienie wyceny zajmuje pięć minut zamiast czterdziestu” to kryterium, które da się sprawdzić. „Ma być wygodniej” nie jest kryterium i nie da się na jego podstawie niczego odebrać ani zareklamować.

Czego naprawdę warto się bać

Ryzykiem przy zamawianiu oprogramowania nie jest to, że wykonawca napisze zły kod. Ryzykiem jest to, że skończysz w miejscu, z którego nie da się wyjść.

  • Umowa nie przenosi na Ciebie praw do kodu, więc nie możesz nikomu zlecić poprawek
  • System stoi na autorskim rozwiązaniu, którego nikt inny nie rozumie
  • Nie istnieje żadna dokumentacja poza pamięcią jednej osoby
  • Dane trzymane są na koncie wykonawcy, a nie na Twoim
  • Wycena obejmuje całość, więc nie da się zatrzymać w połowie
  • Wykonawca nie chce rozmawiać o tym, co się stanie, gdy przestanie być dostępny

Każdy z tych punktów da się usunąć jednym zdaniem w umowie, ale trzeba o to zapytać przed podpisaniem, bo potem nie ma już dźwigni. Najważniejsze są dwa pierwsze – reszta jest uciążliwa, one bywają nie do naprawienia bez pisania systemu od nowa.

Przy jednoosobowym wykonawcy pytanie o jego dostępność w przyszłości nie jest niegrzeczne, tylko rozsądne. Dobra odpowiedź nie brzmi „nic mi nie będzie”, tylko: standardowe technologie, kod i dokumentacja u Ciebie, dane na Twoim koncie. Wtedy odpowiedź przestaje zależeć od zdrowia jednej osoby.

Dlaczego etapy, a nie jedno duże zamówienie

Projekty informatyczne rzadko przekraczają budżet dlatego, że ktoś źle policzył. Przekraczają go, bo na początku nikt nie wiedział dokładnie, co ma powstać – łącznie z zamawiającym.

To nie jest niczyja wina. Dopiero widząc pierwszą działającą wersję, człowiek orientuje się, czego naprawdę potrzebował. Dlatego rozsądniejsze jest zamawianie oprogramowania kawałkami, z których każdy da się uruchomić i ocenić, niż podpisywanie jednej wielkiej umowy na coś, co istnieje wyłącznie w wyobraźni obu stron.

  1. Analiza – spisanie zakresu i wycena budowy. Kończy się dokumentem, który powinien być Twój bez żadnych warunków.
  2. Pierwszy etap – ta część, która przyniesie najwięcej od razu. Uruchomiona i używana, nie pokazana na slajdach.
  3. Kolejne etapy – dokładane wtedy, gdy poprzedni potwierdził, że kierunek jest dobry.
  4. Utrzymanie – serwer, kopie zapasowe, aktualizacje i poprawki po wdrożeniu.

Taki podział daje Ci coś, czego nie da żadna umowa o dzieło na całość: możliwość zatrzymania się. Zdarza się, że po pierwszym etapie okazuje się, iż reszta nie jest już potrzebna, bo najgorszy problem zniknął. To nie jest porażka projektu, tylko najtańszy możliwy sposób jego zakończenia.

Jak wygląda praca nad systemem u mnie, etap po etapie

Pytania do wykonawcy

Osiem pytań, po których odpowiedziach poznasz, z kim rozmawiasz. Żadne z nich nie wymaga wiedzy technicznej.

  • Czy po zapłacie kod źródłowy i dokumentacja będą moje?
  • Na jakich technologiach to powstanie i ilu programistów w Polsce je zna?
  • Czy mogę zamówić tylko pierwszy etap i zdecydować później?
  • Co dokładnie dostanę na koniec pierwszego etapu?
  • Na czyim koncie będą dane i jak je stamtąd zabiorę?
  • Ile kosztuje utrzymanie po wdrożeniu i co obejmuje?
  • Kto poprawi błąd znaleziony pół roku po odbiorze i na jakich zasadach?
  • Co się stanie z projektem, jeśli przestaniesz być dostępny?

Odpowiedzi wymijające przy pierwszym, piątym i ósmym pytaniu są wystarczającym powodem, żeby porozmawiać z kimś jeszcze. Nie chodzi o to, żeby usłyszeć same wygodne rzeczy – dobry wykonawca powie Ci również, czego nie zrobi i kiedy taniej wyjdzie kupić gotowe.

Najczęstsze pytania

Pytania, które słyszę najczęściej przy pierwszej rozmowie.

Ile kosztuje zbudowanie systemu dla małej firmy?

Prosty panel albo kalkulator wyceny to zwykle od dwóch do czterech tygodni pracy. Rozbudowany system z kilkoma rodzajami użytkowników, uprawnieniami i raportami – od kilku miesięcy. Rzetelna kwota powstaje dopiero po etapie analizy, bo wcześniej byłaby zgadywaniem. Jeśli ktoś podaje cenę przed poznaniem procesu, to albo sprzedaje gotowca pod inną nazwą, albo wliczył w wycenę zapas na niewiadome – i tak zapłacisz.

Jak długo trwa wdrożenie i kiedy zobaczę pierwsze efekty?

Przy pracy etapami pierwszą działającą wersję widać zwykle po kilku tygodniach od zakończenia analizy, a nie po zakończeniu całego projektu. To jest właśnie sens tego podziału: sprawdzasz kierunek, zanim wydasz całość budżetu.

Czy da się połączyć nowy system z programem księgowym, którego używam?

Zwykle tak, jeśli ten program udostępnia interfejs do wymiany danych – większość popularnych rozwiązań księgowych, magazynowych i pocztowych to robi. To pytanie warto zadać na samym początku, bo jest jednym z niewielu miejsc, w których odpowiedź „nie da się” zmienia sens całego projektu.

Czy własny system trzeba potem utrzymywać?

Tak, jak każde oprogramowanie. Utrzymanie obejmuje serwer, kopie zapasowe, aktualizacje bezpieczeństwa i drobne poprawki, a kosztuje zwykle kilka procent wartości budowy rocznie. Program, którego nikt nie aktualizuje, po dwóch latach staje się ryzykiem, a nie oszczędnością.

Co z danymi osobowymi w takim systemie?

Administratorem danych pozostajesz Ty, a wykonawca przetwarza je na Twoje polecenie – dlatego przed przekazaniem dostępu podpisuje się umowę powierzenia przetwarzania. Poza tym liczy się rozdzielenie uprawnień, szyfrowanie połączenia, kopie zapasowe i lokalizacja serwera w Europejskim Obszarze Gospodarczym.

Czy mogę zacząć od arkusza i przejść na system później?

To najrozsądniejsza kolejność. Arkusz jest tanim sposobem sprawdzenia, jak proces ma wyglądać, zanim ktokolwiek zacznie go programować. Kiedy okaże się za ciasny, staje się gotowym materiałem wyjściowym dla systemu – a nie zmarnowaną pracą.

Nie wiesz, po której stronie jest Twój przypadek?

Opowiedz, jak dziś wygląda ta robota. Powiem, czy widzę gotowy program, który to załatwi, czy raczej warto zbudować coś swojego – i ile mniej więcej by to trwało. Jeśli tańsze będzie kupienie gotowca, usłyszysz to ode mnie.