Gotowe narzędzie czy aplikacja dedykowana? Drzewko decyzji

Gotowe narzędzie (SaaS) wystarcza, gdy Twój proces jest typowy, a koszt licencji rośnie wolniej niż firma. Aplikacja dedykowana ma sens, gdy gotowe rozwiązania nie obsługują kluczowej części procesu, wymagają coraz więcej obejść albo ich łączny koszt zaczyna hamować rozwój. Często najlepsza jest trzecia droga: gotowe narzędzie i mały własny moduł. Zanim zapytasz o wycenę, przejdź drzewko decyzji.

Pierwsze pytanie: czy narzędzie obsługuje to, co najważniejsze?

Oprogramowanie dedykowane nie jest lepsze samo w sobie. Gotowe narzędzie to zwykle dobra decyzja, gdy Twój proces przypomina procesy tysięcy innych firm (fakturowanie, CRM, newsletter, prosta sprzedaż kursów), braki dotyczą drobiazgów, rozwiązanie potrzebne jest w dniach, a nie miesiącach, i nie ma być źródłem przewagi nad konkurencją. Budowa własnej aplikacji oznacza wtedy płacenie za coś, co już istnieje, a potem utrzymywanie tego samodzielnie. Mówimy to wprost na etapie analizy, także wtedy, gdy wniosek brzmi: nie budujcie aplikacji.

Gałąź „tak”: kiedy koszty rosną szybciej niż firma

Narzędzie może obsługiwać wszystko, a mimo to przestać się opłacać. Sygnały ostrzegawcze:

• płacisz za kilka narzędzi naraz, a licencje liczone od użytkownika lub transakcji rosną z każdym pracownikiem i klientem,
• obejścia stały się procesem: dane przepisywane między systemami, arkusze łączone ręcznie co tydzień, jedna osoba, która „wie, jak to obejść”,
• API nie udostępnia potrzebnych danych albo limity zapytań blokują automatyzację,
• wydajność spada wraz z liczbą użytkowników i danych,
• eksport jest niepełny, a zmiana dostawcy oznaczałaby utratę historii.

Jeśli widzisz dwa lub trzy z nich, policz koszt na trzy lata: abonamenty i dodatki plus czas zespołu na obejścia, wobec kosztu modułu albo aplikacji z utrzymaniem. Czas na obejścia jest zwykle największą i najrzadziej liczoną pozycją.

Gałąź „nie”: najpierw sprawdź moduł

Gdy gotowe narzędzie nie obsługuje kluczowej części procesu, nie od razu trzeba budować cały system. Jeśli ma otwarte API, często wystarczy dobudować mały, dedykowany element tam, gdzie gotowe rozwiązanie się kończy. Taki moduł jest tańszy i szybciej przynosi efekt. Przykład: sklep na WooCommerce zostaje, a obok powstaje osobne narzędzie do ustalania cen, które łączy cennik dostawcy z danymi o konkurencji i przygotowuje plik do importu.

Aplikacja dedykowana zostaje wtedy, gdy nie da się zrobić nawet tego. Tak było przy platformie kursowej Tromplo: gotowe rozwiązania nie dawały potrzebnych funkcji, były wolne i kosztowne w utrzymaniu, więc zbudowaliśmy platformę od podstaw.

Porównanie w jednej tabeli

Kryterium	Gotowe narzędzie (SaaS)	Aplikacja dedykowana
Koszt na start	Niski, abonament od pierwszego miesiąca	Wyższy: analiza, projekt, programowanie
Koszt w czasie	Rośnie z użytkownikami, modułami i dodatkami	Utrzymanie i rozwój, zależne od tego, ile zmieniasz
Czas do uruchomienia	Dni lub tygodnie	Zwykle miesiące, krócej przy wąskiej pierwszej wersji
Dopasowanie	Dopasowujesz proces do narzędzia	Narzędzie powstaje pod proces
Własność i dane	Licencja, dane u dostawcy	Kod i dane mogą należeć do Ciebie, jeśli umowa to przewiduje
Ryzyko	Zmiana cennika, funkcji albo zamknięcie usługi	Jakość wykonania i zależność od wykonawcy bez dokumentacji

Jak wygląda projekt i od czego zależy koszt

Zaczynamy od analizy procesu, ról użytkowników, uprawnień i integracji. Potem makiety kluczowych ekranów, które akceptujesz, zanim zacznie się programowanie. Pierwsza wersja (MVP) ma tylko funkcje, bez których aplikacja nie spełni swojej roli, a kolejne etapy przechodzą przegląd kodu i testy przed wdrożeniem. Przykład połączenia kilku procesów w jednym miejscu to serwis Ocelot Clinic: kalkulator, rezerwacja, płatność i panel do zarządzania wizytami zamiast kilku osobnych narzędzi.

Na koszt najbardziej wpływają:

• role i uprawnienia: system dla klientów, pracowników, partnerów i administratorów, z których każdy widzi co innego,
• liczba procesów: każde zamówienie, rezerwacja czy reklamacja to osobne ekrany, reguły i przypadki brzegowe,
• integracje: płatności, kalendarze, ERP, księgowość, KSeF, a także jakość dokumentacji po drugiej stronie,
• dane i migracja: przeniesienie danych z dotychczasowych narzędzi i arkuszy,
• bezpieczeństwo: logowanie, logi zdarzeń, kopie, szyfrowanie, wymagania klientów objętych NIS2,
• raporty i panel administracyjny: często niedoszacowane, a to one oszczędzają najwięcej czasu,
• aplikacja webowa czy mobilna: osobne aplikacje na iOS i Androida to dodatkowy zakres, a od 11 grudnia 2027 r. oprogramowanie instalowane może podlegać Cyber Resilience Act,
• utrzymanie: hosting, aktualizacje frameworka i PHP, monitoring, rozwój.

Najskuteczniejszy sposób na kontrolę kosztu to wąska pierwsza wersja. Łatwiej dołożyć funkcję, gdy wiadomo, jak korzystają z niej użytkownicy, niż utrzymywać funkcje, które okazały się zbędne.

Framework ma mniejsze znaczenie, niż myślisz

Laravel daje dużo gotowych elementów i szybką pierwszą wersję, ale nowa wersja główna wychodzi co roku, z poprawkami bezpieczeństwa przez 2 lata. Symfony dobrze sprawdza się w dużych, długo rozwijanych systemach, a wersje LTS mają 3 lata poprawek błędów i dodatkowy rok poprawek bezpieczeństwa. Dla zamawiającego ważniejsze jest, czy wykonawca uzasadnia wybór, pisze testy, dokumentuje kod i planuje aktualizacje. Aplikacja na dowolnym frameworku, której nikt nie aktualizuje, po kilku latach wymaga kosztownej przebudowy.

Własność kodu: o co zadbać w umowie

Zapłata za aplikację nie oznacza automatycznie, że prawa do kodu przechodzą na Ciebie. Według ustawy o prawie autorskim przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53) i obejmuje tylko pola eksploatacji wymienione w umowie (art. 41 ust. 2). Sprawdź, czy umowa:

• przenosi prawa do kodu i projektu graficznego, czy daje tylko licencję,
• wymienia pola eksploatacji i moment przejścia praw (np. po zapłacie),
• daje dostęp do repozytorium, serwerów i kont usług zewnętrznych,
• obejmuje przekazanie dokumentacji i instrukcji uruchomienia,
• opisuje biblioteki open source i ich licencje.

Zapisy umowy warto skonsultować z prawnikiem. Nasze podejście do własności kodu opisujemy w FAQ.

Nie wiesz, którą gałąź wybrać?

Budujemy aplikacje i platformy webowe w Laravel, Symfony, React, Vue i innych technologiach, ale zaczynamy od analizy procesu. Jeśli gotowe narzędzie albo mały moduł wystarczą, powiemy to na początku.

Opisz, jaki proces ma obsłużyć aplikacja, a zaproponujemy termin rozmowy.