Własna aplikacja czy SaaS: jak policzyć, co się opłaca

Wybór między własną aplikacją a SaaS to rachunek na trzy do pięciu lat, a nie kwestia gustu. SaaS wygrywa w procesach prowadzonych wszędzie podobnie, takich jak poczta, księgowość, kadry czy wideokonferencje. Własna aplikacja zaczyna się opłacać tam, gdzie cennik za użytkownika rośnie szybciej niż korzyść, gdzie proces jest przewagą firmy albo gdzie zespół codziennie nagina swoją pracę do narzędzia.

Większość firm porównuje jednak miesięczny abonament z jednorazową wyceną programistów, co daje fałszywy obraz po obu stronach. Abonament nie jest jedynym kosztem SaaS, a wycena budowy nie jest jedynym kosztem własnego systemu. Poniżej opisujemy pozycje, które trzeba policzyć, przykład liczbowy i czynniki, których nie da się wyrazić w złotówkach.

Co naprawdę kosztuje SaaS

Podstawą jest iloczyn: cena za użytkownika, liczba użytkowników i liczba lat. Wielu dostawców wycenia produkt właśnie w ten sposób; cennik Salesforce Sales Cloud podaje ceny za użytkownika miesięcznie, a wyższe edycje rozlicza w umowach rocznych. Przy takim modelu rachunek rośnie z każdą zatrudnioną osobą, nawet jeśli nowa osoba używa tych samych trzech ekranów co reszta.

Do tego trzeba doliczyć podwyżki przy odnowieniu, dodatki dostępne tylko w wyższym pakiecie i opłaty za integracje. Największą pozycją bywa jednak praca obok systemu: przepisywanie danych między narzędziami, arkusze uzupełniające braki raportów, ręczne zestawienia na koniec miesiąca. Tego kosztu nie ma na fakturze, ale można go zmierzyć, pytając zespół, ile godzin tygodniowo spędza poza aplikacją.

Warto też sprawdzić, za co firma płaci bez użycia. Zylo 2026 SaaS Management Index, oparty na analizie ponad 40 mln licencji i 75 mld USD wydatków, wskazuje, że organizacje pozostawiają średnio 36% licencji niewykorzystanych względem zalecanych poziomów użycia. Komunikat wymienia wyniki dla dużych przedsiębiorstw i firm zatrudniających ponad 10 tys. osób oraz ankietę wśród 218 liderów IT, ale nie podaje łącznej liczby firm ani pełnego podziału próby, więc nie przenosimy tej liczby wprost na małą firmę. Wniosek praktyczny jest jednak ogólny: zanim policzysz użytkowników, policz aktywnych użytkowników.

Ostatnia pozycja to koszt wyjścia. Akt w sprawie danych stosuje się od 12 września 2025 roku i tworzy ramy, w których klienci usług przetwarzania danych mogą skutecznie zmienić dostawcę. Według objaśnień Komisji Europejskiej dostawca SaaS musi co najmniej wyeksportować dane w powszechnie używanym, nadającym się do odczytu maszynowego formacie, a do 12 stycznia 2027 roku może pobierać opłaty pokrywające koszty przejścia; potem opłaty za zmianę dostawcy, łącznie z transferem danych, mają zniknąć. Eksport danych to jednak nie migracja procesu. Konfiguracja, automatyzacje i nawyki zespołu nie przechodzą w pliku CSV i ich odtworzenie trzeba policzyć osobno.

Co naprawdę kosztuje własna aplikacja

Po drugiej stronie stoi budowa pierwszej wersji, przeniesienie danych z obecnego narzędzia i czas zespołu na testy oraz odbiór. Potem przychodzą koszty stałe: hosting, domena, kopie zapasowe, monitoring, aktualizacje bezpieczeństwa, obsługa usterek i rozwój kolejnych funkcji. Usługi zewnętrzne, takie jak SMS-y, płatności czy mapy, mają własne cenniki niezależne od wykonawcy.

Najczęściej pomijana pozycja to odpowiedzialność. Przy SaaS za łatanie podatności, dostępność i kopie zapasowe odpowiada dostawca. Przy własnej aplikacji ktoś konkretny musi to robić co miesiąc, także wtedy, gdy nikt nie zgłasza nowych funkcji. Jeśli w budżecie nie ma pozycji na utrzymanie, aplikacja nie jest tańsza, tylko ma nieprzeliczone ryzyko.

Przykład hipotetyczny z okrągłymi liczbami

Poniższe liczby są wymyślone na potrzeby ilustracji i nie pochodzą z żadnego projektu ani cennika. Firma ma 40 użytkowników CRM po 250 zł miesięcznie, czyli 120 tys. zł rocznie, i zakłada podwyżki o 5% przy każdym odnowieniu. Zespół spędza poza systemem około 400 godzin rocznie, co przy stawce 100 zł daje 40 tys. zł. Konektor integracyjny kosztuje 6 tys. zł rocznie. Pierwszy rok SaaS to 166 tys. zł, a łącznie przez pięć lat około 893 tys. zł.

Własna aplikacja wymaga 300 tys. zł na budowę i 30 tys. zł na migrację. Rocznie dochodzi 24 tys. zł hostingu, 72 tys. zł utrzymania i 10 tys. zł na resztkową pracę ręczną, razem 106 tys. zł. Po pięciu latach suma wynosi około 860 tys. zł.

Roczna różnica w koszcie bieżącym rośnie z 60 tys. zł w pierwszym roku do około 86 tys. zł w piątym, a jej suma przekracza 330 tys. zł nakładu początkowego dopiero w piątym roku. W horyzoncie trzech lat SaaS jest wyraźnie tańszy, w horyzoncie pięciu lat wynik jest niemal remisowy. Ten przykład pokazuje głównie wrażliwość: przy 60 użytkownikach od pierwszego roku nakład zwróciłby się w trzecim roku; jeśli utrzymanie okaże się dwa razy droższe, nie wygrywa nigdy.

Jak policzyć punkt opłacalności

Punkt opłacalności to moment, w którym suma rocznych oszczędności na kosztach bieżących zrównuje się z nakładem na budowę i migrację. Liczy się go rok po roku, a nie średnią, bo podwyżki i wzrost zatrudnienia działają z opóźnieniem. Każde założenie trzeba zapisać osobno: liczbę aktywnych użytkowników w każdym roku, przewidywane podwyżki, godziny pracy ręcznej przed zmianą i po niej oraz koszt utrzymania.

Potem warto policzyć dwa warianty skrajne: pesymistyczny dla budowy (opóźnienie, droższe utrzymanie, wolniejsze odejście od arkuszy) i pesymistyczny dla SaaS (wzrost zespołu, wyższa podwyżka, konieczność wyższego pakietu). Jeśli własna aplikacja wygrywa tylko w wariancie optymistycznym, decyzja jest zbyt ryzykowna. Jeśli wygrywa w obu, liczenie dalej niczego nie zmieni.

Tak też liczymy przed wyceną aplikacji szytej na miarę: zestawiamy obecne abonamenty z budową, przeniesieniem danych i utrzymaniem w tym samym okresie.

Co zmienia programowanie wspierane przez AI

Narzędzia AI dla programistów mogą obniżać koszt budowy, ale dowody są słabsze, niż sugerują deklaracje producentów. METR w randomizowanym badaniu z początku 2025 roku zmierzył, że doświadczeni programiści open source z narzędziami AI pracowali o 19% dłużej. W aktualizacji z lutego 2026 roku ocenia, że na początku 2026 roku programiści prawdopodobnie zyskują na AI więcej, ale z powodu efektów selekcji uczestników nowe dane są bardzo słabym dowodem na skalę tego efektu.

Nasza ocena jest ostrożna. AI skraca pisanie powtarzalnego kodu, ale nie skraca ustalania wymagań, migracji danych, testów z udziałem zespołu ani utrzymania. Do kalkulacji nie należy więc wpisywać obniżki kosztu budowy, dopóki wykonawca nie pokaże jej w wycenie konkretnego zakresu.

Czynniki, których nie ma w arkuszu

Własność danych i ich przenośność to pierwsze pytanie. W SaaS dane są dostępne na warunkach dostawcy; we własnym systemie firma decyduje, gdzie leżą i kto ma do nich dostęp. Uzależnienie od dostawcy dotyczy jednak obu stron: aplikacja, którą rozumie tylko jeden wykonawca, wiąże firmę równie mocno jak abonament.

Dlatego liczy się własność kodu źródłowego i dokumentacja. Umowa powinna określać prawa do stworzonego kodu i wymieniać komponenty zewnętrzne wraz z licencjami. Warto też sprawdzić, czy aplikację może przejąć inny wykonawca albo własny zespół: czy kod jest w repozytorium firmy, czy istnieje instrukcja uruchomienia, czy konta infrastruktury są na firmę, a nie na wykonawcę.

Kiedy nie budować

Nie buduj, gdy proces jest standardowy, a gotowe narzędzie obsługuje go dobrze i tanio. Nie buduj, gdy wymagania zmieniają się co miesiąc i nikt nie wie, z których funkcji zespół naprawdę korzysta; najpierw warto to zmierzyć w obecnym narzędziu. Nie buduj też wtedy, gdy nikt w firmie nie będzie odpowiadał za odbiór zmian i budżet utrzymania. Własna aplikacja bez właściciela starzeje się szybciej niż abonament, który przynajmniej ktoś aktualizuje.