Як я б збирала SaaS: тенанти, оплата і що робить це продуктом

MVP відповідає: чи хтось доведе цю роботу до кінця? SaaS відповідає: чи багато компаній платитимуть далі, щоб ми тримали один код для всіх? Друге питання - не «додати Stripe і вхід». Це тенантність, оплата, перший вхід і спосіб допомогти незнайомцю о другій ночі, не заходячи по SSH у їхні дані.

Як обирати стек для MVP, я вже писала. Це наступний шар: коли форма бізнесу - software-as-a-service, що я б справді збирала, в якому порядку, і що не копіювала б із Linear чи Salesforce у перший місяць.

1. Спочатку: це взагалі SaaS?

Багато «SaaS-ідей» - кастомна система для одного клієнта з щомісячним рахунком. Це може бути хороший бізнес. Це не SaaS. SaaS - один продукт, багато тенантів, самостійна реєстрація або легкий продаж, і вартість наступної компанії близька до нуля - не ще один проєкт.

• SaaS: багато організацій, ті самі можливості, оплата в продукті, доступність - ваша відповідальність.
• Кастом: один покупець, унікальні процеси, виставляєте рахунок за кожну зміну. Не вдавайте, що другий клієнт «просто увійде».
• Якщо першим трьом клієнтам потрібен окремий форк - припиніть називати це SaaS. Продавайте проєкти, доки спільне не стане очевидним, потім витягніть продукт.

2. Одиниця продукту - воркспейс, не користувач

Я б моделювала домен навколо організації (workspace, tenant, account - оберіть одне слово й тримайтеся його). Користувачі належать організаціям. Дані належать організаціям. Рахунки належать організаціям. Якщо почати з «User має Projects», пів року прикручуватимете команди, запрошення і «хто платить».

• Організація має план, billing-email і статус: trial, active, past_due, canceled.
• Членство - рядок: user + org + role (owner, admin, member на старті вистачає).
• Кожна бізнес-таблиця має org_id. Запит без org_id - помилка, не скорочення.
• Спочатку запрошення, не «створити їм обліковий запис». Лист, підтвердження, потрапляння в правильний воркспейс.

3. Тенантність: спільна база, жорстка ізоляція

Для першого SaaS я б не відкривала Postgres на кожного клієнта. Одна база, org_id на кожному рядку, і захист у кілька шарів, щоб пропущений WHERE не став витоком. Окрема база на тенанта - для регульованої ізоляції або шумних сусідів, яких уже виміряли, не для четвертого клієнта.

• Row-level security або еквівалентний помічник запитів, який завжди підставляє org_id із сесії - не з body клієнта.
• Ідентифікатори, які не вгадаєш (UUID). Послідовні /org/12/invoices/4 - запрошення зламати.
• Файли з префіксом org_id, підписані URL, ніколи публічний бакет «усі завантаження».
• Схема на тенанта чи база на тенанта лише коли контракт, чекліст відповідності або реальний шумний сусід змушує. Міграції на 200 схемах - продукт, який ви не хотіли.

4. Оплата - частина продукту, не плагін «потім»

Якщо ніхто не може заплатити - у вас немає SaaS. Checkout я б поставила на критичний шлях уже на другому тижні, навіть якщо решта застосунку ще худа. Фаза «виставимо рахунок руками» ок для перших п’яти партнерів із дизайну - далі картка має спрацювати.

• Stripe Billing (або процесор, яким реально платять на першому ринку): products, prices, customer portal, webhooks. Не зберігайте номери карток. Не пишіть рушій нагадувань про оплату.
• Один-два плани, не сім. Пробний період із чітким кінцем. Після нього: лише читання або жорстке блокування - оберіть одне й напишіть це в інтерфейсі.
• Ціна за річ, яку клієнт розуміє: місця, проєкти або місячний обсяг. Оплата за використання сильна і легко крива; почніть із місця або фіксованого плану, поки не зрозумієте, що таке «використання».
• Webhooks - джерело правди для «чи вони заплатили?». Ваша база віддзеркалює Stripe (чи Paddle). Cron, який здогадується, - це як заблокувати платника.

5. Стек, який я б узяла (і чим він відрізняється від MVP-сайта)

Веб за замовчуванням лишається: Next.js, TypeScript, Tailwind, Postgres. SaaS додає кілька частин, яких маркетинговому сайту не треба, - і досі не потребує сітки сервісів.

• Auth, який розуміє організації: Clerk, WorkOS, Auth.js плюс таблиця членства - не один глобальний прапорець «увійшов».
• Фонові завдання з першого дня, якщо щось повільне або можна повторити: листи, Stripe webhooks, експорти, виклики LLM. Проста черга (Inngest, Trigger.dev або воркер на VPS) надійніша за setTimeout у serverless-функції.
• Транзакційна пошта з першої хвилини: запрошення, квитанція, «пробний період закінчується в п’ятницю». Якщо лист не доходить - продукт здається мертвим.
• Feature flags для планів (can_export, seat_limit), а не if (org.plan === "pro") у п’ятдесяти файлах.
• Хостинг: Vercel плюс хостований Postgres ок, поки воркер або вимоги до розміщення даних не скажуть інакше. Одного регіону вистачає. Кілька регіонів - пізніша проблема.

6. Онбординг - це продукт першої години

Порожні SaaS-дашборди не конвертують. Першу сесію я б проєктувала як роботу, не як екскурсію: створити воркспейс, імпортувати або ввести перший живий запис, запросити колегу, побачити один результат. Підказки над порожньою таблицею - не онбординг.

• Демо-воркспейс ок, якщо він явно несправжній і за один клік від «почати з моїх даних».
• Метрика активації: вони один раз закінчили ключову роботу, не «зареєструвались». Це вимірюйте. Це продавайте.
• Налаштування можуть бути бридкими. Порожній стан головного екрана - ні.

7. Експлуатація: як підтримувати людей, яких ви не знаєте

У день, коли платна організація напише «не бачу рахунків», потрібен шлях без SSH у прод. Тонку внутрішню адмінку я б додала до десятого клієнта, не після першого інциденту.

• Адмінка: знайти організацію, бачити план і останній webhook, увійти лише на читання від її імені, переслати запрошення. Такий вхід - у журнал аудиту.
• Логи з org_id і request id. «Впало» без тенанта - не рядок логу, а знизування плечима.
• Резервні копії, які ви хоча б раз відновлювали. На старті нічних вистачає; неперевірена копія - казка для себе.
• Сторінка статусу може зачекати. Лист «ми лежимо, ось що знаємо» - ні.

8. Що я б не збирала в перший рік

Великий SaaS - музей можливостей, які окупилися пізніше. Копіювати музей - спосіб промахнутися з однією роботою.

• SSO, SCIM і 40-сторінкову анкету безпеки - поки реальна угода на них не стоїть. Тоді це і є спринт, не побічний квест.
• Публічне API і вітрина інтеграцій. Один Zapier або CSV-експорт часто розблоковує того самого покупця.
• Власні домени на тенанта, white-label і студія тем. Завантаження логотипу вистачає більшості раннього B2B.
• ШІ скрізь. Одне місце, де мова і є робота (пошук, чернетки, витяг) зі схемою і лічильником для рахунку. Не бульбашка чату на кожному екрані.

9. Послідовність, якої я б справді дотримувалась

Та сама чесність календаря, що й для MVP, але з віхами під SaaS. Якщо в тижні немає тенанта, оплати або роботи - це не SaaS-тиждень.

• Тиждень 0: назвати роботу, покупця, план, число зупинки (наприклад п’ять платних організацій за 90 днів - або стоп). Що не робимо - на сторінці.
• Тижні 1-2: організація + членство + один щасливий шлях у проді + Stripe test mode. Тести ізоляції: user A не бачить user B.
• Тижні 3-4: жива оплата, запрошення, листи, онбординг порожнього стану, тонка адмінка. Показати іменним компаніям, не «інтернету».
• Дні 30-90: дивитися активацію й причини відтоку. Додати одну інтеграцію або звіт, за який платять. Не додавати другий продукт.

Висновок: здавайте в оренду роботу, не платформу

SaaS я б збирала так само непретензійно, як MVP, плюс те, що дає багатьом компаніям одну систему: воркспейс, рахунок, стіна між тенантами, перша година не порожня, і адмінка, щоб підтримка не була root-шеллом. Стек може лишатися нудним. Продукт - ні.

Якщо є процес, за повторення якого вам уже платять кілька компаній, і ви хочете продукт замість купи кастомних деплоїв - напишіть через блок контактів. Можемо назвати модель тенанта, перший план і зріз, який приймає картку, не прикидаючись Salesforce.