Skip to content
Vertical AI

Четырёхнедельный playbook вертикали и наше собственное табло

Метод запуска вертикали на общей инфраструктуре за четыре недели, а следом реестр, который говорит, сколько наших вертикалей ему соответствуют.


Михаил Савченко·14 августа 2026 г.·4 мин чтения
Vertical AIArchitectureMulti-tenantStrategy

Почему четыре недели вообще возможны

Почти ничто в новой вертикали не является новым.

Каждой нужно знать, кто такой пользователь, что такое компания, как человек принадлежит компании, как ограничен API-ключ и как право переопределяется для одного тенанта. Это пять сущностей, и они одинаковы независимо от того, сдаёт продукт экскаваторы или записывает на физиотерапию.

Над ними лежат возможности: девятнадцать пакетов под @inite/*, среди них входящие, биллинг, инциденты, уведомления, локализация, безопасность, витрина и база знаний, плюс три горизонтальных сервиса для auth, billing и brain. Это тоже не переписывается.

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

Порядок, который имеет значение

НеделяЧто подключаетсяПочему здесь
1auth, tenantОт того, кто и за кого спрашивает, зависит всё дальнейшее
1api-kitЕдиные ошибки и лимиты до того, как эндпоинтов станет много
2Доменная модельЕдинственное по-настоящему новое в стройке
2-3Основное взаимодействие: входящие или витринаСмотря чем продукт является
3assistant, notificationsПолезны, когда есть чему ассистировать
4billing, security, i18nЦены оставлены на конец, потому что меняются чаще всего

Правило «идентичность первой» имеет самое острое последствие. Достраивание мультитенантности в продукт, который предполагал одного клиента, самая дорогая переделка в этом деле, и именно эта ошибка превращает четырёхнедельный клон в трёхмесячный.

Биллинг уходит в конец по обратной причине. Цены меняются чаще идентичности, и построенный на первой неделе он будет построен дважды.

Табло, без прикрас

Пост про playbook обычно заканчивается счётчиком успехов. Вместо него привожу настоящий реестр.

СтатусШтукЧто означает
production1Обслуживает пользователей
pilot2Активно калибрует спецификацию
migration_pending4Репозиторий есть, намерение есть, пробел в модели данных
drift4Потребляет общие пакеты, манифеста нет
non_conforming2Репозиторий есть, общих пакетов нет, манифеста нет
candidate3Названа, не начата
legacy2Заменена другой
conforming0Объявляет версию и выполняет контракт

Восемнадцать записей. Одна в проде. И статус, который спецификация определяет как цель, не имеет вообще никто.

Последняя строка та, с которой стоит посидеть. conforming означает, что вертикаль объявляет свою версию экосистемы и выполняет контракт целиком. Пока таких нет ни одной. Половина реестра стоит в drift или migration_pending, то есть пользуется общим рантаймом на практике и ещё не призналась в этом на бумаге.

Почему мы публикуем это именно так

Потому что счётчик вертикалей это маркетинговое число, а реестр статусов инженерное, и ошибиться заметным образом может только второе.

«Шестнадцать вертикалей на общем рантайме» это фраза, которая переживёт любой объём расхождения под ней. «Ноль соответствующих, четыре в расхождении» это фраза, которая создаёт работу. Реестр ведётся руками и обновляется на каждом релизе спецификации ровно затем, чтобы он не превратился тихо в число первого рода. По той же причине разделение конституции и рантайма держит репозиторий спецификации свободным от исполняемого кода: спецификация, которая поставляет рантайм, перестаёт быть проверяемой хоть по чему-нибудь.

Что четыре недели дают и чего не дают

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

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

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

Если делаете это сами

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

Запишите сущности, которые будут общими для всех продуктов семьи, и не позволяйте ни одному продукту их менять. Поставьте общий рантайм под версию. Ведите реестр того, какие продукты ему действительно соответствуют, и сделайте честные статусы неприятными на вид, потому что реестр, от которого никто не морщится, никто и не обновляет.

Часто задаваемые вопросы
  • 01Если метод работает, почему в проде только одна вертикаль?+

    Потому что построить вертикаль и привести её в соответствие спецификации это разные задачи, и срочной для кого-либо является только первая. Вертикаль доходит до прода, когда обслуживает пользователей достаточно хорошо, чтобы брать за это деньги; статуса conforming она достигает, когда объявляет версию экосистемы и выполняет контракт целиком, а эта работа окупается позже, а не раньше. Реестр намеренно не льстит. Четыре из восемнадцати стоят в drift, то есть потребляют общие пакеты и ни разу не опубликовали манифест, и ещё четыре в migration_pending, то есть репозиторий есть и намерение соответствовать есть, а в модели данных пробел. Такое распределение и выглядит как программа со спецификацией впереди на середине пути, и публиковать его реестром статусов, а не маркетинговым счётчиком, единственный способ сохранить число полезным внутри.

  • 02Что именно общее, а что пишется каждый раз заново?+

    Общее: пять сущностей Ring 1, которые определяют, кто такой пользователь, что такое компания и как они связаны, плюс пакеты-возможности для входящих, биллинга, инцидентов, уведомлений, локализации, безопасности, витрины и базы знаний, плюс три горизонтальных сервиса для auth, billing и brain. Ничего из этого не переписывается. Заново под вертикаль: доменные объекты, которые делают продукт тем, чем он является, и процессы поверх них. Для проката это единица техники, бронь и отгрузка; для агентства недвижимости это объект, объявление и сделка. Именно эта пропорция делает четыре недели возможными, и она же честная граница утверждения, потому что вертикаль с по-настоящему новой доменной моделью займёт больше времени, сколько инфраструктуры ни унаследуй.

  • 03В каком порядке подключать возможности?+

    Идентичность первой, всегда: auth и tenant, потому что каждое последующее решение зависит от того, кто спрашивает и от чьего имени, а достраивание мультитенантности в продукт, который предполагал одного клиента, самая дорогая переделка в этом деле. Дальше обёртка запросов, чтобы форма ошибок, логирование и лимиты стали одинаковыми до того, как появится много эндпоинтов, которые надо приводить к одному виду. Дальше та возможность, что несёт основное взаимодействие продукта: обычно это входящие для всего, где есть переписка, или витрина для всего, где есть каталог. Биллинг подключается позже, чем ожидают основатели, потому что цены меняются чаще идентичности, и построенный рано он будет построен дважды. Безопасность и локализация идут последними по порядку, а не по важности, и обе гораздо дешевле ложатся на чистую модель тенантов, чем прикручиваются к грязной.

  • 04Четыре недели на вертикаль означают четыре недели на бизнес?+

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

Читать дальше