Задача
Первая версия создавалась как самостоятельная установка для одного автосервиса. По мере развития стало понятно, что продукту нужна другая модель: единая SaaS-платформа, где разные автосервисы получают свои рабочие пространства и общие обновления.
Это требовало не добавить ещё один уровень настроек, а заново определить владение данными, роли и путь заказа внутри продукта.
Ограничения
В одной системе работают независимые организации. Они не должны видеть данные друг друга или выполнять действия за пределами своего автосервиса. При этом владелец автомобиля, сотрудник сервиса, механик и администратор платформы работают с одним заказом по-разному.
Скрыть лишнюю кнопку в интерфейсе недостаточно: сервер должен проверять организацию, роль и право на каждое действие. Большой переход также нельзя было принимать целиком — нужны были отдельные этапы с проверкой данных, доступа и выпуска.
Моя роль
Я пересмотрел продуктовую модель, определил границы организаций и ролей, разделил переход на волны разработки и принимал результат каждой волны. В работу входили архитектура, реализация и проверка выпуска. AI-агенты помогали исследовать зависимости и готовить проверки, но решения о модели продукта и достаточности доказательств принимал я.
Инженерное решение
Основой стала последовательность: исходный запрос превращается в сервисный запрос, затем — в заказ конкретного автосервиса. История изменений хранится отдельно, чтобы новые правки не переписывали прошлое.
Данные принадлежат организации, а сервер проверяет доступ независимо от интерфейса. Для владельца автомобиля, сотрудника сервиса, механика и администратора платформы сделаны отдельные рабочие пространства с разным объёмом данных и действий. Модель может помогать готовить описание работ и документы, но не определяет права пользователя.
Переход был разбит на проверяемые волны: доменная модель, доступ, жизненный цикл заказа, интерфейсы ролей, эксплуатационный контур и выпуск.
Результат
«Самурай» работает как единая мультитенантная платформа. Организации получают изолированные данные, роли — свои рабочие сценарии, а обновления выпускаются для общего SaaS-продукта. Система ведёт клиентов, автомобили, заказы, документы и историю обслуживания.
Выводы
Переход к SaaS меняет основу продукта, а не только схему базы данных. Сначала нужно определить владельца каждой сущности и допустимые действия ролей, затем закрепить эти правила на сервере и проверять миграцию по частям.
Полный разбор перехода — в статье «От open-source для одного автосервиса к мультитенантному SaaS». Для похожей задачи подойдёт разработка веб-систем; для изменений на уровне компании — технологическая работа с процессами.