Разработка SaaS-сервиса на опыте собственных продуктов

Большинство заказных систем пишутся под одну компанию. SaaS отличается тем, что одной и той же системой пользуются десятки и сотни компаний. Это меняет почти всё: как хранятся данные, как подключается новый клиент, как выпускаются обновления.

Наш опыт: три собственных продукта

Кроме заказной разработки, мы запускаем собственные продукты, рассчитанные на много компаний сразу.

• Kvadrum — мультитенантная платформа продаж недвижимости: шахматка, брони, цены с историей, кабинеты застройщика и агентства, синхронизация с Битрикс24 и amoCRM, виджет для сайта. Написан на Go и React, работает в Docker.
• Sapadex — ИИ-оценка звонков и переписок отдела продаж: выгрузка из Битрикс24, расшифровка, оценка по рубрике, тревоги и дашборд.
• b24tools — мультипортальная админка для Битрикс24: подключить можно любой портал, дальше сервис сам считает дни на стадии, красит канбан и рассылает сводки.

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

Разработка SaaS-сервиса: решения, которые нельзя отложить

Изоляция данных. Каждая запись в базе принадлежит конкретной компании, и сервер проверяет это в каждом запросе. Отдельная база на клиента или общая база с меткой компании — выбор зависит от числа клиентов и требований к безопасности. Ошибка здесь — когда клиент видит чужие данные — убивает доверие к продукту сразу.

Роли. У клиента есть администратор, руководитель, сотрудники, иногда внешние партнёры. В Kvadrum это админ, РОП, менеджер и риелтор агентства. Схему ролей проектируем до первого экрана.

Подключение клиента. Регистрация, приглашение сотрудников, импорт данных, подключение CRM. Если каждый новый клиент требует ручной настройки разработчиком, бизнес упирается в эту работу.

Интеграции. Для B2B-продукта в Казахстане чаще всего это Битрикс24 и amoCRM. Ключи доступа хранятся только на сервере, интеграция переживает временную недоступность внешнего API.

Как мы запускаем SaaS по этапам

1. Прототип за 1–3 дня, чтобы показать идею первым клиентам. Об этом подробнее — на странице MVP за неделю.
2. MVP для 2–3 пилотных компаний с изоляцией данных, ролями и главной интеграцией.
3. Онбординг и оплата, когда понятно, за что клиенты готовы платить.
4. Масштабирование: фоновые очереди, кэш, мониторинг, публичный API.

Инфраструктура и поддержка

SaaS живёт дольше, чем проект на заказ, поэтому эксплуатацию продумываем с первого релиза. Сервис работает в Docker-контейнерах, база PostgreSQL копируется каждую ночь, мониторинг сообщает о сбоях раньше клиентов. Тяжёлые задачи — синхронизация с CRM, отчёты, обработка файлов — уходят в фоновые очереди, чтобы интерфейс не тормозил. Сервер, домен, HTTPS, бэкапы и мониторинг берём на себя, код и доступы остаются у вас.

Когда SaaS делать рано

Если у вас нет ни одного клиента, готового пользоваться продуктом, начните с прототипа и разговоров с рынком. Если система нужна только вашей компании, мультитенантность и тарифы — лишняя стоимость: достаточно веб-приложения. А если вы хотите продавать партнёрам доступ к своим ценам и остаткам, посмотрите B2B-портал: это проще SaaS и запускается быстрее.