Jak zbudować SaaS – najem, rozliczenia i co sprawia, że ​​jest to produkt

MVP odpowiada: czy ktoś dokończy tę pracę? Odpowiedź SaaS: czy wiele firm będzie nadal płacić za to, abyśmy mogli uruchomić dla nich jedną bazę kodu? To drugie pytanie nie brzmi „dodaj Stripe i zaloguj się”. To najem, fakturowanie, wdrażanie i sposób na pomoc nieznajomemu o 2 w nocy bez konieczności przesyłania danych przez SSH.

Już pisałem jak wybrałbym stack na MVP. To jest kolejna warstwa: gdy biznes kształtuje się jako oprogramowanie jako usługa, co tak naprawdę zbudowałbym, w jakiej kolejności i czego nie chciałbym kopiować z Linear lub Salesforce w pierwszym miesiącu.

1. Po pierwsze: czy to rzeczywiście SaaS?

Wiele „SaaS pomysłów” to system szyty na miarę dla jednego klienta z miesięczną fakturą. To może być dobry biznes. To nie jest SaaS. SaaS oznacza jeden produkt, wielu najemców, sprzedaż samoobsługową lub typu light-touch, a koszt dołączenia kolejnej firmy jest bliski zeru – a nie kolejny projekt.

• SaaS: wiele organizacji, te same funkcje, rozliczenia w produkcie, czas sprawności należy do Ciebie.
• Oprogramowanie na zamówienie: jeden kupujący, unikalne przepływy pracy, fakturujesz za żądania zmian. Nie udawaj, że drugi klient „po prostu się zaloguje”.
• Jeśli każdy z pierwszych trzech klientów potrzebuje widelca, przestań nazywać go SaaS. Sprzedawaj projekty, aż nakładanie się będzie oczywiste - następnie wyodrębnij produkt.

2. Jednostką produktu jest przestrzeń robocza, a nie użytkownik

Modelowałbym domenę wokół organizacji (przestrzeń robocza, najemca, konto — wybierz jedno słowo i zachowaj je). Użytkownicy należą do organizacji. Dane należą do organizacji. Rachunki należą do organizacji. Jeśli zaczniesz od „Użytkownik ma projekty”, spędzisz sześć miesięcy na szukaniu zespołów, zaproszeń i „kto płaci”.

• Organizacja ma plan, adres e-mail dotyczący rozliczeń i status: próbny, aktywny, przeterminowany, anulowany.
• Członkostwo to rząd: użytkownik + organizacja + rola (na początek wystarczą właściciel, administrator, członek).
• Każda tabela biznesowa ma identyfikator org_id. Zapytania bez identyfikatora org to błędy, a nie skróty.
• Zaproszenia przed „utwórz dla nich użytkownika”. Wyślij e-mail, zaakceptuj i wejdź do odpowiedniego obszaru roboczego.

3. Dzierżawa: wspólna baza danych, ścisła izolacja

Przez pierwsze SaaS nie otwierałbym Postgresu na jednego klienta. Użyłbym jednej bazy danych, org_id w każdym wierszu i dogłębnej obrony, aby pominięte WHERE nie mogło stać się wyciekiem danych. Baza danych na dzierżawcę służy do regulowanej izolacji lub hałaśliwych sąsiadów, których już zmierzyłeś, a nie do dzierżawy numer cztery.

• Zabezpieczenia na poziomie wiersza lub równoważny pomocnik zapytań, który zawsze wstrzykuje org_id z sesji, a nie z treści klienta.
• Identyfikatory, których nie można odgadnąć (UUID). Sekwencyjne /org/12/invoices/4 to zaproszenie.
• Miejsce na pliki z prefiksem org_id, podpisane adresy URL, nigdy publiczny zbiór „wszystkich przesłanych plików”.
• Schemat na dzierżawcę lub DB na dzierżawcę tylko wtedy, gdy wymusza to umowa, lista kontrolna zgodności lub naprawdę hałaśliwy sąsiad. Migracje pomiędzy 200 schematami to produkt, którego nie chciałeś.

4. Płatności to funkcja, a nie wtyczka, którą dodasz później

Jeśli nikt nie może zapłacić, nie masz SaaS. W drugim tygodniu umieściłbym usługę Checkout na ścieżce krytycznej, nawet jeśli reszta aplikacji jest niewielka. Faza „wystawiamy faktury ręcznie” jest dozwolona dla pierwszych pięciu partnerów projektowych – wtedy karta musi zadziałać.

• Stripe Billing (lub procesor, z którego faktycznie korzysta Twój pierwszy rynek): produkty, ceny, portal klienta, webhooki. Nie przechowuj numerów kart. Nie pisz silnika monitującego.
• Jeden lub dwa plany, a nie siedem. Próba z wiadomym zakończeniem. Po okresie próbnym: tylko do odczytu lub blok twardy — wybierz jeden i wypowiedz go w interfejsie użytkownika.
• Wyceniaj coś, co klienci rozumieją: miejsca, projekty lub miesięczny wolumen. Rozliczenia za użytkowanie są potężne i łatwe do popełnienia błędu; zacznij od siedzenia lub płaskiego planu, aż dowiesz się, co to w ogóle jest „użytkowanie”.
• Webhooki są źródłem prawdy o tym, „czy są płatne?” Twoja baza danych odzwierciedla Stripe (lub Paddle). Cron, który zgaduje, w jaki sposób blokujesz płacącego klienta.

5. Stos, którego użyłbym (i czym różni się od MVP witryny)

Domyślne ustawienia sieciowe nadal obowiązują: Next.js, TypeScript, Tailwind, Postgres. SaaS dodaje kilka elementów, których witryna marketingowa nie potrzebuje – i nadal nie potrzebuje siatki usług.

• Autoryzacja, która rozumie organizacje: Clerk, WorkOS, Auth.js plus tabela członkostwa – ani jednej globalnej flagi „zalogowany”.
• Zadania w tle pierwszego dnia, jeśli coś jest powolne lub można ponowić próbę: e-maile, Stripe webhooki, eksporty, LLM połączenia. Prosta kolejka (Inngest, Trigger.dev lub proces roboczy na VPS) przewyższa setTimeout w funkcji bezserwerowej.
• E-mail transakcyjny od pierwszej minuty: zaproszenie, potwierdzenie, „Twój okres próbny kończy się w piątek”. Jeśli ta poczta nie dotrze, produkt będzie sprawiał wrażenie martwego.
• Flagi funkcji dla planów (can_export, seat_limit), a nie if (org.plan === "pro") rozproszone w pięćdziesięciu plikach.
• Hosting: Vercel plus hostowany Postgres jest w porządku, dopóki pracownik lub miejsce zamieszkania nie powie inaczej. Jeden region wystarczy. Wieloregionowość to późniejszy problem.

6. Onboarding to produkt na pierwszą godzinę

Puste dashboardy SaaS nie podlegają konwersji. Pierwszą sesję zaprojektowałbym jako pracę, a nie wycieczkę: utwórz obszar roboczy, zaimportuj lub wpisz pierwszy prawdziwy rekord, zaproś jednego członka zespołu, zobacz jeden wynik. Etykietki narzędzi nad pustą tabelą nie są wprowadzane.

• Przykładowy obszar roboczy jest dozwolony, jeśli jest wyraźnie fałszywy i dzieli Cię jedno kliknięcie od „zacznij od moich danych”.
• Wskaźnik aktywacji: raz wykonali podstawową pracę, a nie „zarejestrowali się”. Śledź to. Podrzuć to.
• Ustawienia mogą być brzydkie. Pusty stan ekranu głównego nie jest możliwy.

7. Ops: jak będziesz wspierać ludzi, których nigdy nie spotkałeś

W dniu, w którym organizacja płacąca napisze: „Nie widzę moich faktur”, potrzebujesz ścieżki innej niż produkcyjne SSH. Dodałbym cienkiego administratora wewnętrznego przed dziesiątym klientem, a nie po pierwszym incydencie.

• Administrator: znajdź organizację, zobacz plan i ostatni webhook, podszyj się pod osobę tylko do odczytu, wyślij ponownie zaproszenie. Sprawdź to podszywanie się.
• Dzienniki z identyfikatorem org_id i identyfikatorem żądania. „Nie udało się” bez najemcy to nie logika, to wzruszenie ramionami.
• Kopie zapasowe, które przywróciłeś raz. Na początek wystarczy noc; nieprzetestowane kopie zapasowe to historia, którą sam sobie opowiadasz.
• Strona stanu może poczekać. Wiadomość e-mail „nie działamy, oto, co wiemy” nie może zostać wysłana.

8. Czego nie zbudowałbym w pierwszym roku

Wielka SaaS to muzeum cech, które później zaprocentowały. Kopiowanie muzeum to strata jednej pracy.

• SSO, SCIM i 40-stronicowy kwestionariusz bezpieczeństwa, dopóki nie zostanie na nich zablokowana prawdziwa transakcja. Wtedy stają się sprintem, a nie zadaniem pobocznym.
• Publiczny API i rynek integracji. Jeden Zapier lub eksport CSV często odblokowuje tego samego kupującego.
• Domeny niestandardowe dla najemców, white-label i studio tematyczne. W przypadku większości wczesnych transakcji B2B wystarczy przesłanie logo.
• Sztuczna inteligencja wszędzie. Jedno miejsce, w którym najważniejszy jest język (wyszukiwanie, wersje robocze, ekstrakcja) ze schematem i płatnym licznikiem. Nie bańka czatu na każdym ekranie.

9. Sekwencja, której faktycznie bym przestrzegał

Taka sama uczciwość kalendarza jak MVP, z kamieniami milowymi w kształcie SaaS. Jeśli w tygodniu nie ma najemcy, wynagrodzenia ani pracy, nie jest to tydzień SaaS.

• Tydzień 0: podaj nazwę pracy, kupującego, plan, liczbę zabójstw (np. pięć płatnych organizacji w 90 dni lub przestaniemy). Brak celów na stronie.
• Tygodnie 1-2: organizacja + członkostwo + jedna szczęśliwa ścieżka w produkcji + Stripe tryb testowy. Testy izolacyjne: użytkownik A nie może widzieć użytkownika B.
• Tygodnie 3-4: rozliczenia na żywo, zaproszenia, e-maile, wdrożenie w stanie pustym, cienki administrator. Przedstaw to wymienionym firmom, a nie „internetowi”.
• Dni 30–90: aktywacja oglądania i przyczyny rezygnacji. Dodaj jedną integrację lub raport, za który płacą. Nie dodawaj drugiego produktu.

Wniosek: wynajmij pracę, a nie platformę

Zbudowałbym SaaS w ten sam nieestetyczny sposób, co MVP, plus części, które sprawiają, że wiele firm korzysta z jednego systemu: przestrzeń robocza, rachunek, ściana między najemcami, pierwsza godzina, która nie jest pusta, oraz administrator, więc wsparcie nie jest powłoką root. Stos może pozostać nudny. Produkt nie może pozostać niejasny.

Jeśli masz przepływ pracy, za jego powtarzanie kilka firm już płaci i chcesz, aby był to produkt, a nie sterta niestandardowych wdrożeń – napisz w sekcji kontaktów. Możemy nazwać model najemcy, pierwszy plan i wycinek, który bierze kartę, bez udawania Salesforce.