Aplikacja SaaS — jak zbudować własny produkt od MVP do płatności cyklicznych

Aplikacja SaaS to oprogramowanie, które sprzedajesz w abonamencie, a nie oddajesz klientowi po zakończeniu projektu. Ta jedna różnica zmienia prawie wszystko: jak liczysz koszty, co musi znaleźć się w pierwszej wersji, jak pobierasz pieniądze i jakie dokumenty prawne musisz mieć, zanim pierwszy klient kliknie „Zapłać”.

Ten tekst jest dla osób, które mają pomysł na własny produkt i chcą wiedzieć, z czego składa się zbudowanie go w Polsce w 2026 roku. Opieramy się na przepisach w obowiązującym brzmieniu, dokumentacji operatorów płatności, naszym raporcie o kosztach aplikacji webowych i na własnym doświadczeniu: prowadzimy produkt SaaS — DVN Links — i nasza strona sama korzysta z jego API. Nie znajdziesz tu wymyślonych historii klientów ani obietnic przychodu.

Czym aplikacja SaaS różni się od aplikacji na zamówienie

Aplikację na zamówienie budujesz dla jednego klienta. Ma jeden zestaw wymagań, jeden budżet i moment odbioru, po którym przechodzi w utrzymanie. Aplikacje SaaS działają inaczej w trzech punktach.

Jeden kod, wielu klientów. Każda firma, która zakłada konto, korzysta z tej samej aplikacji, na tych samych serwerach. Dane klientów muszą być od siebie oddzielone, a zmiana wprowadzona dla jednego trafia do wszystkich. Sposób, w jaki się to robi — jedna baza z identyfikatorem klienta w każdym rekordzie czy osobne bazy — opisujemy w tekście o architekturze multi-tenant.

Abonament zamiast jednorazowej płatności. Klient płaci co miesiąc albo co rok i w każdej chwili może zrezygnować. Oznacza to, że przychód zależy od tego, ilu klientów zostaje, a nie tylko od tego, ilu przyszło — i że płatności cykliczne, faktury oraz obsługa nieudanych obciążeń są częścią produktu, a nie dodatkiem.

Rozwój bez daty zakończenia. Produkty SaaS nie mają „odbioru”. Po pierwszej wersji przychodzą poprawki, nowe funkcje, zmiany cennika i aktualizacje bezpieczeństwa. Koszt budowy to tylko początek; koszt utrzymania i rozwoju płacisz tak długo, jak produkt działa.

Jeśli dopiero zastanawiasz się, czy twój problem wymaga własnego produktu, czy wystarczy gotowe narzędzie, zacznij od przewodnika po SaaS i porównania z oprogramowaniem dedykowanym.

Pięć elementów, bez których nie działa żaden produkt SaaS

Niezależnie od tego, czy budujesz narzędzie do fakturowania, rezerwacji czy skracania linków, pod spodem są te same pięć klocków. Klient ich nie kupuje — kupuje funkcję, która rozwiązuje jego problem — ale bez nich tej funkcji nie da się sprzedać.

1. Konta i organizacje

Użytkownik zakłada konto, loguje się, resetuje hasło. W produktach B2B dochodzi poziom wyżej: organizacja, do której należy kilka osób i która jest właścicielem danych oraz subskrypcji. Decyzję, czy konto należy do osoby, czy do firmy, trzeba podjąć na początku — późniejsza zmiana oznacza przebudowę bazy danych.

2. Rozliczenia

Plany, ceny, okres próbny, zmiana planu w trakcie okresu, nieudana płatność i ponowna próba, faktura. W większości przypadków nie buduje się tego od zera, tylko korzysta z usługi operatora płatności, ale integracja nadal jest pracą. W naszym kalkulatorze kosztu aplikacji opisujemy ją tak: „Integracja płatności wymaga obsługi webhooków, logiki idempotentności i testów compliance — to nie tylko osadzenie widżetu checkout.”

3. Uprawnienia

Kto w organizacji może zapraszać ludzi, kto widzi faktury, kto może usunąć dane. Na start często wystarczą dwie role — właściciel i członek zespołu. Rozbudowany system ról przydaje się dopiero wtedy, gdy klienci zaczynają o niego prosić.

4. Panel administratora

Twój własny panel, w którym widzisz klientów, ich plany i płatności, możesz przedłużyć komuś okres próbny, zablokować konto albo sprawdzić, dlaczego klient zgłasza błąd. Bez niego każda sprawa klienta kończy się ręcznym zapytaniem do bazy danych.

5. E-maile transakcyjne

Potwierdzenie rejestracji, reset hasła, zaproszenie do zespołu, potwierdzenie płatności, informacja o nieudanym obciążeniu karty. To nie jest marketing — to wiadomości, bez których klient nie wie, co się dzieje z jego kontem.

Co można odłożyć na później

Trzy rzeczy, które często trafiają do planu pierwszej wersji, a rzadko są potrzebne na start:

• aplikacja mobilna — dobrze zrobiona aplikacja webowa działa w przeglądarce telefonu; osobną aplikację warto budować, gdy wiesz, że klienci jej naprawdę używają w terenie;
• publiczne API — ma sens, gdy klienci chcą łączyć twój produkt z własnymi systemami; wcześniej to dodatkowa powierzchnia do utrzymania i zabezpieczenia;
• drugi język — tłumaczenie interfejsu, e-maili, regulaminu i obsługi klienta to kilka osobnych zadań; jeśli pierwsi klienci są w Polsce, polska wersja wystarczy.

MVP aplikacji SaaS — co wchodzi w pierwszą wersję

MVP, czyli minimalna wersja produktu, ma odpowiedzieć na jedno pytanie: czy ktoś zapłaci za rozwiązanie tego problemu. Szerzej o tym, jak planować taką wersję, piszemy w tekście o MVP. W przypadku SaaS zasada jest prosta: pięć klocków opisanych wyżej plus jedna funkcja, dla której klient w ogóle przychodzi. Wszystko inne czeka, aż pierwsi płacący klienci powiedzą, czego im brakuje.

Najczęstszy błąd przy MVP aplikacji to budowanie wszystkich funkcji z pomysłu, zanim ktokolwiek z nich skorzystał. Drugi — pominięcie rozliczeń „bo na razie damy za darmo”. Jeśli produkt ma zarabiać na abonamencie, to właśnie płatność jest najważniejszym testem MVP.

Plan darmowy i limity jako mechanizm sprzedaży

W wielu aplikacjach SaaS cennik nie jest listą funkcji, tylko listą limitów. Dobrze to widać w cenniku naszego produktu, DVN Links — polskiej platformy do skracania linków z analityką i kodami QR. Według cennika (odczyt 30.09.2026):

• Darmowy — 0 zł/mies.: 50 linków miesięcznie, 1 000 kliknięć miesięcznie, podstawowe statystyki z 7 dni, bez dostępu do API; linki w planie darmowym są ważne przez 30 dni;
• Starter — 39 zł/mies.: 500 linków, 10 000 kliknięć, statystyki z 30 dni, dostęp do API;
• Pro — 79 zł/mies., oznaczony jako najpopularniejszy: 2 000 linków, 50 000 kliknięć, statystyki z 90 dni, API do 10 000 zapytań na godzinę, 7 dni okresu próbnego;
• Business — 199 zł/mies.: 10 000 linków, 250 000 kliknięć, statystyki z 365 dni, API do 50 000 zapytań na godzinę, dedykowany opiekun;
• Enterprise — cena indywidualna, bez limitu zapytań API, SLA w umowie.

Przy płatności rocznej cena jest niższa o 20%. Każdy plan to ta sama aplikacja — różnią się liczby. Plan darmowy pozwala sprawdzić produkt bez karty, a limity (liczba linków, czas przechowywania statystyk, dostęp do API) wyznaczają moment, w którym klientowi opłaca się przejść wyżej. Dla MVP oznacza to jedną ważną rzecz: mechanizm limitów trzeba zaprojektować od początku, nawet jeśli na starcie jest tylko jeden plan płatny. Więcej o tym, kiedy plan darmowy pomaga, a kiedy tylko kosztuje, piszemy w tekście o modelu freemium.

Płatności cykliczne w Polsce: Stripe, PayU, Przelewy24

Płatności cykliczne to automatyczne obciążanie klienta co miesiąc lub co rok, po tym, jak raz wyraził na to zgodę. W Polsce masz do wyboru kilku operatorów, a różnią się nie tylko ceną, ale też tym, które metody płatności działają cyklicznie.

Stripe Billing — Stripe w Polsce

Stripe pozwala założyć konto firmom z Polski — Polska jest na liście krajów na stronie Stripe Global. Za subskrypcje odpowiada moduł Stripe Billing. Dokumentacja opisuje go tak: „Subscriptions let customers make recurring payments to access a product or service. When you create a subscription, Stripe automatically generates invoices, attempts payment collection, and manages the subscription status throughout its lifecycle.” (tłumaczenie własne: „Subskrypcje pozwalają klientom płacić cyklicznie za dostęp do produktu lub usługi. Gdy tworzysz subskrypcję, Stripe automatycznie generuje faktury, próbuje pobrać płatność i zarządza statusem subskrypcji przez cały cykl jej życia”). Stripe przejmuje też ponawianie nieudanych płatności (dokumentacja Stripe Billing).

Opłaty według polskiego cennika Stripe (odczyt 30.09.2026):

• karty krajowe i z EOG (standardowe): 1,5% + 1,00 zł;
• karty premium z EOG: 1,9% + 1,00 zł; karty z Wielkiej Brytanii: 2,5% + 1,00 zł; karty międzynarodowe: 3,25% + 1,00 zł; przewalutowanie: dodatkowo 2%;
• BLIK: 1,6% + 1,00 zł; Przelewy24: 1,9% + 1,00 zł;
• Billing (pay as you go): 0,7% wartości obsługiwanej przez Billing — to opłata doliczana do opłaty za samą płatność.

Ważne zastrzeżenie dotyczy BLIK-a. W dokumentacji BLIK w Stripe płatności cykliczne są oznaczone jako „Recurring payments: Yes (Private preview)” — czyli dostępne w wersji testowej dla wybranych kont, a nie dla wszystkich. Jeśli twoi klienci mają płacić cyklicznie BLIK-iem, sprawdź przed wyborem operatora, czy twoje konto ma do tego dostęp.

PayU

PayU obsługuje płatności cykliczne kartą na podstawie tokenów wielokrotnego użytku: „All transactions, except of the first one, are not initiated by the cardholder.” (tłumaczenie własne: „Wszystkie transakcje poza pierwszą nie są inicjowane przez posiadacza karty”). Przed integracją trzeba skontaktować się z PayU w celu konfiguracji usługi (dokumentacja PayU — płatności cykliczne kartą). PayU obsługuje też cykliczny BLIK: pierwszą płatność inicjuje klient, kolejne pobiera sprzedawca. Aktywacja wymaga jednak, jak pisze dokumentacja, podpisania aneksu do istniejącej umowy (dokumentacja PayU — BLIK cykliczny).

Przelewy24

Przelewy24 opisują usługę tak: „Płatności rekurencyjne (cykliczne) to automatyczne pobieranie opłaty od klientów, którzy wyrazili na to zgodę. Usługa sprawdza się w przypadku płatności za abonamenty, karnety czy subskrypcje.” Jako metody wymieniają kartę płatniczą i BLIK (Przelewy24 — płatności cykliczne).

Faktury i KSeF

Operator płatności pobiera pieniądze, ale polską fakturę VAT dla klienta biznesowego musisz wystawić zgodnie z polskimi przepisami. Według Ministerstwa Finansów: „Obowiązek wystawiania faktur w KSeF wszedł etapami: od 1 lutego 2026 r. dla firm, które w 2024 r. miały sprzedaż powyżej 200 mln zł (z VAT), od 1 kwietnia 2026 r. dla pozostałych. Dodatkowo do 31 grudnia 2026 r. można jeszcze wystawiać faktury poza KSeF (papierowe lub elektroniczne), jeśli w danym miesiącu suma sprzedaży z VAT na takich fakturach nie przekroczy 10 000 zł.” (ksef.podatki.gov.pl). Od 1 stycznia 2027 KSeF jest obowiązkowy także dla przedsiębiorców wcześniej zwolnionych (etapy wdrożenia KSeF).

W praktyce oznacza to, że każda faktura za abonament B2B musi przejść przez KSeF. Przed wyborem narzędzia do rozliczeń sprawdź, czy twój system fakturowania — ten od operatora płatności albo księgowy, do którego go podłączysz — jest zintegrowany z KSeF.

Minimum prawne: regulamin, RODO i usługa cyfrowa

To, co poniżej, jest mapą obowiązków, a nie poradą prawną. Regulamin i dokumenty dotyczące danych osobowych daj do sprawdzenia prawnikowi, zanim przyjmiesz pierwszą płatność.

Regulamin świadczenia usług drogą elektroniczną

Każda aplikacja SaaS jest usługą świadczoną drogą elektroniczną, więc potrzebuje regulaminu. Art. 8 ust. 1 ustawy o świadczeniu usług drogą elektroniczną wymaga, żeby usługodawca określił regulamin i „nieodpłatnie udostępnia usługobiorcy regulamin przed zawarciem umowy”. Ust. 2 mówi, co grozi, gdy tego nie zrobi: „Usługobiorca nie jest związany tymi postanowieniami regulaminu, które nie zostały mu udostępnione” w ten sposób. Ust. 3 wymienia, co regulamin musi zawierać w szczególności: rodzaje i zakres usług, warunki ich świadczenia (w tym wymagania techniczne i zakaz dostarczania treści o charakterze bezprawnym), warunki zawierania i rozwiązywania umów oraz tryb postępowania reklamacyjnego (Dz.U. 2024 poz. 1513, tekst jednolity).

RODO w obie strony: administrator i podmiot przetwarzający

W aplikacji SaaS dla firm występujesz w dwóch rolach jednocześnie.

Wobec własnych użytkowników — osób, które zakładają konto — jesteś administratorem danych i przy zbieraniu danych musisz przekazać im informacje z art. 13 RODO: swoją tożsamość i dane kontaktowe, cele i podstawę prawną przetwarzania, odbiorców danych, a także m.in. okres przechowywania i przysługujące im prawa.

Wobec danych, które twoi klienci wgrywają do aplikacji — ich klientów, pracowników, kontrahentów — zwykle jesteś podmiotem przetwarzającym. Art. 28 ust. 3 RODO wymaga wtedy umowy powierzenia, która określa m.in. przedmiot i czas trwania przetwarzania, jego charakter i cel oraz rodzaj danych (RODO, EUR-Lex). W praktyce przygotowujesz jedną standardową umowę powierzenia, którą klient akceptuje razem z regulaminem. Twoi własni dostawcy — hosting, wysyłka e-maili, operator płatności — to z kolei twoi podwykonawcy, których klient musi zaakceptować. Jak ten układ wygląda od strony klienta, opisujemy w tekście o bezpieczeństwie danych w chmurze.

Klient konsument: usługa cyfrowa i prawo odstąpienia

Jeśli sprzedajesz także osobom prywatnym, dochodzi ustawa o prawach konsumenta w najnowszym tekście jednolitym (Dz.U. 2026 poz. 1244). Aplikacja SaaS mieści się w definicji usługi cyfrowej z art. 2 pkt 5a — to usługa pozwalająca konsumentowi na „wytwarzanie, przetwarzanie, przechowywanie lub dostęp do danych w postaci cyfrowej”. Umowy o dostarczanie usług cyfrowych reguluje rozdział 5b ustawy (art. 43h–43q). Z punktu widzenia produktu najważniejsze są trzy przepisy:

• usługę dostarczasz niezwłocznie po zawarciu umowy, chyba że strony postanowiły inaczej (art. 43j ust. 1);
• zmiana produktu, która nie jest potrzebna do utrzymania jego zgodności z umową, jest dozwolona „tylko jeżeli umowa tak stanowi i jedynie z uzasadnionych przyczyn w tej umowie wskazanych” i nie może wiązać się z kosztami dla konsumenta (art. 43p);
• jeśli zmiana „istotnie i negatywnie wpływa” na dostęp do usługi, konsument może wypowiedzieć umowę bez zachowania terminu w ciągu 30 dni (art. 43q ust. 2).

Przed zawarciem umowy na czas nieoznaczony albo przedłużanej automatycznie musisz też poinformować konsumenta o sposobie i przesłankach jej wypowiedzenia (art. 12 ust. 1 pkt 16).

Najwięcej wątpliwości budzi prawo odstąpienia od umowy. Konsument, który zawarł umowę na odległość, może od niej odstąpić w ciągu 14 dni bez podawania przyczyny (art. 27 ust. 1). Wyjątek z art. 38 ust. 1 pkt 1 dotyczy usług, które przedsiębiorca „wykonał w pełni” za wyraźną zgodą konsumenta. Abonament miesięczny czy roczny nie jest w pełni wykonany w ciągu pierwszych 14 dni. Naszym zdaniem oznacza to, że konsument, który zaczyna korzystać z aplikacji od razu, najczęściej zachowuje prawo odstąpienia — ale jeśli złożył żądanie rozpoczęcia usługi przed upływem tego terminu (art. 21 ust. 2), płaci za okres, z którego skorzystał, proporcjonalnie do ceny (art. 35). To nasza interpretacja, nie porada prawna: zapisy o odstąpieniu w regulaminie koniecznie skonsultuj z prawnikiem.

Ile kosztuje zbudowanie aplikacji SaaS

Najbardziej wiarygodnym punktem odniesienia dla polskiego rynku jest nasz raport „Koszty aplikacji webowych w Polsce — edycja 2026”. Zbiera 118 obserwacji cenowych od 92 podmiotów z okresu marzec–maj 2026. Dwie najliczniejsze próby dają dwa punkty orientacyjne:

• MVP: mediana 30 000 zł (n=24);
• aplikacja enterprise / multi-tenant: mediana 200 000 zł (n=43).

Zastrzeżenie: raport zestawia opublikowane cenniki i benchmarki firm z rynku, a nie faktury z zakończonych projektów, więc pokazuje, od jakich kwot firmy zaczynają rozmowę, a nie, ile ostatecznie zapłacili klienci. Nasze własne dane nie są wliczane do tych median. Pozostałe kategorie w raporcie mają zbyt małe próby, żeby na nich polegać.

Nasza linia cenowa: Lean MVP od 10 tys. zł — najprostsza wersja do sprawdzenia, czy ktoś w ogóle chce płacić — i MVP od 30 tys. zł, czyli pierwsza wersja z pięcioma klockami i główną funkcją. Każdy projekt wyceniamy indywidualnie, bo różnica między „prostym SaaS” a „prostym SaaS z płatnościami cyklicznymi, rolami i integracją z KSeF” to często kilka tygodni pracy. Wstępny szacunek dla swojego zakresu możesz policzyć w kalkulatorze kosztu aplikacji webowej. Kalkulator zakłada ok. 8 tygodni pracy dla bazowego MVP; raport podaje dla MVP 8–12 tygodni, ale bez liczebności próby dla tej wartości. Ogólniej o tym, co wpływa na cenę aplikacji, piszemy w tekście ile kosztuje stworzenie aplikacji.

Koszty po uruchomieniu

Produkt SaaS płaci rachunki co miesiąc: hosting i baza danych, usługa wysyłki e-maili, opłaty operatora płatności (w Stripe prowizja od każdej transakcji plus 0,7% za Billing), monitoring i kopie zapasowe. Do tego dochodzi czas programisty na poprawki, aktualizacje zależności i nowe funkcje. Jak zorganizować to po uruchomieniu, opisujemy w tekstach o opiece technicznej i o własnym hostingu na Coolify — to drugie rozwiązanie pozwala obniżyć rachunki za infrastrukturę, gdy produkt jest jeszcze mały.

Przykład: DVN Links i jego publiczne API

DVN Links to nasz własny produkt SaaS: „polska platforma do zarządzania linkami z analityką i kodami QR”. Na stronie produktu czytamy: „Dane przechowywane w UE. Pełna zgodność z RODO bez dodatkowych opłat.” (dvnlinks.pl). Cennik opisaliśmy wyżej — to przykład produktu, w którym plan darmowy i limity są głównym mechanizmem sprzedaży.

Publiczne API w praktyce

DVN Links udostępnia klientom REST API, opisane w dokumentacji w standardzie OpenAPI 3.1. Każde zapytanie wymaga klucza API przesłanego w nagłówku Authorization jako token Bearer. Limity zapytań zależą od planu, a API informuje o nich w nagłówkach odpowiedzi X-RateLimit-Limit, X-RateLimit-Remaining i X-RateLimit-Reset — dzięki temu program klienta wie, ile zapytań mu zostało i kiedy licznik się odnowi. Dostęp do API według cennika mają plany od Starter wzwyż.

To dobry przykład elementu, który odkłada się na później: API nie było potrzebne, żeby sprawdzić, czy ktoś chce płacić za krótkie linki. Stało się potrzebne, gdy produkt miał klientów, którzy chcieli tworzyć linki automatycznie ze swoich systemów — i wtedy stało się też kolejnym limitem, który odróżnia plany.

Co robi z tym API nasza strona

Najlepszym testem API jest korzystanie z niego samemu. Nasza strona — ta, którą czytasz — łączy się z DVN Links przez to samo publiczne REST API, które dostają klienci planów płatnych:

• tworzy krótki link przy publikacji artykułu lub strony i zapisuje go w dokumencie;
• przy każdej kolejnej publikacji sprawdza, czy link nadal istnieje;
• odtwarza link, jeśli ktoś usunął go w panelu DVN Links;
• aktualizuje adres docelowy, gdy zmieni się adres strony — stary krótki link działa dalej i prowadzi pod nowy adres;
• przejmuje stare linki, utworzone zanim strona zaczęła zapisywać ich identyfikatory: wyszukuje link po adresie docelowym i przypisuje go do dokumentu, zamiast tworzyć duplikat.

Błąd komunikacji z API nigdy nie blokuje zapisania artykułu — jest tylko odnotowywany. To zasada, którą warto przyjąć przy każdej integracji z zewnętrzną usługą: twoja aplikacja ma działać także wtedy, gdy druga strona chwilowo nie odpowiada. Czym jest API, jak działa webhook i jak zabezpieczyć integrację, wyjaśniamy w tekście o API.

Budować samemu, z software house'em czy z nami

Nie ma jednej dobrej odpowiedzi — jest kilka kryteriów, które warto przejść uczciwie.

Budujesz sam, jeśli jesteś programistą albo masz programistę w zespole założycielskim, a czas jest tańszy niż gotówka. Ryzyko: pięć klocków zajmie więcej czasu niż główna funkcja, a płatności i sprawy prawne zostaną „na później”.

Zaczynasz od narzędzi no-code lub low-code, jeśli chcesz sprawdzić popyt w kilka tygodni i akceptujesz, że pierwszą wersję prawdopodobnie przepiszesz. Kiedy to ma sens, a kiedy blokuje rozwój, opisujemy w tekście o low-code.

Wybierasz software house, jeśli masz dokładnie opisany zakres, budżet na pełną aplikację i własną osobę, która będzie prowadzić produkt po stronie biznesu. Dla takich projektów raport pokazuje medianę enterprise 200 000 zł (n=43).

Rozmawiasz z nami, jeśli chcesz zacząć od najmniejszej wersji, która przyjmuje płatności, i rozwijać produkt etapami. Sami prowadzimy produkt SaaS, więc płatności cykliczne, limity planów, API i obowiązki prawne znamy od strony właściciela, nie tylko wykonawcy. Szczegóły współpracy opisujemy na stronach MVP dla startupów i tworzenie aplikacji webowych. Jeśli nie wiesz jeszcze, czy potrzebujesz własnego produktu, czy wystarczy gotowe narzędzie, rozwiąż quiz: gotowy SaaS czy aplikacja na zamówienie.