Перейти к содержимому
DTS Business

Разработка SaaS

Мультиарендные продукты, рассчитанные на эксплуатацию: тенантность, биллинг, наблюдаемость и прочие скучные части, от которых зависит, переживёт ли продукт первую сотню клиентов.

  • Тенантность и биллинг спроектированы до первого клиента, а не достроены после
  • Наблюдаемость с первого дня — инциденты разбираются, а не угадываются
  • Кодовая база, которую способна перенять ваша собственная команда
Интерактивное демо

Диалог с агентом квалификации

Ничего не сохраняется: файл и переписка исчезают при сбросе.

Он задаёт те же вопросы, что и сильный пресейл-инженер, и оценивает перспективность.

Хотите то же самое на своих данных?

Это демо — уменьшенная версия того, что мы внедряем клиентам.

Обсудить задачу

Что на самом деле решает судьбу SaaS

Не набор функций. Функции — видимая часть, и она всё равно меняется. Решает то, заложен ли фундамент раньше, чем он понадобился.

Тенантность. Способ изоляции арендаторов — самое трудное решение для последующего изменения: он касается каждого запроса в системе. Общая схема с колонкой арендатора, схема на арендатора и база на арендатора дают разное, и правильный ответ зависит от ваших требований к соответствию и от того, какого размера ваши клиенты.

Биллинг. Подписки, учёт потребления, пропорциональные пересчёты, переход на другой тариф в середине периода, неудавшиеся платежи, возвраты. Каждый пункт — конечный автомат, а биллинг, пристроенный после запуска, означает переписывание ровно тех частей, которые переписывать хочется меньше всего.

Наблюдаемость. Структурированные логи, трассировки и метрики с самого начала. Добавить их после первого серьёзного инцидента — значит разбирать этот инцидент догадками.

Миграции. Изменение схемы на живых данных арендаторов, с возможностью отката. Это привычка, и вырабатывать её нужно, пока цена ошибки мала.

Стек по умолчанию

TypeScript от края до края, Next.js на фронте, PostgreSQL как система записи и скучная инфраструктура. Не потому, что это модно: один язык по обе стороны границы убирает целый класс интеграционных ошибок, а PostgreSQL переживёт большинство альтернатив.

Отклоняемся, когда есть причина. Не отклоняемся ради интересности.

Как устроена работа

Двухнедельные циклы, каждый заканчивается чем-то развёрнутым. Ни один цикл не производит только проектную документацию. Доступ к репозиторию у вас с первого коммита, к конвейеру развёртывания — с первого релиза, поэтому передача идёт непрерывно, а не наступает событием в конце.

Что передаётся

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

О демо выше: это агент квалификации, один из компонентов, которые мы встраиваем в продукты такого рода. Он проходит те же измерения, что и грамотный пресейл-инженер, по одному вопросу за раз.

Частые вопросы

Вы работаете с существующим продуктом или только с новым?

И так, и так. На существующем продукте первая работа обычно — прочитать код и рассказать, что мы там нашли. Это уже результат сам по себе.

Кому принадлежит код?

Вам, с первого коммита, в вашем репозитории. Мы не строим на своей проприетарной платформе: это сделало бы уход дорогим, а такие отношения нам не нужны.

Можете ли вы принять SaaS от другой команды?

Да. Сначала — две-три недели обследования: аудит зависимостей и безопасности, восстановление процесса развёртывания и письменный перечень хрупких мест. Принять систему без этого шага — способ унаследовать чужой инцидент.

Есть процесс, который стоит автоматизировать?

Связаться с нами