Как создать мультибрендовую архитектуру в ePharm: кейс аптеки «36,6» и .redev

Цель Создать функциональную, но простую платформу для масштабирования бизнеса. Первоначально стояла задача уйти от SAP Commerce и создать собственную технологическую основу для управления тремя брендами и обеспечивать улучшенный пользовательский опыт для миллионов пользователей. Клиента беспокоила устаревшая архитектура, технологический стек и нестабильная работа приложения. Вместе с клиентом команда .redev определила четыре блока задач: Разработать два новых мобильных приложения «с нуля» за 11 месяцев, сохранив привычный функционал с возможностью развития. Внедрить 24/7/365 мониторинг и поддержку. Обеспечить архитектуру, выдерживающую рост трафика x10 без деградации. Создать современный интуитивный интерфейс с простым оформлением заказа, при этом сохранить UX-привычки миллионов пользователей, не потеряв конверсию. Обеспечить поддержку старых приложений на момент разработки, чтобы пользователи не остались без привычного канала. 

Как была организована разработка: три команды под единой моделью управления

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

Команда разработки создавала два абсолютно новых приложения для iOS и Android на общей архитектуре. Это заняло 11 месяцев. 

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

Команда круглосуточной технической поддержки 24/7 мониторила систему, реагировала на инциденты, а также устраняла неполадки и решала вопросы от пользователей. SLA по критическим инцидентам — 15 минут. Такой уровень зрелости — редкость для фармритейла.

Чтобы синхронизировать их работу, мы выстроили понятный ритм коммуникаций: ежедневные дейли с участием CPO заказчика, отдельные короткие встречи по поддержке, еженедельные созвоны по инцидентам и техническому долгу и регулярные отчеты по. прогрессу. Это позволило держать в фокусе и выпуск новой версии продукта, и стабильность старых приложений, которые продолжали работать весь период разработки. 

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

Результаты: устойчивая и масштабируемая система, оценки 4,9+, трафик +62%, заказы +48%

1. Нативная разработка — быстрее, надежнее, удобнее для пользователя.
Создали приложения на «родных» языках — для iOS на Swift, Android — Kotlin. Это обеспечивает:

• высокую скорость работы;

• интуитивный интерфейс, привычный для пользователей обеих платформ;

• стабильность даже на старых устройствах;

• независимые обновления под каждую платформу, что ускоряет развитие.

2. Масштабируемая архитектура — система выдерживает рост трафика х10 без сбоев.
Платформа изначально спроектирована под высокие нагрузки. Она автоматически масштабируется при всплесках трафика (например, акции, сезонный спрос) и продолжает работать без простоев. Ускорение загрузки обеспечивается за счет кеширования и CDN. Это снижает риски потери заказов в пиковые периоды.

3. Единый слой интеграции со всеми внутренними системами компании — middleware.
Сделали промежуточный слой, который отвечает за обмен данными между приложениями и внутренними системами (ERP, сайт, остатки товаров, платежи).
Он берет на себя тяжелую работу по обработке запросов и обеспечивает:

• стабильность и скорость;

• корректность данных в реальном времени;

• безопасность и контроль бизнес-логики.

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

4. Единая кодовая база — быстрее запуск, легче поддержка, ниже стоимость владения. 
Оба приложения — «36,6» и «Горздрав» — работают на общей технологической основе.
Различия — только в брендинге и отдельных бизнес-модулях.

Преимущества:

• новые функции создаются один раз и доступны всем брендам;

• единый UX формирует единые привычки у пользователя и помогает ориентироваться во всех сервисах сети;

• техподдержка работает быстрее благодаря централизованным логам — единой базе хранения технической информации и статистике;

• запуск новых брендов или франшиз ускоряется в разы.

Бизнесу это позволяет сократить бюджет на техническую поддержку на 20–40% и повысить скорость ввода новых продуктов.

Сравнение октября 2024 и октября 2025 годов показывает рост трафика приложений на 62%, а количества заказов — на 48%. При этом архитектура справляется с большим количеством единовременных пользователей — 10 000+.