Czym SaaS różni się od zwykłej aplikacji webowej
Na demo SaaS wygląda jak każda inna aplikacja: logowanie, kilka ekranów, tabelki. Różnica leży w rzeczach, których na prezentacji nie widać, a które zjadają dużą część budżetu. Warto je znać, zanim porównasz wyceny, bo tańsza oferta często po prostu ich nie obejmuje.
- Wiele firm w jednym systemie. Każdy klient (firma, zespół, szkoła) ma swoje konto i nie może zobaczyć danych innych. Ta izolacja musi być wpisana w bazę danych i każde zapytanie, nie dopisana na końcu.
- Samodzielny start klienta. Rejestracja, potwierdzenie e-maila, pierwsze kroki w aplikacji i zaproszenie współpracowników bez rozmowy z Tobą. Od tego, jak dobrze działa pierwsze 10 minut, zależy, ile kont próbnych zamieni się w płatne.
- Rozliczenia. Plany cenowe, okres próbny, zmiana planu w trakcie miesiąca (z proporcjonalnym przeliczeniem), odrzucona karta, ponowienie płatności, blokada konta po kilku nieudanych próbach. Każdy z tych scenariuszy trzeba zaprojektować i przetestować.
- Role w obrębie konta. Właściciel, administrator, zwykły użytkownik, czasem gość z dostępem tylko do odczytu. Klienci biznesowi pytają o to bardzo szybko.
- Panel operatora. Ty i Twój zespół musicie widzieć konta klientów, przedłużyć komuś okres próbny, pomóc w problemie. Bez takiego panelu każda prośba klienta kończy się na programiście.
- Liczby. Ile osób się zarejestrowało, ile zaczęło korzystać, ile płaci, ile zrezygnowało. Bez tego nie wiesz, co poprawiać.
MVP: co budować w pierwszej wersji, a co odłożyć
Najczęstszy błąd przy SaaS to próba zbudowania od razu produktu „jak konkurencja, tylko lepszego”. Konkurencja rozwijała go latami. Pierwsza wersja ma udowodnić jedno: że ktoś zapłaci za rozwiązanie konkretnego problemu. Dlatego robimy jeden główny proces od początku do końca, razem z płatnością, a resztę odkładamy.
| Obszar | W pierwszej wersji | Może poczekać |
|---|---|---|
| Logowanie | e-mail i hasło lub link logujący, logowanie przez Google | SSO dla korporacji (SAML), weryfikacja dwuetapowa wymuszana na całe konto |
| Cennik | jeden lub dwa plany, okres próbny | rozliczenia roczne, kody rabatowe, opłaty za zużycie |
| Rozliczenia | gotowy ekran płatności i portal klienta operatora płatności | własny, dopracowany ekran zarządzania subskrypcją |
| Obsługa klientów | prosty panel operatora, część rzeczy robiona ręcznie | pełna automatyzacja wyjątków |
| Dane | eksport do CSV | integracje z innymi systemami, publiczne API |
| Urządzenia | aplikacja webowa działająca dobrze na telefonie | osobna aplikacja mobilna |
Rzeczy z prawej kolumny nie znikają, tylko czekają, aż pierwsi płacący klienci powiedzą, której z nich naprawdę potrzebują. Często okazuje się, że zupełnie innej.
Płatności, faktury i podatki w Polsce
Ta część najczęściej zaskakuje założycieli, bo sam operator płatności nie załatwia wszystkiego.
- Subskrypcje. Najczęściej korzystamy ze Stripe, który obsługuje plany, okresy próbne i ponawianie nieudanych płatności. Za karty z Europejskiego Obszaru Gospodarczego płacisz 1,5% + 1 zł od transakcji, a moduł subskrypcji kosztuje dodatkowo 0,7% obrotu (stawki z cennika Stripe na 2026 rok, warto je sprawdzić przed startem). Przy subskrypcjach podstawą są karty. BLIK sprawdza się przy płatnościach jednorazowych, a cykliczny BLIK oferują tylko niektóre polskie bramki.
- Faktury VAT i KSeF. Stripe nie wystawia polskich faktur, które trafią do Krajowego Systemu e-Faktur. Od 2026 roku faktury dla firm w Polsce przechodzą przez KSeF, dlatego łączymy rozliczenia z programem do fakturowania (np. przez API), który wysyła faktury do KSeF automatycznie po każdej płatności. Jak to wygląda technicznie, opisujemy na stronie integracja KSeF.
- Klienci z innych krajów UE. Firmy z numerem VAT UE rozlicza się zwykle w mechanizmie odwrotnego obciążenia, a klientom prywatnym nalicza się VAT kraju klienta (procedura OSS). Aplikacja musi zbierać odpowiednie dane przy zakupie, a szczegóły warto ustalić z księgowym jeszcze przed startem.
Jeśli Twoi klienci to firmy, które płacą przelewem na fakturę, a nie kartą, pierwsza wersja może w ogóle nie mieć automatycznych płatności. Ręczne fakturowanie kilkunastu klientów to rozsądny kompromis, dopóki nie wiesz, czy produkt się sprzedaje.
Fundamenty, które nie zablokują wzrostu
Nie budujemy MVP „na brudno, potem się przepisze”, bo potem nigdy nie ma na to czasu. Nie budujemy też infrastruktury dla miliona użytkowników, bo za nią płacisz od pierwszego dnia. Kilka decyzji trzeba jednak podjąć dobrze od początku:
- Model danych z podziałem na konta klientów. W większości produktów wystarcza jedna baza, w której każdy rekord należy do konkretnego konta. Osobne bazy dla każdego klienta mają sens dopiero przy dużych klientach z wymaganiami prawnymi.
- Dane w Unii Europejskiej i RODO. Jako dostawca SaaS przetwarzasz dane swoich klientów w ich imieniu, więc potrzebujesz umowy powierzenia przetwarzania danych, a klienci biznesowi zapytają o nią przed zakupem. Hosting w UE, kopie zapasowe i dziennik ważnych zmian ułatwiają odpowiedź na ich pytania.
- Włączanie funkcji dla wybranych kont. Nową funkcję możesz najpierw udostępnić kilku zaufanym klientom, a dopiero potem wszystkim.
- Automatyczne testy kluczowych ścieżek: rejestracji, płatności i dostępu do danych. Błąd, w którym jeden klient widzi dane drugiego, to w SaaS najgorszy możliwy scenariusz.
Ile kosztuje i co wpływa na cenę
MVP aplikacji SaaS budujemy od 20 000 zł netto. W tej kwocie mieści się jeden główny proces, konta firmowe z rolami, subskrypcja z okresem próbnym i podstawowy panel operatora. Cenę podnoszą przede wszystkim:
- liczba różnych typów użytkowników (np. firma, jej pracownicy i jej klienci to w praktyce trzy aplikacje),
- integracje z zewnętrznymi systemami, zwłaszcza takimi bez dobrej dokumentacji,
- praca w czasie rzeczywistym (czat, wspólna edycja, mapy na żywo),
- raporty i rozbudowane uprawnienia,
- aplikacja mobilna obok webowej.
Po starcie dochodzą koszty stałe: serwery (na początku zwykle od kilkudziesięciu do kilkuset złotych miesięcznie), wysyłka e-maili, prowizje operatora płatności i dalszy rozwój. Szczegółowo rozpisujemy to w poradniku ile kosztuje aplikacja webowa.
Twój produkt, Twój kod
Repozytorium kodu, konto w chmurze, konto operatora płatności i domena są zakładane na Ciebie albo od razu przekazywane. To ważne, gdy będziesz szukać inwestora: przy weryfikacji spółki pytanie „do kogo należy kod?” pada zawsze. Po starcie możemy dalej rozwijać produkt albo przekazać go Twojemu zespołowi, razem z dokumentacją.
Najczęstsze pytania
Czy nie wystarczy narzędzie no-code, np. Bubble?
Na sprawdzenie pomysłu czasem tak, zwłaszcza gdy budujesz sam i bez budżetu. Problemy pojawiają się później: koszt rośnie z liczbą użytkowników, trudniej o wydajność i nietypowe funkcje, a kodu nie da się przenieść gdzie indziej. Jeśli masz już klientów gotowych płacić, zwykle taniej jest od razu zbudować produkt na własnym kodzie.
Ile trwa zbudowanie MVP?
Zależy od zakresu, dlatego zaczynamy od jego spisania. Po tym etapie dostajesz listę funkcji, harmonogram i cenę, zanim zaczniemy programować. Im ciaśniej przytniemy pierwszą wersję, tym szybciej trafi do pierwszych klientów.
Mam już prototyp lub działającą aplikację. Przejmiecie ją?
Tak, ale najpierw przeglądamy kod i infrastrukturę. Po przeglądzie mówimy wprost, co warto zostawić, co poprawić, a co lepiej przepisać, i ile to kosztuje.
Czy zbudujecie też aplikację mobilną?
Tak. Aplikacja mobilna może korzystać z tego samego API i tej samej bazy co wersja webowa, więc nie budujemy wszystkiego dwa razy. Więcej na stronie aplikacje mobilne.