1. Wstęp. Gotowe narzędzie to dobra odpowiedź, dopóki nie przestaje nią być
Zacznę od tezy, której nie spodziewasz się po firmie, która buduje aplikacje webowe dla firm. W większości przypadków gotowe narzędzie w abonamencie to słuszny wybór. Poczta, kalendarz, księgowość, podstawowy CRM, komunikator. Ktoś to już zrobił lepiej, taniej i z większym zespołem, niż Ty kiedykolwiek zamówisz. Jeśli prowadzisz firmę z kilkoma osobami, płacenie kilkudziesięciu złotych miesięcznie za narzędzie, które działa od pierwszego dnia, jest rozsądne.
Jestem założycielem i jedyną osobą stojącą za Ralkom. Buduję dla firm narzędzia szyte pod jeden proces, ale zdarza mi się też odradzać ich budowę, bo gotowe rozwiązanie wystarczy. Ten artykuł jest o tym, jak odróżnić jedno od drugiego. Pokażę Ci trzy sygnały, przy których abonament zaczyna kosztować więcej, niż widać na fakturze, prosty rachunek na trzy lata, który zrobisz sam, i listę sytuacji, w których własna aplikacja to zły pomysł. Także wtedy, gdy ktoś bardzo chce Ci ją sprzedać.
Kontekst jest taki, że firmy kupują coraz więcej oprogramowania w abonamencie, a to oprogramowanie drożeje szybciej niż cokolwiek innego w budżecie. Według GUS w 2025 roku z płatnych usług chmurowych korzystało 55,3 procent polskich przedsiębiorstw zatrudniających co najmniej dziesięć osób, a wśród firm małych, od dziesięciu do czterdziestu dziewięciu pracowników, 50,8 procent. Najczęściej kupowana jest poczta, potem oprogramowanie biurowe i przechowywanie plików. Mikrofirm w tych statystykach nie ma, ale z mojego doświadczenia wygląda to podobnie, tylko z mniejszą liczbą stanowisk. Jednocześnie firma Vertice, która analizuje ceny oprogramowania abonamentowego, policzyła, że we wrześniu 2026 roku ceny SaaS rosły w tempie 14,3 procent rok do roku, a w czerwcu padł rekord 16,4 procent. Przy inflacji ogólnej, która się ustabilizowała, to oznacza, że abonament z tego samego narzędzia co dwa lata jest wyraźnie droższy, nawet jeśli Twoja firma nie urosła.
2. Trzy sygnały, że gotowe narzędzie kosztuje więcej, niż widać na fakturze
Cena abonamentu to najłatwiejsza część rachunku i dlatego najczęściej jedyna, którą firmy liczą. Prawdziwy koszt siedzi gdzie indziej. Nauczyłem się rozpoznawać trzy sygnały, które pojawiają się na długo przed tym, zanim ktoś w firmie powie na głos „to narzędzie nam nie pasuje”.
Pierwszy sygnał to praca obok narzędzia. Jeśli raz w tygodniu ktoś eksportuje dane z systemu do Excela, bo w systemie nie da się zrobić zestawienia, które jest potrzebne szefowi, a potem wkleja je z powrotem albo przepisuje do drugiego systemu, to narzędzie przestało obsługiwać proces. Obsługuje tylko jego fragment, a resztę robi człowiek. Z ankiety Zapier wśród tysiąca osób pracujących w małych i średnich firmach wynika, że 76 procent z nich spędza od jednej do trzech godzin dziennie na samym przenoszeniu danych z miejsca na miejsce. Jeśli przeliczysz to na stawkę godzinową pracownika, abonament za narzędzie, które tego nie załatwia, przestaje być najdroższą pozycją. Pisałem o tym szerzej w artykule o automatyzacji procesów w firmie, bo często wystarczy połączyć dwa istniejące systemy, zamiast budować trzeci.
Drugi sygnał to płacenie za stanowiska i funkcje, których nikt nie używa. Większość narzędzi w abonamencie rozlicza się od użytkownika, a pakiety są skonstruowane tak, że jedna potrzebna funkcja siedzi w planie wyższym, razem z dwudziestoma niepotrzebnymi. Dane są tu brutalne, choć pochodzą z firm większych niż Twoja. Według raportu Zylo za 2026 rok organizacje nie wykorzystują średnio 36 procent kupionych licencji SaaS, a Vertice podaje nawet 45,7 procent. W małej firmie skala jest inna, ale mechanizm ten sam. Trzy konta dla osób, które logują się raz w miesiącu, plan „Business” kupiony dla jednego raportu i dodatek, który ktoś włączył rok temu na próbę.
Trzeci sygnał jest najtrudniejszy do zauważenia, bo nie widać go w żadnym arkuszu. To moment, w którym firma zaczyna naginać swój proces do logiki narzędzia. Faktury wystawiane w innej kolejności, bo tak chce system. Klienci opisywani w polach, które nie pasują do branży. Pracownik, który pamięta, że „w tym programie trzeba kliknąć trzy razy, bo inaczej się nie zapisze”. Każda z tych rzeczy z osobna jest drobiazgiem. Razem oznaczają, że narzędzie zarządza firmą, a nie odwrotnie. Właśnie w takich miejscach aplikacje webowe dla firm projektowane pod jeden konkretny proces mają sens, bo robią dokładnie to, co robi firma, w tej kolejności, w której ona to robi.
3. Rachunek na trzy lata
Rachunek, który proponuję, jest prosty i celowo nie udaje analizy finansowej. Jego zadaniem jest sprowadzenie obu opcji do tej samej jednostki, czyli pieniędzy wydanych w ciągu trzech lat. Trzy lata, bo to realistyczny horyzont życia narzędzia w małej firmie, zanim zmieni się proces, zespół albo rynek.
Po stronie gotowego narzędzia liczysz miesięczną cenę za stanowisko, razy liczba stanowisk, razy 36 miesięcy. Do tego dodajesz dwie rzeczy, o których większość zapomina. Pierwsza to podwyżki. Przy dwucyfrowej inflacji cen SaaS uczciwie jest założyć, że w trzecim roku płacisz co najmniej o jedną piątą więcej niż w pierwszym. Nie jest to teoria. Microsoft od 1 lipca 2026 roku podniósł cenę Microsoft 365 Business Basic z 6 do 7 dolarów, a Business Standard z 12,50 do 14 dolarów za użytkownika miesięcznie, czyli o 16 i 12 procent. Atlassian od 13 października 2026 roku podniósł ceny Jira i Confluence dla najmniejszych klientów. A Canva, jak opisał TechCrunch, podniosła cenę starszego planu Teams dla pięciu osób ze 120 do 500 dolarów rocznie, tłumacząc, że poprzednia cena „odzwierciedlała wczesny etap produktu”. Druga rzecz to koszt pracy obok narzędzia z poprzedniej sekcji. Jeśli ktoś traci na przeklejanie danych pięć godzin w miesiącu, pomnóż to przez jego stawkę i przez 36.
Po stronie własnej aplikacji liczysz jednorazowy koszt budowy, plus hosting, plus utrzymanie. I tu jest pułapka, w którą wpada większość firm, bo utrzymanie traktuje jako zero. Nie jest zerem. Robert Glass w klasycznej książce Facts and Fallacies of Software Engineering podaje, że utrzymanie pochłania od 40 do 80 procent całkowitych kosztów oprogramowania w jego cyklu życia, a większość tych kosztów to nie naprawianie błędów, tylko dodawanie nowych funkcji, bo firma się zmienia. Dla małego narzędzia pod jeden proces te proporcje są łagodniejsze, bo mniej jest co zmieniać, ale w rachunku musi być pozycja na aktualizacje bibliotek, poprawki po zmianach w systemach, z którymi aplikacja się łączy, i kopie zapasowe. Zapytaj wykonawcę wprost, ile to kosztuje rocznie, i wpisz tę kwotę razy trzy.
Jeśli po takim rachunku własna aplikacja wychodzi drożej, zostań przy gotowym narzędziu i nie miej wyrzutów sumienia. Jeśli wychodzi porównywalnie, przewagą własnej jest to, że po trzech latach nadal ją masz, a abonament trzeba płacić dalej. Jeśli wychodzi wyraźnie taniej, to zwykle znak, że proces jest wąski i dobrze opisany, a gotowe narzędzie było do niego za duże.
4. Kiedy własna aplikacja to zły pomysł
Byłbym nieuczciwy, gdybym nie napisał tej sekcji, bo własna aplikacja potrafi skończyć jako droższa wersja problemu, który miała rozwiązać.
Własna aplikacja to zły pomysł, kiedy proces jest standardowy. Księgowość, poczta, kalendarz, podstawowa obsługa sprzedaży, podpisywanie dokumentów. W tych obszarach gotowe narzędzia mają za sobą tysiące firm, zgodność z przepisami, która zmienia się co rok, i zespoły, które to pilnują. Według GUS w 2025 roku z systemu ERP korzystało 32,9 procent małych firm, a z CRM 20 procent. Te firmy nie zbudowały własnego ERP i słusznie.
To zły pomysł, kiedy nikt w firmie nie potrafi opisać procesu. Jeśli na pytanie „co dokładnie ma robić to narzędzie” odpowiedź brzmi „no, to co robimy”, a trzy osoby robią to trzema różnymi sposobami, to najpierw trzeba uporządkować proces, a dopiero potem go oprogramować. Aplikacja napisana pod bałagan tylko ten bałagan utrwali.
To zły pomysł, kiedy wymieniasz jedno uzależnienie na drugie. Zamiast od dostawcy SaaS stajesz się zależny od jednego wykonawcy, który jako jedyny rozumie kod. Tu trzeba wiedzieć jedną rzecz o polskim prawie. Zgodnie z ustawą o prawie autorskim umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności, a zgodnie z art. 41 ust. 2 obejmuje tylko te pola eksploatacji, które wyraźnie w niej wymieniono. Jeśli w umowie nie ma wprost przeniesienia praw i wyraźnej zgody na modyfikowanie programu, domyślnie masz tylko licencję i nie możesz legalnie zlecić zmian komuś innemu. Co więcej, jak opisuje Lege Artis na podstawie wyroku Sądu Apelacyjnego w Warszawie, wykonawca nie ma obowiązku wydać kodu źródłowego, jeśli umowa tego wprost nie przewiduje. Kupiłeś działający program, nie jego źródło. Dla większych wdrożeń istnieje jeszcze depozyt kodu źródłowego, czyli umowa, w której kod leży u niezależnego podmiotu i jest wydawany, gdy wykonawca upadnie albo przestanie świadczyć wsparcie. Kancelaria RPMS opisuje, że to rozwiązanie jest dostępne także dla małych firm, choć przy wąskim narzędziu zwykle wystarczy po prostu dobrze napisana umowa i kod w Twoim repozytorium.
I wreszcie to zły pomysł, kiedy nie ma planu na dzień po wdrożeniu. Kto reaguje, gdy aplikacja przestanie działać w piątek o siedemnastej? Kto robi kopie bazy? Kto aktualizuje serwer? Jeśli odpowiedź brzmi „jakoś to będzie”, to będzie, ale źle.
5. Trzy przykłady z praktyki
Żeby to nie było teoretyzowanie, trzy narzędzia z moich realizacji. Celowo wybieram takie, w których gotowe rozwiązanie istniało i było dobre, a mimo to własne wyszło lepiej.
Pierwsze to panel SEO do monitoringu pięciu portali. Klient prowadzący kilka serwisów płacił kilkaset złotych miesięcznie za dwa czy trzy narzędzia do śledzenia pozycji w Google i dostępności stron, a dane miał rozrzucone między nimi. Własny panel oparty na bezpłatnym API Google Search Console i jednym płatnym API do sprawdzania pozycji powstał w dwa tygodnie. Abonament spadł do zera, a dostęp do płatnego API, za kilkadziesiąt dolarów jednorazowo, wystarczy na kilka lat pomiarów. To przykład drugiego sygnału z sekcji 2, czyli płacenia za pakiet, z którego używało się jednej piątej.
Drugie to stopka mailowa w Exchange Online dla firmy, która postawiła jeden twardy warunek, zero kosztów cyklicznych. Gotowe narzędzia do stopek robią to dobrze, ale w abonamencie liczonym od użytkownika. Własny dodatek do Outlooka, hostowany samodzielnie, wstawia stopkę z imieniem i telefonem pobranymi z Microsoft 365, na pięciu platformach Outlooka łącznie z telefonem. Od specyfikacji do produkcji minęło około jedenastu godzin pracy. Tu nie było żadnego skomplikowanego procesu, była wąska, dobrze opisana potrzeba, i to właśnie dlatego się opłaciło.
Trzecie to wysyłka faktur z ERP Optima w biurze rachunkowym. Co miesiąc ktoś przez godzinę wysyłał kilkadziesiąt faktur, mail po mailu, z ręcznie dołączanym plikiem. Aplikacja zintegrowana z Optimą skróciła to do jednego kliknięcia i około dwóch minut, a wdrożenie zajęło tydzień. To pierwszy sygnał w czystej postaci, praca obok narzędzia, bo sam ERP był dobry, tylko kończył się w miejscu, w którym zaczynała się żmudna robota.
Co te trzy przypadki mają wspólnego? Każdy dotyczył jednego, wąskiego procesu, który dało się opisać na jednej stronie. Każdy łączył się z tym, co firma już miała, zamiast to zastępować. I w każdym gotowe narzędzie nie było złe, tylko za szerokie albo kończyło się za wcześnie. Więcej takich wdrożeń znajdziesz w realizacjach.
6. Jak przygotować się do rozmowy z wykonawcą
Jeśli po rachunku z sekcji 3 własna aplikacja nadal wygląda sensownie, przed rozmową z kimkolwiek, kto miałby ją zbudować, przygotuj odpowiedzi na kilka pytań. Dobry wykonawca i tak je zada, a Ty zaoszczędzisz pierwszą godzinę spotkania.
- Opisz proces, nie funkcje. Nie „potrzebuję panelu z tabelą i filtrami”, tylko „co miesiąc Ania bierze listę klientów z Optimy, dla każdego generuje PDF, wysyła mailem i odhacza w arkuszu”. Z opisu procesu wykonawca sam wyprowadzi funkcje, a często zaproponuje prostsze rozwiązanie, niż sobie wyobrażałeś.
- Powiedz, co ma zostać bez zmian. Jeśli faktury nadal mają być wystawiane w ERP, a klienci nadal mają być w arkuszu, to narzędzie ma się do tego podłączyć, nie zastąpić. To zwykle obniża koszt o połowę.
- Ustal, kto utrzymuje i za ile rocznie. Hosting, kopie, aktualizacje, reakcja na awarię. Kwota i zakres na piśmie, zanim powstanie pierwsza linia kodu.
- Zażądaj przeniesienia praw i kodu źródłowego w umowie. Wyraźne przeniesienie autorskich praw majątkowych z wymienionymi polami eksploatacji, zgoda na modyfikacje, kod w repozytorium, do którego masz dostęp, i dokumentacja, która pozwoli innej osobie przejąć projekt. Bez tego kupujesz program, nie narzędzie.
- Zapytaj, co się stanie, gdy wykonawca zniknie. Nie jako prowokację, tylko jako test. Jeśli odpowiedź jest konkretna, czyli kod jest u Ciebie, serwer jest Twój, a dokumentacja istnieje, to jesteś bezpieczny. Jeśli odpowiedź brzmi „nie zniknę”, to nie jest odpowiedź.
7. Podsumowanie
Gotowe narzędzie w abonamencie to dobra, domyślna odpowiedź i w większości przypadków powinieneś przy niej zostać. Własna aplikacja webowa ma sens wtedy, gdy proces jest wąski i dobrze opisany, gdy ludzie pracują obok narzędzia zamiast w nim, gdy płacisz za pakiet, z którego używasz ułamka, i gdy rachunek na trzy lata, z uczciwie policzonym utrzymaniem, wychodzi na jej korzyść. A nawet wtedy tylko z umową, która daje Ci prawa i kod, nie samą obietnicę.
Jeśli masz w firmie proces, który pasuje do tego opisu, i chcesz sprawdzić, czy warto go oprogramować, zobacz, jak wyglądają aplikacje webowe projektowane pod konkretny proces firmy, albo po prostu napisz do mnie z opisem tego, co dziś robicie ręcznie. Odpowiem szczerze, także wtedy, gdy odpowiedź brzmi „zostańcie przy tym, co macie”.