Kupić gotowy system czy zbudować własny: rachunek na trzy lata

Czyli o tym, dlaczego porównanie abonamentu z wyceną programisty prawie zawsze wychodzi na korzyść abonamentu i dlaczego to jeszcze niczego nie rozstrzyga.

Masz otwarte dwie zakładki. W pierwszej cennik systemu do obsługi zleceń: kilkadziesiąt złotych miesięcznie za osobę, darmowy okres próbny, przycisk „Zacznij teraz”. W drugiej wycena od programisty, który ma zbudować to samo, tylko pod Twój sposób pracy. Kwota z czterema zerami, termin w miesiącach, a na końcu zdanie o „utrzymaniu do ustalenia”.

Decyzja podejmuje się sama. Kto rozsądny płaci kilkadziesiąt tysięcy za coś, co można mieć jutro za cenę obiadu?

Pół roku później zespół prowadzi obok systemu arkusz, bo system nie umie policzyć wyceny tak, jak liczycie ją Wy. Ktoś codziennie przekleja dane z jednego miejsca do drugiego. Przy odnowieniu przychodzi mail o nowym cenniku. Każda z tych rzeczy z osobna jest drobna, ale żadnej nie było w porównaniu, które zrobiłeś w pierwszym tygodniu.

Brzmi znajomo? Pytanie „kupić czy zbudować” prawie zawsze rozstrzyga się na liczbach z pierwszego miesiąca, a pieniądze rozkładają się na kolejne lata. Gotowy system wygrywa na starcie i bardzo często wygrywa też na mecie. Własny wygrywa wtedy, gdy proces, który obsługuje, jest Twoją przewagą. Ten wpis jest o tym, jak to rozpoznać i jak policzyć rachunek na trzy lata, zanim podpiszesz którąkolwiek umowę.

Porównanie z pierwszego miesiąca zawsze wygrywa gotowe

Abonament i wycena programisty to dwie liczby z różnych okresów, a porównuje się je tak, jakby dotyczyły tego samego. Cena abonamentu jest podana za miesiąc i za jedną osobę, więc wygląda na drobną. Wycena budowy obejmuje całą pracę z góry, więc wygląda na ogromną. Postawione obok siebie dają odpowiedź, zanim ktokolwiek zada pytanie.

Do tego obie liczby są niepełne, tylko w przeciwne strony. Abonament nie zawiera kosztu wdrożenia, przeniesienia danych, szkolenia zespołu ani czasu, który ludzie będą tracić na obchodzenie tego, czego system nie umie. Wycena budowy nie zawiera utrzymania, czyli wszystkiego, co dzieje się z programem po dniu, w którym zaczął działać.

Fałszywa diagnoza brzmi więc: „własny system jest drogi, gotowy tani”. Trafniejsza brzmi: gotowy system jest tani na początku i drożeje z każdym rokiem, a własny jest drogi na początku i potem kosztuje mniej, niż się spodziewasz, albo dużo więcej. Który z tych scenariuszy jest Twój, zależy od rzeczy, których w żadnej ofercie nie ma.

Abonament rośnie szybciej niż Twoja firma

Ceny oprogramowania w abonamencie rosną kilka razy szybciej niż ogólna inflacja. Firma Vertice, która śledzi ceny z umów zakupowych swoich klientów, w swoim indeksie inflacji SaaS podaje dla września 2026 roku wzrost o 14,3% rok do roku, a w czerwcu rekord: 16,4%. To średnia dla całego rynku, więc u jednego dostawcy może być zero, a u innego dwadzieścia procent. Kierunek jest jednak stały od kilku lat.

Przykład z narzędzia, które ma prawie każda firma. Microsoft od lipca 2026 roku podniósł ceny planów Microsoft 365 dla firm: Business Basic z 6 do 7 dolarów za osobę miesięcznie, czyli o około 17%, Business Standard z 12,50 do 14 dolarów. Firma uzasadniła podwyżkę ponad tysiącem nowych funkcji dodanych od 2022 roku. Możesz z nich nie korzystać, a i tak za nie zapłacisz.

Druga oś wzrostu jest po Twojej stronie. Cena „za użytkownika” oznacza, że każda nowa osoba w zespole podnosi rachunek, nawet jeśli korzysta z systemu raz w tygodniu. Firma, która w trzy lata urośnie z ośmiu do dwunastu osób, płaci o połowę więcej za samą liczbę kont, zanim dostawca w ogóle ruszy cennik. Obie osie się mnożą. Dlatego abonament, który w pierwszym roku był pomijalną pozycją w kosztach, w trzecim potrafi stać się drugą po pensjach.

Własny system kosztuje głównie po wdrożeniu

Program, który zaczął działać, nie jest skończony. Zaczyna się wtedy najdłuższa część jego życia. Klasyczne badanie Lientza, Swansona i Tompkinsa z 1978 roku, przeprowadzone w kilkudziesięciu firmach, pokazało, na co idzie praca przy utrzymaniu działających aplikacji. Według zestawienia w pracy Schacha i współautorów poprawianie błędów zajmowało 17,4% tej pracy, dostosowanie do zmian otoczenia 18,2%, a 60,3% szło na ulepszenia, czyli na rzeczy, o które prosili użytkownicy.

To jest dobra i zła wiadomość jednocześnie. Zła, bo własny system nigdy nie przestaje kosztować. Dobra, bo większość tego kosztu idzie na dopasowywanie programu do firmy, która się zmienia, a gaszenie awarii to mniejsza część rachunku. W gotowym systemie za tę samą potrzebę płacisz inaczej: czekasz, aż dostawca doda funkcję, albo budujesz obejście.

Utrzymanie małego systemu firmowego składa się zwykle z kilku stałych pozycji: serwer i kopie zapasowe, aktualizacje bibliotek i frameworka, poprawki bezpieczeństwa, drobne zmiany na prośbę zespołu i człowiek, który to wszystko rozumie. Ostatnia pozycja jest najdroższa, choć w żadnej fakturze jej nie widać.

📖 Ze słownika Noraline: Dług technologiczny (technical debt) — koszt przyszłych poprawek, który powstaje, kiedy dziś wybierasz rozwiązanie szybsze zamiast lepszego. W przypadku własnego systemu to on decyduje, czy utrzymanie w trzecim roku kosztuje tyle, ile w pierwszym, czy dwa razy więcej.

Piszę to z perspektywy kogoś, kto wybrał drugą drogę. Ten blog działa na CMS-ie, który zbudowałem sam, a ten sam silnik obsługuje kilkanaście innych serwisów. Nie płacę za niego licencji. Płacę za to czasem: każda aktualizacja frameworka, każda zmiana w sposobie wysyłki maili, każda nowa funkcja to godziny, których nikt mi nie odda. Opłaca się to dlatego, że ten silnik jest częścią tego, co sprzedaję. Gdyby był tylko narzędziem do publikowania tekstów, byłby kosztownym hobby.

Ryzyko budowy siedzi w ogonie, nie w średniej

Wycena budowy jest szacunkiem, a szacunki w IT mają skłonność do rozjeżdżania się w jedną stronę. Bent Flyvbjerg i Alexander Budzier z Oxfordu przeanalizowali 1471 projektów informatycznych i opisali wyniki w Harvard Business Review w tekście „Why Your IT Project May Be Riskier Than You Think”. Średnie przekroczenie budżetu wyniosło 27%. Groźniejsze było co innego: mniej więcej jeden projekt na sześć przekraczał koszt średnio o 200%, a termin o prawie 70%.

Te liczby dotyczą głównie dużych organizacji i dużych wdrożeń. Mechanizm działa jednak tak samo przy małym systemie: najwięcej kosztuje to, czego nikt nie wpisał do wyceny, bo nikt tego nie przewidział. Integracja z programem księgowym, która „miała być prosta”. Wyjątek w procesie, o którym wie tylko jedna osoba. Zakres, który w trakcie rozrósł się o połowę.

Co z tego wynika dla rachunku? Że do wyceny budowy trzeba dopisać zapas, i to nie symboliczny. Jeśli decyzja „budujemy” przestaje mieć sens przy wycenie wyższej o jedną trzecią, to znaczy, że nie miała sensu od początku. Podobny mechanizm, w którym projekt rośnie bez końca, opisuję w tekście o długu technicznym od pierwszej wersji.

Jedno pytanie rozstrzyga więcej niż kalkulator

Zanim zaczniesz liczyć, zapytaj: czy sposób, w jaki Twoja firma wykonuje tę pracę, odróżnia ją od konkurencji? Martin Fowler, jeden z najbardziej znanych autorów piszących o wytwarzaniu oprogramowania, nazwał to w 2010 roku podziałem na systemy użytkowe i strategiczne. Użytkowe to te, które każda firma robi mniej więcej tak samo, jak płace czy księgowość. Strategiczne to te, w których Twój sposób działania jest powodem, dla którego klienci wybierają Ciebie.

Rada Fowlera dla systemów użytkowych jest bezwzględna: kup gotowy pakiet i dopasuj swój proces do niego, zamiast przerabiać pakiet pod siebie. Przerabianie gotowego systemu łączy wady obu dróg, bo płacisz abonament i jednocześnie utrzymujesz własny kod, który psuje się przy każdej aktualizacji dostawcy. Dla systemów strategicznych ta sama rada brzmi odwrotnie: zrób je tak dobrze, jak umiesz, bo tam przegrana z konkurencją kosztuje więcej niż sam program.

Gartner opisał podobny podział jako model warstw tempa. Na dole leżą systemy ewidencji, które zmieniają się rzadko i powinny być standardowe. Wyżej systemy wyróżniające, czyli te, w których firma robi coś po swojemu. Najwyżej eksperymenty. Księgowość jest w tym modelu przykładem modułu prawie zawsze standardowego.

W małej firmie ten podział da się przeprowadzić w kwadrans, z listą narzędzi przed sobą.

Jeśli nie umiesz wskazać, czym Twój proces różni się od procesu konkurenta, to masz odpowiedź.

Rachunek na trzy lata w jednej tabeli

Trzy lata to horyzont, w którym widać obie krzywe. Pierwszy rok faworyzuje gotowe, bo cała budowa ląduje w nim naraz. Od drugiego zaczynają się sumować podwyżki, nowe konta i obejścia po jednej stronie oraz utrzymanie po drugiej. Dłuższego horyzontu nie warto liczyć, bo po trzech latach zmieni się i firma, i rynek narzędzi.

Przykładowy rachunek, z liczbami wymyślonymi na potrzeby ilustracji, żeby pokazać mechanizm. Firma ma osiem osób, w trzecim roku dwanaście. Gotowy system kosztuje 120 zł za osobę miesięcznie i co roku drożeje o 12%, czyli mniej więcej tyle, ile wynosi średnia z indeksu inflacji SaaS. Nie obsługuje jednego kroku Waszego procesu, więc ktoś spędza na obejściu około dziesięciu godzin miesięcznie, liczonych po 120 zł za godzinę pracy. Własny system kosztuje 45 000 zł budowy i 1000 zł miesięcznie utrzymania, plus 8000 zł rocznie na zmiany od drugiego roku.

W pierwszym roku gotowy system jest tańszy o równowartość mniej więcej połowy budowy. W drugim różnica topnieje do kilku tysięcy. W trzecim krzywe się przecinają i własny wychodzi minimalnie taniej. Tak wygląda rachunek, który rozstrzyga się w trzecim roku, a nie w pierwszym miesiącu.

Ten wynik jest kruchy. Wystarczy, że budowa przekroczy budżet o średnie 27% z badania Flyvbjerga i Budziera, a własny system kosztuje po trzech latach ponad 103 000 zł i przegrywa. Wystarczy, że obejście zajmuje dwie godziny miesięcznie zamiast dziesięciu, a gotowy wygrywa z dużym zapasem. O wyniku decydują dwa wiersze: koszt obejścia i zapas na budowę. Cena abonamentu, o którą najczęściej toczy się dyskusja, waży tu najmniej.

Koszty, których nie ma w żadnej ofercie

Najdroższy wiersz w gotowym systemie nazywa się „obejście”, a w ofercie dostawcy nie występuje. To arkusz prowadzony obok systemu, bo raport nie liczy tego, czego potrzebujecie. To ręczne przeklejanie danych do programu księgowego. To osoba, która „wie, jak to obejść”, i bez której nikt nie wystawi wyceny. O tym, jak taki arkusz z pomocnika zamienia się w drugi system, pisałem w tekście o firmie stojącej na arkuszach.

Własny system ma swój ukryty wiersz: zależność od ludzi, którzy go znają. Jeśli kod rozumie jeden programista, a dokumentacja istnieje w jego głowie, to każdy jego urlop jest ryzykiem, a odejście może oznaczać budowę od nowa. Szczególnie dotyczy to systemów sklejonych szybko z pomocą AI, w których nikt nie wie, dlaczego coś działa. Opisałem to szerzej w tekście o tym, kto sprząta po vibe codingu.

Oba ukryte koszty mają jedną wspólną cechę: rosną po cichu. Czy wiesz, ile godzin w miesiącu Twój zespół poświęca na obchodzenie narzędzi, za które płacisz? Jeśli nie wiesz, to najważniejsza liczba do tego rachunku jest jeszcze niezmierzona.

Trzecia droga: kup rdzeń, zbuduj krawędź

Między „wszystko gotowe” a „wszystko własne” leży wariant, który w małej firmie wygrywa najczęściej. Kupujesz standardowy system do tego, co standardowe, i dobudowujesz małą, własną część tylko tam, gdzie Twój proces się od standardu odróżnia. Taką krawędzią bywa kreator wyceny, który zapisuje wynik do gotowego CRM-u, albo panel klienta czytający dane z systemu zleceń przez API. Najprostsza krawędź to automatyzacja, która przenosi dane między programami zamiast człowieka.

Ten wariant ma niższy koszt budowy, bo budujesz jedną funkcję, a nie cały system. Ma też niższe ryzyko, bo jeśli dostawca zmieni cennik albo zniknie z rynku, wymieniasz rdzeń, a Twoja część zostaje. Jest jeden warunek: gotowy system musi pozwalać wyciągać z niego dane. Jeśli nie ma API ani porządnego eksportu, krawędzi nie zbudujesz.

Prostsze krawędzie, czyli przenoszenie danych i powiadomienia, da się dziś zrobić narzędziami do automatyzacji bez pisania aplikacji. Ich też trzeba policzyć na kilka lat, bo mają własne abonamenty i własne utrzymanie. Zestawienie, ile kosztują po roku, jest w tekście o Make, n8n i Zapierze.

Jak policzyć ten rachunek u siebie

Do pierwszej wersji wystarczy arkusz, cennik dostawcy i tydzień obserwacji. Nie chodzi o dokładność co do złotówki. Chodzi o to, żeby zobaczyć, które wiersze ważą najwięcej, i sprawdzić, czy wynik przetrwa pesymistyczny scenariusz.

Krok drugi jest tym, który najczęściej się pomija, bo wymaga obserwacji zamiast kalkulacji. Pomaga w nim metoda z tekstu o tym, jak zmierzyć proces przed automatyzacją: liczysz to, co ludzie robią naprawdę, a nie to, co mówią, że robią.

Najczęstsza pomyłka przy decyzji po fakcie

Decyzja „kupić czy zbudować” nie zapada raz. Wraca przy każdym odnowieniu umowy i przy każdej dużej zmianie w firmie. I wtedy najczęściej pada zdanie: „już tyle w to włożyliśmy”. Dotyczy to obu stron. Firma, która przez trzy lata budowała obejścia wokół gotowego systemu, nie chce ich wyrzucać. Firma, która zapłaciła za własny system, nie chce przyznać, że dziś gotowy zrobiłby to samo taniej.

Oba zdania rozliczają przeszłość, a decyzja dotyczy kolejnych trzech lat. To klasyczny błąd utopionych kosztów. Pieniądze wydane na budowę albo na abonament nie wrócą bez względu na to, co postanowisz. Do rachunku wchodzi wyłącznie to, co zapłacisz od jutra.

Dlatego ten rachunek najlepiej zrobić na miesiąc przed odnowieniem umowy. Masz wtedy realne dane: ile osób korzysta, ile kosztowały podwyżki, ile godzin zjadają obejścia. Weź ten jeden system, którego używacie najdłużej, i policz dla niego tabelę z tego tekstu. Jeśli wyjdzie, że obejścia kosztują więcej niż abonament, masz pierwszego kandydata do zmiany.

Jeśli chcesz zobaczyć, jak wygląda budowa tej własnej części w praktyce, zajrzyj do opisu aplikacji i systemów, które robię dla firm.