SaaS
W produkcie SaaS od pierwszego dnia trzeba myśleć o wielu klientach naraz: izolacji danych, planach abonamentowych, onboardingu i odejściach. Zaczynamy od discovery i MVP, bo pierwsza hipoteza o tym, za co klienci zapłacą, prawie nigdy nie jest trafna — a w rozliczeniach abonamentów trudniejsze od płatności są zmiany planów, zawieszenia i zwroty.
Firmy które nam zaufały
Podstawy
Co znaczy zbudować SaaS i czym to się różni od zwykłej aplikacji
SaaS to oprogramowanie sprzedawane w abonamencie, z którego korzysta wielu klientów naraz na jednej instalacji. Różnica wobec aplikacji na zamówienie nie polega na funkcjach, tylko na tym, że od pierwszego dnia trzeba rozwiązać rzeczy, których w aplikacji dla jednego klienta nie ma: rozdzielenie danych między firmami, konta i uprawnienia, rejestrację bez udziału człowieka, płatności cykliczne i to, co dzieje się po nieudanym obciążeniu karty.
To jest ta część, którą najczęściej się pomija przy szacowaniu. Sam pomysł produktowy bywa prosty; „obsłuż tysiąc firm naraz, każdą z własnymi danymi i własnym cennikiem" — nie jest.
Drugi element to fakt, że SaaS nigdy nie jest skończony. Klient płaci co miesiąc i co miesiąc ocenia, czy warto. Budżet na budowę bez budżetu na rozwój przez kolejne kwartały to najczęstsza przyczyna produktów, które ruszyły i ucichły.
Zobacz wybrane projekty dla naszych klientów
„Mimo ciągłych zmian w funkcjonalności systemu wspólnie z Boring Owl doprowadziliśmy go do wersji przeznaczonej do sprzedaży. Dla nas Boring Owl to nie tylko software house, ale też partner i doradca biznesowy. Dobrze doradzali na każdym etapie.”
Hubert Zaborowski — Co-Owner, SHM Sp. z o.o.
Opinia z Clutch (tłum. z angielskiego)
Przebieg
Od pierwszej wersji do pierwszych płacących klientów
Zaczynamy od zawężenia: jedna grupa odbiorców, jeden problem, jedna ścieżka, która musi zadziałać bezbłędnie. Pierwsza wersja ma odpowiedzieć na pytanie, czy ktoś zapłaci — a nie pokazać wszystko, co planujecie.
Potem budujemy rdzeń wraz z tym, co wynika z modelu abonamentowego: rejestracja, plany, płatności cykliczne, obsługa rezygnacji. Równolegle podstawy, bez których nie da się prowadzić produktu — logi, monitoring, miary użycia. To nie jest luksus; bez nich nie wiadomo, czego klienci używają, a czego nie.
Po Twojej stronie jest wiedza o odbiorcy i decyzja o modelu cenowym. Po naszej stronie architektura, budowa, wdrożenie i przekazanie albo dalszy rozwój.
Na czas wpływa liczba ról i to, jak bardzo plany różnią się między sobą. Trzy plany różniące się limitem są proste; trzy różniące się dostępnymi funkcjami mnożą liczbę stanów do sprawdzenia.
Decyzje
Decyzje, które ustawiają koszt na kolejne lata
Jak rozdzielić dane klientów. Wspólna baza z filtrowaniem po firmie jest tańsza i łatwiejsza w utrzymaniu; osobna baza na klienta daje mocniejsze rozdzielenie i bywa wymagana w regulowanych branżach. To decyzja architektoniczna, której zmiana później oznacza migrację wszystkich klientów naraz.
Model cenowy. Za użytkownika, za zużycie czy ryczałt — to nie jest tylko kwestia handlowa, bo określa, co system musi liczyć i pokazywać. Rozliczanie za zużycie wymaga wiarygodnego miernika od pierwszego dnia.
Co robicie, gdy płatność się nie uda. Odcięcie dostępu natychmiast, po tygodniu, ograniczenie funkcji. Brak decyzji oznacza, że ktoś będzie to obsługiwał ręcznie przy każdym przypadku.
Czego nie robić. Nie buduj wszystkich planów przed pierwszym klientem. Nie odkładaj miar użycia — bez nich rozwój produktu opiera się na przeczuciach. I nie zakładaj, że da się dołożyć rozdzielenie danych później; to jest fundament, nie warstwa wykończeniowa.
Zakres
Produkt SaaS od MVP po skalę
W produkcie SaaS od pierwszego dnia trzeba myśleć o wielu klientach naraz: izolacji danych, planach abonamentowych, onboardingu i odejściach. Zaczynamy od discovery i MVP, bo pierwsza hipoteza o tym, za co klienci zapłacą, prawie nigdy nie jest trafna — szybciej i taniej jest to sprawdzić na działającym minimum niż na rozbudowanym produkcie.
Architektura
Multi-tenancy, rozliczenia i to, co widać dopiero przy wzroście
Fundamenty kładziemy pod skalę, na którą produkt ma szansę: izolacja danych klientów, uprawnienia i role, limity per plan. W rozliczeniach abonamentowych trudniejsze od samej płatności są zmiany planów, zawieszenia i zwroty — projektujemy je od razu, bo dorabiane później kosztują wielokrotnie więcej.
Do tego zaplecze, bez którego SaaS nie działa na poważnie: monitoring, backupy z przetestowanym przywracaniem, deploy bez przestojów i środowisko testowe, na którym można bezpiecznie eksperymentować.
Przygotowujemy też dokumentację, o którą pytają więksi klienci przy zakupie — polityki, architekturę, procedury.
Wzrost
Onboarding, metryki i pętla iteracji
SaaS żyje z retencji: mierzymy aktywację (czy nowy użytkownik dochodzi do wartości), retencję kohort i punkty odejść. Onboarding traktujemy jako funkcję produktu — pierwsze minuty decydują, czy trial zamieni się w abonament. Iterujemy na danych produktowych, nie na życzeniach roadmapy.
Zespół zostaje przy produkcie po starcie — od poprawek po rozwój kolejnych modułów. Najdłużej prowadzone produkty rozwijamy latami, z tym samym zespołem, który je budował.
FAQ
Pytania, które słyszymy przed budową SaaS
SaaS to oprogramowanie udostępniane jako usługa: użytkownik korzysta z niego przez przeglądarkę, w modelu abonamentowym, a dostawca odpowiada za serwery, aktualizacje i kopie zapasowe. Skrót pochodzi od software as a service. Z perspektywy klienta znika instalacja i utrzymanie, z perspektywy twórcy — pojawia się obowiązek utrzymywania jednej działającej wersji dla wszystkich.
Najmocniej na koszt wpływa nie liczba funkcji, tylko wielodostępność i rozliczenia: obsługa wielu klientów w jednym systemie, izolacja ich danych, plany taryfowe i limity to praca, której nie widać w interfejsie. Doliczyć trzeba stały koszt utrzymania — infrastrukturę, monitoring i wsparcie — który przy SaaS jest częścią produktu, a nie dodatkiem po wdrożeniu. Pierwsza wersja obejmująca jeden proces od początku do końca pozwala sprawdzić model, zanim koszt urośnie.
Wspólna baza z rozdzieleniem danych na poziomie aplikacji jest tańsza w utrzymaniu i łatwiej ją aktualizować, bo wersja jest jedna. Osobne bazy dają mocniejszą izolację i bywają wymagane przy danych wrażliwych albo przez dział bezpieczeństwa klienta, ale każdy kolejny najemca to kolejne środowisko do utrzymania. Decyzję warto podjąć na starcie — zmiana modelu później oznacza migrację wszystkich klientów naraz.
Tyle, żeby jeden użytkownik mógł przejść swój proces od początku do końca i uzyskać z tego realną wartość. Wersja, która robi połowę drogi, nie da odpowiedzi na najważniejsze pytanie: czy ktoś za to zapłaci. Funkcje poboczne, panele administracyjne i integracje zwykle mogą poczekać na pierwszych płacących.
Zaczyna się właściwa praca: obsługa zgłoszeń, monitoring, poprawki i rozwój prowadzony na danych o tym, z czego użytkownicy faktycznie korzystają. SaaS nie ma etapu odbioru, po którym system zostaje sam — dostawca odpowiada za jego działanie stale. To trzeba uwzględnić w budżecie rocznym, nie tylko w koszcie budowy.
Zbudujmy wspólnie produkty cyfrowe dla Twojej firmy
Artykuły o produkcie
Interesuje cię budowa produktu SaaS?
Od pierwszego dnia myślimy o wielu klientach naraz: izolacji danych, planach abonamentowych i onboardingu. Zaczynamy od MVP.
Napisz do nas