SaaS-платформа на практике: как разработать и запустить продукт, а не дорогую кастомизацию

• «Нужно разработать SaaS-платформу».
• «Хорошо. Сколько клиентов должны запускаться без доработки кода?»
• «Ну... у нас пять компаний, и у каждой свои процессы».

Я слышу это регулярно. Вопрос «SaaS-платформа - что это» часто звучит как термин, но системно это проверка бизнес-модели: вы строите один повторяемый продукт или набор отдельных внедрений по подписке. Ошибка на этом шаге стоит 6-12 месяцев и обычно бьет не по коду, а по продажам, поддержке и темпу развития.

Граница между SaaS и порталом проходит не в интерфейсе

Снаружи портал и SaaS похожи: личный кабинет, роли, отчеты, уведомления, API. Разница в том, как подключается новый клиент и сколько ручного труда нужно команде после продажи.

Если упростить, тест очень простой. Новый аккаунт должен стартовать за 1 час или хотя бы за 1 день настройки. Если для запуска нужны 2-3 недели кастомизации, вы строите сервисный бизнес, даже если на сайте написано SaaS.

У нас был проект в обучении. Клиент хотел «SaaS для корпоративных академий», но у каждого заказчика были свои аттестации, роли и правила доступа. Мы не пошли в общую платформу сразу - сначала собрали 1 вертикаль с одинаковыми правилами и только потом вынесли повторяемые части в продукт.

Идеи ломаются там, где сегмент еще не выбран

Чаще всего дело не в Laravel 11 или Node.js 22. Ломается гипотеза: за что клиент будет платить каждый месяц и можно ли этот сценарий стандартизировать для одной группы компаний.

У нас был кейс для дилерской сети. Изначально команда хотела платформу сразу для 5 отраслей. После интервью стало видно, что KPI разные, обязательные интеграции разные, базовые процессы тоже разные. Мы уже пробовали такой широкий старт на другом проекте, и он не сработал: каждая новая продажа превращалась в отдельный мини-проект.

Что проверять до разработки?
Нужна регулярная боль, понятный первый результат и сценарий без участия разработчика на каждом запуске. Если хотя бы один пункт не сходится, строить SaaS рано.

После сужения до одного сегмента первый релиз сократился примерно на 45%. Это хороший сигнал: у продукта появляются границы, а без них подписка почти всегда начинает течь по швам.

Регистрации легко купить. Активацию - гораздо сложнее.

MVP - это путь к первой пользе, а не набор экранов

Я бы смотрел на MVP как на кратчайший путь к моменту, когда клиент понял ценность. Для простого SaaS это 5-15 минут. Для тяжелого B2B-сценария - до 1 рабочего дня.

На проекте по согласованию документов в первом черновике было 18 экранов, 9 ролей и 6 интеграций. Мы оставили один маршрут согласования, уведомления, статусы, audit log и три роли: инициатор, согласующий, админ. Стек был такой: Laravel 11, PostgreSQL 16, Redis 7, Vue 3, PostHog, Sentry.

До

• много экранов и ролей
• сложный первый запуск
• ценность появлялась слишком поздно

После

• 8 недель до релиза
• один ключевой сценарий
• рост активации с 22% до 41%

Для ранней версии обычно хватает такого набора:

• onboarding без звонка с разработчиком
• один ключевой workflow
• роли, история действий и audit log
• биллинговые события и базовая аналитика

Архитектура старта должна ускорять релизы

Спор про монолит и микросервисы на старте обычно преждевременный. Команде из 4-10 человек почти всегда выгоднее modular monolith: быстрее деплой, меньше точек отказа, проще сопровождение.

Мы обычно собираем ранний B2B SaaS на Next.js 15 или React 19, Node.js 22 + NestJS 11 либо Laravel 11, PostgreSQL 16, Redis, Docker и управляемом облаке. Для авторизации - Keycloak, Auth0 или Clerk, в зависимости от требований к ролям, SSO и внешним входам. Хороший признак на старте - команда релизится несколько раз в неделю, а новый клиент подключается без участия разработчика.

Один раз мы зашли в продукт, где multi-tenancy решили «добавить потом». Переделка tenant-aware доступа, миграций и прав заняла почти 4 недели. Я сам недооценивал такие вещи на раннем этапе, и это была ошибка. С тех пор мы биллинговые события, RBAC и audit log проектируем в первой итерации, даже если внешне это еще «просто кабинет».

if (user.tenantId !== resource.tenantId) {
  throw new ForbiddenException();
}

if (!user.roles.includes('admin') && !canAccess(user, resource)) {
  throw new ForbiddenException();
}

Запуск начинается с метрик, а не с домена

Открыть регистрацию недостаточно. Нужны числа, по которым видно, что продукт живет без ручного сопровождения каждого аккаунта.

Я обычно смотрю на четыре метрики: активация, время до первой пользы, переход из пробного периода в оплату и причины оттока. Для B2B особенно полезно измерять, какая доля аккаунтов за 7 дней дошла до первого ценностного события. Если активация ниже 30-40%, проблема чаще в онбординге или в выбранном сегменте, а не в рекламе.

Я пару раз ошибался и начинал обсуждение со стека раньше, чем с границ продукта. Лучше работает другой порядок: перед стартом написать на одной странице, для кого продукт, какой первый результат клиент должен получить и что точно не войдет в первую версию. Этот лист экономит больше денег, чем еще один месяц разработки.