Co zyskujesz

• Multi-tenant z dnia 1 — Architektura wspierająca wielu klientów na tej samej infrastrukturze. Izolacja danych, custom domains.
• Billing i subskrypcje — Stripe Billing, plany, free trial, upgrades/downgrades, pro-rata, faktury VAT zgodne z polskim prawem.
• Self-service onboarding — Klient zakłada konto, weryfikuje email, dodaje dane firmy, zaprasza zespół, płaci — bez handlowca.
• Product analytics — PostHog/Mixpanel — widzisz, co użytkownicy klikają, gdzie się gubią, którzy uciekają.
• Bezpieczeństwo — SOC 2 ready, GDPR/RODO compliant, encryption at rest, MFA, audit logs.
• Integracje i API — API publiczne dla klientów, webhooks, integracje (Zapier, Slack, Salesforce), SSO (SAML/OIDC).

Co dostajesz

• Discovery hipotezy biznesowej i target persona
• Architektura multi-tenant z planem skalowania
• MVP z core funkcjonalnością + billing Stripe
• Onboarding self-service i zaproszenia zespołu
• Panel admina dla zarządzania klientami
• Product analytics i email lifecycle
• Dokumentacja API + status page
• Plan rozwoju i pricing strategy

Czym SaaS różni się od zwykłej aplikacji webowej?

Wielu klientów myśli "mam aplikację webową = mam SaaS". To nieprawda. SaaS to specyficzny model biznesowy z własnymi wyzwaniami architektonicznymi.

Pierwsze: multi-tenancy. SaaS hostuje wielu klientów (tenantów) na tej samej infrastrukturze. Każdy klient widzi tylko swoje dane, ma swoich użytkowników, ewentualnie swój subdomain (klient1.app.com). Implementacja multi-tenancy z dnia 1 jest 30% droższa niż single-tenant — ale kosztuje 10x więcej, jeśli dorabia się ją po roku rozwoju (refactor całej bazy danych).

Drugie: billing recurring. Klient płaci miesięcznie/rocznie. Trzeba obsłużyć: free trial, upgrade planu w połowie miesiąca (pro-rata), downgrade, zawieszenie konta przy braku płatności (z grace period), faktury VAT, dunning emails (przypominanie o płatności), MRR/ARR raporting. To 20-30% kodu typowego SaaS.

Trzecie: self-service onboarding. Klient w zwykłej aplikacji enterprise jest "wdrażany" przez sprzedaż. W SaaS zakłada konto i zaczyna używać sam. Każda przeszkoda w pierwszych 5 minutach = utracony klient. Wymaga inwestycji w UX, dokumentację, tutoriale, sample data.

Czwarte: product analytics. SaaS musi mierzyć retention (DAU/MAU), feature adoption (które funkcje są używane), churn (kto rezygnuje i dlaczego). Bez analityki nie da się rozwijać produktu — zgadywanie zamiast danych.

Pricing SaaS — najtrudniejsza decyzja foundera

Pricing to obszar, gdzie founderzy najczęściej tracą pieniądze. Klasyczne błędy: zbyt niskie ceny ("muszę być konkurencyjny"), zbyt mało planów (jeden plan dla wszystkich), zbyt skomplikowane plany (10 wymiarów: użytkownicy × storage × API calls × integracje), brak free trial (klienci nie chcą kupić w ciemno), zbyt długi free tier (klienci nie konwertują na płatne).

Good pricing dla typowego B2B SaaS: 3 plany (Starter, Pro, Enterprise), różniące się 1-2 wymiarami (np. liczba użytkowników, liczba projektów). Free trial 14 dni z pełnym dostępem. Pricing widoczny na stronie (transparentność = trust). Annual billing z rabatem 20% (poprawia cash flow i retention).

Wielkość MRR per klient zależy od ICP (Ideal Customer Profile). Mały SaaS dla freelancerów: $20-50/mies. SMB SaaS: $50-300/mies. Mid-market SaaS: $300-2000/mies. Enterprise: $2000+/mies (often negotiated). Każdy z tych segmentów ma inną drogę sprzedaży, inne wymagania funkcjonalne, inne bariery wejścia.

My zwykle robimy 2-3 iteracje pricingu w pierwszym roku. Pierwsza wersja wychodzi na launch, po 3 miesiącach analiza (czy klienci konwertują, jakie plany wybierają, gdzie tracimy klientów na pricing'u), korekta. Po 6 miesiącach zwykle stabilizacja.

Skalowanie SaaS — od pierwszych klientów do tysięcy

Architektura SaaS skalującego się stopniowo: MVP→100 klientów→1k klientów→10k klientów. Na każdym etapie inne wyzwania.

Do 100 klientów (rok 1): focus na produkt-market fit. Architektura prosta, jeden serwer aplikacyjny + PostgreSQL, hosting Vercel/Supabase wystarcza. Czas dewelopera idzie w funkcje, nie infrastrukturę. Koszt operacyjny: $200-500/mies.

100-1k klientów (rok 2): początek skalowania. Wprowadzamy CDN dla static assets, Redis cache dla często używanych zapytań, dedicated email infrastructure (zamiast Resend/SendGrid free tier), monitoring (Sentry, DataDog). Architektura jeszcze monolitowa, ale przemyślana. Koszt operacyjny: $1-3k/mies.

1k-10k klientów (rok 3-4): problemy skalowania. Database już za mała na pojedynczym serwerze — read replicas, partitioning. Background jobs przenosimy do dedykowanego workera (BullMQ + Redis). API rate limiting per tenant. Multi-region deployment dla globalnych klientów. Koszt operacyjny: $5-20k/mies.

10k+ klientów: każdy SaaS jest unikalny na tym etapie. Często microserwisy dla części obciążenia, dedicated infrastructure dla enterprise klientów, custom contracts, dedicated DevOps team. To już nie startup, to scale-up.

Najczęstsze pytania

Co to znaczy "multi-tenant"?

Architektura, w której jedna instancja aplikacji obsługuje wielu klientów (tenantów). Każdy klient widzi tylko swoje dane, ale fizycznie wszystko działa na tej samej infrastrukturze. Standardowy model dla SaaS — bez tego każdy nowy klient = osobny serwer (zbyt drogie).

Stripe vs polskie systemy billingowe?

Stripe — najlepszy globalnie, świetne API, problemy w PL: brak natywnego BLIK-a (jest, ale przez ekstra plugin), faktury VAT wymagają osobnego rozwiązania. Tpay/PayU/Przelewy24 — natywny PL, ale słabsze API, mniej funkcji billing. Dla globalnego SaaS — Stripe + osobne fakturowanie. Dla SaaS PL-only — Tpay + custom billing.

Ile kosztuje hosting SaaS-a?

MVP (do 100 użytkowników): $200-500/mies. SaaS średni (do 1000 użytkowników): $1-3k/mies. Większy: $5-20k/mies. Enterprise z multi-region: $20k+/mies. Pro tip: Vercel + Supabase są ~3x droższe niż AWS dla większych SaaS-ów, ale 10x prostsze w utrzymaniu.

Jak SaaS radzi sobie z RODO?

Standardowo: dane w UE (Vercel EU, Supabase EU, AWS EU regions), Data Processing Agreement z każdym klientem, retention policy, prawo do usunięcia, eksport danych. Dla enterprise: SOC 2 audit, dedicated data residency.

Co to jest churn i dlaczego ważny?

Churn = % klientów, którzy rezygnują w danym okresie. Dla B2B SaaS: dobry churn 1-2%/mies, akceptowalny do 5%, ponad to — produkt ma problem. Churn × LTV = realny revenue per client. Bez niskiego churn'u SaaS się nie skaluje.

Czy budujecie też mobile app dla SaaS-a?

Tak — najczęściej React Native (jeden codebase iOS+Android). Dla SaaS-a typowo robimy web app jako primary, mobile jako "companion" dla najczęściej używanych funkcji. Pełna funkcjonalność na mobile to osobny duży projekt.

Czy mogę zacząć z prostszym MVP i skalować?

Tak — to nasza preferowana ścieżka. MVP w 8-12 tygodni żeby sprawdzić rynek, potem iteracyjny rozwój. Architektura od pierwszego dnia jest "skalowalna" (multi-tenant), ale nie nadmierna (brak microserwisów dla 10 użytkowników).