MVP systemu SaaS kosztuje w AppCreo od 35 000 zł netto, bo potrzebuje płatności cyklicznych - najprostsze MVP webowe bez płatności to od 15 000 zł netto. MVP powstaje zwykle w 3–5 tygodni i jest najtańszym sposobem, żeby sprawdzić, czy klienci zapłacą. Wersję gotową na wielu płacących klientów wyceniamy indywidualnie. O cenie decydują cztery elementy: obsługa wielu firm w jednym systemie (multi-tenant), subskrypcje i płatności, onboarding oraz liczba integracji. Aktualne ceny AppCreo znajdziesz w cenniku.
Poniżej rozpisujemy etapy budowy i to, co podnosi koszt na każdym z nich, oraz pokazujemy, czym SaaS różni się od zwykłej aplikacji webowej. Wyjaśniamy też, co musi mieć pierwsza wersja, żeby nie trzeba było jej przepisywać po pierwszych klientach.
Co składa się na koszt systemu SaaS na każdym etapie?
SaaS buduje się etapami, bo dopiero pierwsi płacący klienci pokazują, które funkcje są warte rozbudowy. Tabela pokazuje typową ścieżkę od warsztatu do platformy z integracjami.
| Etap | Co obejmuje | Względny poziom kosztu | Czas |
|---|---|---|---|
| Warsztat i zakres | Model danych, role, plany cenowe, makiety kluczowych ekranów | najniższy | kilka dni; rynkowy format design sprint (GV) trwa 5 dni |
| MVP | Rejestracja firmy-klienta, jeden główny proces, jeden plan subskrypcji, panel administratora | średni - u nas od 35 000 zł netto | 3–5 tygodni |
| Beta z pierwszymi klientami | Poprawki, onboarding, analityka zachowań, wsparcie | niższy niż MVP | rynkowo zwykle 4–8 tygodni (Centercode) |
| Wersja 1.0 | Kilka planów, role w firmie klienta, faktury, API, monitoring | wysoki | 1,5–2 miesiące |
| Platforma z integracjami | Integracje z systemami klientów, logowanie SSO, raporty, white-label | bardzo wysoki, rozbudowana platforma - najwyższy | 2–3 miesiące, platforma 2,5–4,5 miesiąca |
| Utrzymanie i rozwój | Hosting, aktualizacje, poprawki, nowe funkcje | 15–25% wartości projektu rocznie | stale |
Kwota w wierszu MVP to nasz dolny próg dla MVP z płatnościami, bo SaaS potrzebuje ich już w pierwszej wersji. Wersję 1.0 i platformę z integracjami, logowaniem SSO i white-label wyceniamy indywidualnie - ich koszt zależy głównie od liczby planów, ról i integracji, a progi dla większych projektów znajdziesz w cenniku.
Etapy nie muszą iść jeden po drugim. Jeśli masz już klientów, którzy czekają na produkt i wiedzą, czego potrzebują, możesz zacząć od razu od wersji 1.0.
Czym system SaaS różni się od zwykłej aplikacji webowej?
Aplikacja webowa dla firmy obsługuje jedną organizację: jej pracowników, dane i procesy. System SaaS obsługuje wiele firm-klientów naraz, z których każda płaci abonament, widzi wyłącznie swoje dane i sama zakłada konto. Z tego wynikają cztery dodatkowe obszary pracy.
- Separacja danych klientów. Każde zapytanie do bazy musi uwzględniać, do której firmy należą dane; błąd oznacza wyciek danych do innego klienta.
- Płatności cykliczne. Plany, okresy próbne, zmiana planu w trakcie okresu rozliczeniowego, nieudane płatności, faktury.
- Samodzielny onboarding. Klient zakłada konto, zaprasza zespół i dochodzi do pierwszego efektu bez rozmowy z Tobą.
- Jedna wersja dla wszystkich. Aktualizacja trafia do wszystkich klientów naraz, więc testy i proces wdrożeń muszą być pewniejsze.
Dlatego ten sam zakres funkcji kosztuje w SaaS więcej niż w systemie wewnętrznym. Jeśli zastanawiasz się, czy zbudować własny system, czy kupić gotowy SaaS dla swojej firmy, porównanie obu dróg znajdziesz w tekście system dedykowany czy SaaS.
MVP SaaS czy od razu wersja skalowalna?
Dla nowego produktu prawie zawsze MVP. Jego celem nie jest pełna funkcjonalność, tylko dowód, że klienci zapłacą za rozwiązanie jednego problemu. Wersja skalowalna ma sens, gdy popyt jest już potwierdzony, na przykład listą firm gotowych podpisać umowę.
Co musi mieć MVP SaaS
- rejestrację firmy-klienta i zaproszenia dla jej pracowników,
- separację danych klientów od pierwszego dnia, nawet przy jednym kliencie,
- jeden główny proces, za który klient płaci,
- jeden lub dwa plany subskrypcji z płatnością kartą i na fakturę,
- panel administratora do obsługi klientów i podglądu płatności,
- podstawową analitykę: kto się zarejestrował, kto wrócił, kto zapłacił.
Co można odłożyć na później
Rozbudowane role i uprawnienia, integracje z systemami klientów, logowanie firmowe SSO, własne raporty, aplikację mobilną i wersje językowe. Każdą z tych funkcji da się dołożyć w wersji 1.0, jeśli fundament - separacja danych i model płatności - jest zaprojektowany poprawnie.
Kiedy od razu budować wersję skalowalną
Gdy pierwszymi klientami są duże firmy, które od pierwszego dnia wymagają SSO, dziennika zdarzeń i umowy powierzenia danych. Albo gdy produkt działa w branży regulowanej, gdzie MVP bez tych elementów nie przejdzie oceny działu bezpieczeństwa klienta.
Jak zaplanować pierwszą wersję, opisujemy w tekście o koszcie i czasie budowy MVP, a o przejściu do wersji produkcyjnej - w tekście od MVP do wersji 1.0. Obie decyzje warto podjąć przed napisaniem pierwszej linijki kodu.
Masz pomysł na SaaS? Opisz go w 3 zdaniach - odsyłamy przedział cenowy w 24 h w dni robocze. wypełnij formularz, napisz na biuro@appcreo.pl albo zadzwoń: +48 783 477 243.
Jak zaprojektować multi-tenant, subskrypcje i onboarding?
Te trzy obszary odróżniają SaaS od zwykłej aplikacji i to w nich najłatwiej o błąd, którego nie da się tanio naprawić później. Każdy warto zaprojektować przed startem budowy, nawet jeśli w MVP powstanie tylko jego najprostsza wersja.
Trzy modele multi-tenant
Multi-tenant oznacza, że wielu klientów korzysta z jednej instalacji systemu, ale ich dane są od siebie oddzielone. Są trzy podstawowe sposoby tej separacji, różniące się poziomem izolacji i kosztem utrzymania.
| Model | Izolacja danych | Koszt infrastruktury | Kiedy wybrać |
|---|---|---|---|
| Wspólna baza, identyfikator klienta w każdej tabeli | Logiczna, zależy od kodu | Najniższy | MVP i większość produktów dla małych i średnich firm |
| Osobny schemat bazy dla każdego klienta | Silniejsza | Średni | Klienci z większymi wymaganiami bezpieczeństwa |
| Osobna baza danych dla każdego klienta | Najsilniejsza | Najwyższy | Duże firmy, branże regulowane, wymóg lokalizacji danych |
W Laravelu każdy z tych modeli da się zbudować na gotowych pakietach, na przykład Tenancy for Laravel albo spatie/laravel-multitenancy. Niezależnie od modelu izolację trzeba testować automatycznie: błędna kontrola dostępu to pierwsza kategoria na liście OWASP Top 10:2025.
Subskrypcje i płatności
Płatności cykliczne najczęściej obsługuje operator z modułem subskrypcji, na przykład Stripe Billing. Bierze na siebie odnawianie subskrypcji, przypomnienia o zaległościach, ponawianie nieudanych płatności i portal, w którym klient sam zmienia kartę. Kosztuje 0,7% wolumenu rozliczeń, plus opłaty za same płatności.
W Laravelu integrację upraszcza Cashier: subskrypcje, okresy próbne, kupony, zmiana planu, liczba stanowisk, karencja po anulowaniu i faktury PDF są gotowe. Zostaje logika Twojego cennika i obsługa wyjątków.
Polscy klienci B2B często płacą przelewem po fakturze, a nie kartą. Od 2026 roku większość firm w Polsce wystawia faktury w KSeF, więc system musi je tam wysyłać albo przekazywać dane do programu księgowego. Więcej w tekście o integracji systemów z KSeF.
Onboarding
Onboarding decyduje, czy firma z okresu próbnego zostanie płacącym klientem. Dobry onboarding prowadzi od rejestracji do pierwszego efektu: import danych, zaproszenie zespołu, przykładowe dane zamiast pustych ekranów. Mierz odsetek firm, które w okresie próbnym wykonały kluczową akcję.
RODO i bezpieczeństwo
Dostawca SaaS przetwarza dane klientów w ich imieniu, więc z każdym podpisuje umowę powierzenia przetwarzania (art. 28 RODO). Klienci zapytają o lokalizację serwerów, podprocesorów, kopie zapasowe i zgłaszanie naruszeń. Odpowiedzi przygotuj przed pierwszą sprzedażą, bo bez nich większe firmy nie podpiszą umowy.
Jak wygląda architektura SaaS w Laravelu i React?
Typowy układ to backend w Laravelu, interfejs w React i relacyjna baza danych, najczęściej PostgreSQL albo MySQL. Laravel obsługuje logikę, API, kolejki zadań i płatności, a React odpowiada za płynny interfejs dla użytkowników klienta.
- Backend: Laravel z kolejkami (Horizon), płatnościami (Cashier) i API dla integracji.
- Frontend: React przez Inertia, gdy wystarczy jeden backend, albo osobna aplikacja, gdy dojdą aplikacje mobilne.
- Baza i cache: PostgreSQL lub MySQL oraz Redis na sesje, cache i kolejki.
- Pliki: magazyn obiektowy zgodny z S3, z oddzieleniem plików poszczególnych klientów.
- Hosting: chmura publiczna, Laravel Cloud albo własny serwer; dla klientów z UE - z danymi w regionie UE.
- Monitoring: błędy, wydajność i nieudane zadania w tle, z alertami dla zespołu.
Dlaczego akurat Laravel i kiedy lepszy będzie Node.js, opisujemy w tekście o Laravelu w systemach firmowych. Obie technologie przedstawiamy też na stronach Laravel i PHP oraz React i Node.js.
Co składa się na utrzymanie systemu SaaS i jak policzyć budżet?
Po uruchomieniu SaaS ma koszty stałe, które rosną z liczbą klientów: hosting, poczta transakcyjna, monitoring, opłaty operatora płatności i wsparcie. Utrzymanie z aktualizacjami i poprawkami to rocznie zwykle 15–25% wartości projektu, bez rozwoju nowych funkcji.
Pamiętaj też o aktualizacjach technologii. Laravel wydaje nową wersję główną co roku i każdą wspiera 2 lata w zakresie poprawek bezpieczeństwa, więc aktualizacja frameworka to stała pozycja w rocznym planie, a nie wydatek awaryjny.
Budżet na pierwsze 12 miesięcy policzysz w pięciu krokach:
- Koszt budowy. MVP albo wersja 1.0 - według zakresu z tabeli etapów i wyceny wykonawcy.
- Koszty stałe. Hosting, usługi zewnętrzne i monitoring - poproś wykonawcę o wycenę przy zakładanej liczbie klientów.
- Opłaty za płatności. Procent od przychodu według cennika operatora, na przykład 0,7% wolumenu w Stripe Billing plus prowizje od transakcji.
- Utrzymanie. Poprawki, aktualizacje i wsparcie, rocznie zwykle 15–25% wartości projektu.
- Rozwój. Budżet na funkcje zgłaszane przez pierwszych klientów; przy stawce godzinowej wykonawcy łatwo przeliczyć go na godziny pracy.
Tak policzony budżet porównaj z prognozą przychodu z abonamentów. Jeśli do pokrycia kosztów potrzebujesz więcej klientów, niż realnie pozyskasz w pierwszym roku, zmień zakres MVP albo cennik, zanim zaczniesz budowę.
Planowanie kosztów projektu opisujemy szerzej w tekście o budżetowaniu projektu dedykowanego systemu IT. Zakres naszych prac przy systemach webowych znajdziesz na stronie tworzenia aplikacji webowych.
