Z SaaS na system dedykowany: dlaczego usunęliśmy 15 tys. linii kodu z własnego produktu
Zwykle pisze się o przejściu w drugą stronę: firma porzuca dedykowany system i przesiada się na abonament. My we wrześniu 2026 zrobiliśmy odwrotnie — z własnego produktu SaaS zbudowaliśmy instancję dedykowaną dla jednej firmy i wycięliśmy z niej 106 plików, czyli ponad 15 700 linii kodu. Oto dlaczego to była najlepsza decyzja w tym projekcie i jak się to robi, żeby nic nie wybuchło.
Punkt wyjścia: dobry SaaS, który zaczął przeszkadzać
Serwis-Pro powstał jako typowy produkt abonamentowy dla firm serwisowych: pakiety, okres próbny, samodzielna rejestracja firm, panel operatora do zarządzania klientami platformy i moduły włączane zależnie od wykupionego planu. Taka architektura ma sens, kiedy obsługujesz wiele podobnych firm, z których żadna nie ma prawa zmienić produktu pod siebie.
Potem przyszedł klient, który nie był „podobną firmą”. Firma instalacyjna z zespołem 26 osób (20 monterów, czterech administratorów, dwie osoby w biurze) potrzebowała rzeczy, które w SaaS-ie byłyby albo niemożliwe, albo kosztowałyby wszystkich pozostałych użytkowników komplikację: własnych nazw ról w całym systemie, protokołu przeglądu kotła wiernego co do przecinka ich wzorowi, rezerwacji ze swojej strony internetowej z płatnością online i automatyczną fakturą, a do tego przydziału zlecenia do najbliższego montera liczonego od jego ostatniej wizyty w danym dniu.
Co dokładnie wycięliśmy
Decyzja zapadła 12 września 2026: ta instancja nie będzie sprzedawana w pakietach. Produkt serwis-pro.app żyje dalej jako osobna linia, a firma dostała system, który jest wyłącznie jej. Z kodu dedykowanej wersji zniknęło wszystko, co służyło platformie, a nie firmie:
| Warstwa | Po co była w SaaS | Dlaczego firmie nie jest potrzebna |
|---|---|---|
| Plany, abonamenty, baner okresu próbnego, obsługa płatności za abonament | sprzedaż produktu wielu firmom | firma płaci za wdrożenie i utrzymanie, nie za pakiet |
| Panel operatora (8 zakładek, 24 funkcje serwerowe) | zarządzanie klientami platformy | jest jedna firma — nie ma kim zarządzać |
| Wnioski rejestracyjne i zakładanie firmy z linku | samodzielny onboarding | konta zakłada administrator firmy zaproszeniami |
| Bramkowanie modułami (widoczność funkcji zależna od planu) | różnicowanie pakietów | firma ma wszystko, czego używa, i nic ponadto |
| Cała warstwa marketingowa: strona główna, cennik, blog, FAQ, landingi, sitemapa | pozyskiwanie klientów | system firmowy nie powinien być indeksowany w Google |
W sumie: 106 plików i 15 723 linie kodu mniej. Adres główny prowadzi prosto do logowania, roboty wyszukiwarek mają zakaz wstępu, a w interfejsie i mailach widnieje marka klienta, nie nasza. Zakładka, w której był abonament, zamieniła się w podgląd zużycia asystenta AI — jedynej rzeczy, którą rzeczywiście warto tam liczyć.
Dlaczego mniej kodu oznacza lepszy system
- mniej miejsc, w których może się coś zepsuć — każdy moduł, którego nikt nie używa, i tak trzeba aktualizować, testować i zabezpieczać
- prostsze uprawnienia — reguły dostępu do danych nie muszą już rozróżniać firm na platformie ani planów, więc łatwiej je sprawdzić i trudniej o wyciek
- szybsze zmiany — prośba klienta nie przechodzi przez pytanie „a jak to wpłynie na 40 innych firm”; jest jedna firma i jeden proces
- jasna własność — kod i dane tej instancji należą do firmy, a nie do dostawcy platformy
Pułapki, o których nie przeczytasz w poradnikach
Usuwanie kodu brzmi jak najbezpieczniejsza operacja w informatyce. W systemie z logiką w bazie danych bywa odwrotnie. Trzy rzeczy, które przy mniej ostrożnym podejściu skończyłyby się awarią produkcyjną:
- funkcja obsługująca rejestrację nowego użytkownika deklarowała zmienną typu wiersza tabeli wniosków rejestracyjnych — usunięcie tej tabeli wywróciłoby każdą rejestrację, także zaproszenia do zespołu, i to dopiero przy pierwszym wywołaniu, nie w chwili wdrożenia
- sprawdzanie „czy firma ma moduł” było wołane z wnętrza innych funkcji, w tym czterech strażników pilnujących, żeby dwa zlecenia nie zajęły tego samego terminu montera; baza danych nie śledzi takich zależności, więc usunięcie przeszłoby bez błędu, a system zacząłby się sypać w trakcie pracy
- kolumny związane z okresem próbnym były jawnie pobierane przy ładowaniu sesji — skasowanie ich przed poprawką kodu oznaczałoby wieczne kółko ładowania dla wszystkich użytkowników
SaaS czy system dedykowany — jak to rozpoznać u siebie
| Sytuacja w firmie | Lepiej sprawdzi się |
|---|---|
| proces jak u większości konkurencji, zespół do 5–10 osób | gotowy SaaS |
| dokumenty muszą wyglądać jak Wasze wzory, a nie szablon dostawcy | system dedykowany |
| własne nazwy ról, własny obieg akceptacji, własne reguły przydziału | system dedykowany |
| integracja z Waszą stroną, bramką płatności i programem do faktur | zależy — jeśli SaaS ma gotowe integracje, SaaS; jeśli nie, dedykowany |
| chcecie zacząć jutro i sprawdzić, czy w ogóle potrzebujecie systemu | gotowy SaaS |
| abonament za 20+ użytkowników przekracza koszt utrzymania własnego systemu | system dedykowany |
Warto zauważyć, czego ta historia NIE pokazuje: nie pisaliśmy systemu od zera. Firma dostała sprawdzony rdzeń — zlecenia, kalendarz, protokoły, podpisy, płatności — i zapłaciła za dopasowanie, a nie za wymyślanie koła na nowo. To jest najtańsza droga do systemu dedykowanego i piszemy o niej osobno.
Najczęstsze pytania
Czy przejście z SaaS na system dedykowany oznacza utratę danych?
Nie powinno. W opisanym przypadku instancja dedykowana powstała z tej samej bazy kodu, więc dane i konfiguracja zostały na miejscu, a zmiany schematu bazy szły migracjami z kopią zapasową wykonaną przed każdym krokiem. Przy migracji z cudzego SaaS-a kluczowe jest wcześniejsze sprawdzenie, w jakim formacie dostawca pozwala wyeksportować dane.
Ile kosztuje utrzymanie systemu dedykowanego w porównaniu z abonamentem?
Utrzymanie (hosting, kopie zapasowe, monitoring, drobne poprawki) to zwykle kwota rzędu kilkuset złotych miesięcznie, niezależna od liczby użytkowników. Przy zespole kilkudziesięciu osób abonament liczony per użytkownik bardzo często ją przekracza — to jeden z częstszych powodów przejścia na własny system.
Czy system dedykowany może później wrócić do modelu SaaS?
Technicznie tak, ale to rzadko ma sens. Rozsądniej jest traktować dobre rozwiązania z wdrożenia dedykowanego jako moduły, które wracają do produktu SaaS albo trafiają do kolejnych wdrożeń — tak robimy z modułami przenoszonymi między naszymi systemami.