Рассказываем, как отказ от «универсального» продукта помогает запускать новые приложения за два дня.

Помните времена, когда одно приложение пыталось делать всё сразу? Регистрация – общая, интерфейс – переключается по ролям, логика — вроде бы универсальная. На старте развития того же Uber все так и было: один продукт и для пассажиров, и для водителей. Пока всё не стало слишком большим. Слишком сложным. Слишком тяжёлым. В итоге их разделили — на Uber и Uber Driver. Так же потом поступили Glovo, Bolt, DoorDash. И правильно сделали.

Когда ты пытаешься уместить в одно приложение и клиента, и курьера, и поддержку, и весь бэк-офис – это уже не продукт, а Франкенштейн. Он растёт, начинает сам с собой конфликтовать и в какой-то момент рискует обрушиться под собственным весом.

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

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

Так мы отказались от попытки втиснуть всю экосистему в одно приложение. И обкатали подход уже на следующем крупном проекте в крипто-домене. Это была платформа лояльности, где пользователи получали бонусы, а бренды – аналитику по их действиям. Архитектура включала Shopify-интеграции, клиентский портал, мобильное приложение, Chrome-расширение и серверную часть. И все это – кастомное.

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

Это позволило упростить локальную разработку, ускорить сборку, снизить порог входа в проект для  новых участников и обеспечить контроль качества.

Этот опыт стал основой для нашей следующей экосистемы – уже в рамках проекта Sizl.

История с Sizl началась с задачи перезапустить уже существующее приложение для сети dark-kitchen в Чикаго – с доставкой еды, самовывозом и лояльной аудиторией. Первая версия была написана на Kotlin Multiplatform – крутой, но нишевой технологии. Со временем внутренняя техническая команда обновилась, и фаундерам Sizl стало понятно: с поддержкой, масштабированием и развитием продукта могут возникнуть сложности.

Мы начали проект задачей с ребилда приложения на React Native и добавления нового функционала. Продукт уже имел рабочую бизнес-логику, понятные сценарии и реальные данные. А для разработчиков это просто мечта – ничего не надо выдумывать, просто собери всё грамотно и начинай улучшать.

Идея перейти на монорепу пришла от нашего мобильного разработчика Ильи – именно он уже реализовывал подобное решение на TypeScript в проекте, о котором я рассказывал выше. Поэтому у него сразу сложилась картинка, как можно объединить отдельные компоненты кода в управляемую экосистему.

Для Sizl мы организовали архитектуру так, что каждый блок системы – например, авторизация – оформлен как самостоятельный модуль со своей логикой, интерфейсом, хуками и данными. Такие модули хранятся отдельно и не зависят друг от друга напрямую.

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

Поэтому когда позже клиент пришёл с запросом: «А давайте сделаем еще отдельное приложение для курьеров», – нам не пришлось начинать с нуля. Многие части логики уже были прописаны в проекте, и мы просто подключили монорепозиторий, чтобы не плодить сущности.

Монорепозиторий мы разделили на две части:

По факту это позволило нам быстро собрать новое приложение, просто подключив нужные модули, прописав логику и привязав API. А в клиентском приложении заменить только импорты и ничего не сломать.

Такой подход позволил нам сильно ускорить релиз: на приложение для курьеров у нас ушло около 2,5 недель. При этом сам монорепозиторий мы собрали за неделю. А на приложение для поддержки планируем потратить всего 2 дня – там суперпростой флоу, поэтому точно знаем, что уложимся в срок.

Если бы backend был написан на Node.js, мы бы тоже включили его в монорепозиторий: вынесли бы клиент в отдельный пакет и просто импортировали его, без необходимости каждый раз генерировать API-документацию. Это упростило бы связку фронта с сервером и ускорило разработку.

Монорепозиторий – не магия, а инженерное решение. Да, на старте оно требует времени и усилий. Но если вы не просто тестируете гипотезы с MVP, а планируете строить зрелую цифровую платформу, эти инвестиции быстро окупаются и приносят новые преимущества:

И самое главное – пользователь тоже чувствует эти эффекты. Интерфейс становится легче, путь – яснее, сценарии – логичнее. Для команды разработки всё так же прозрачно: архитектура разделена, но связана, зоны ответственности понятны, и можно наконец-то не бояться «просто поправить в одном месте».