Разработали мобильное приложение на Флаттер для B2B-платформы — один код для трёх продуктов, экономия на поддержке до 70%.

Клиент — B2B-платформа корпоративных скидок для сотрудников крупных компаний (проект под NDA).

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

Проблема — в процессе разработки выяснилось, что приложений нужно не одно, а три — с разными брендами, дизайном и серверами. Бэкенд задерживался, а внешний чат-сервис не имел SDK для Флаттер.

Решение — спроектировали архитектуру так, что из одного кода собираются три брендированных приложения, фронт не простаивал в ожидании бэкенда, а чат заработал даже без готового SDK.

Результат — три приложения в Google Play и App Store, более 100 000 активных пользователей, экономия на поддержке до 70%, проект уже во всю работает.

Заказчик — B2B-платформа, которая предоставляет сотрудникам крупных корпораций доступ к эксклюзивным скидкам: массаж со скидкой 70%, аренда яхт, спецпредложения в ресторанах и спа-салонах. Модель простая: компания-работодатель покупает доступ к платформе и выдаёт его сотрудникам как нематериальный бонус. Каждый сотрудник получает индивидуальный инвайт-код, регистрируется в приложении и видит эксклюзивные предложения.

Задача звучала как «разработайте мобильное приложение», но в процессе мы столкнулись с тремя скрытыми проблемами.

Первая. Бэкенд задерживался. Он должен был быть готов к началу разработки, но фактически его доделывали параллельно. Фронт-команда могла простаивать неделями — а это прямой сдвиг сроков и дополнительные затраты.

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

Третья. В приложении требовался встроенный чат поддержки. Внешний сервис LifeText не имел SDK для Флаттер, что не позволяет разработать чат. Без обратной связи пользователи не могли оперативно решать проблемы, что вело к снижению конверсии.

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

Флаттер как основа. Выбрали Флаттер — он позволяет вести единую кодовую базу для Айос и Андроид, любая доработка пишется один раз и работает на обеих платформах. Это классическая кроссплатформенная разработка под Айос и Андроид, которая экономит время и бюджет. Если бы мы выбрали нативные языки, пришлось бы разрабатывать два отдельных приложения — на Свифт и Котлин — с двойными затратами.

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

Мок-данные — работа без бэкенда. Пока бэкенд задерживался, мы подготовили свои тестовые данные — такие же, какие позже должен был отдавать сервер( мок-данные). С ними можно сразу начать разрабатывать интерфейс и логику приложения, не дожидаясь готового бэкенда. Всё выглядит и работает как с реальными данными, но хранится локально в проекте, а когда бэкенд доделали, мы просто заменили тестовые данные на реальные запросы — это заняло один день.

Чат через ВебСокет. Для чата мы использовали внешний сервис LifeText. Обычно такие сервисы дают готовые инструменты для разработчиков — но для Флаттер у LifeText такого не было. Поэтому подключились к сервису напрямую: настроили канал для обмена сообщениями в реальном времени, передали данные пользователя и настроили приём уведомлений. Всё сделали сами, без готового SDK(набор инструментов от разработчиков сервиса), в результате чат заработал мгновенно — пользователи получают ответы поддержки без задержек, прямо в приложении.

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

Производительность. Приложение выросло до 50+ экранов — это серьёзный объём для мобильного проекта. Мы настроили приоритеты загрузки, чтобы список купонов не тормозил даже при быстром скролле, а картинки подгружались без задержек, пока пользователь листает. Это особенно важно для высоконагруженных мобильных сервисов с большим потоком данных.

Главный вызов этого проекта случился не на старте. Мы уже вовсю разрабатывали приложение, когда заказчик сообщил: «Нам нужно не одно приложение, а три — с разными брендами, дизайном и серверами».

Три брендированных приложения одновременно вышли в Google Play и App Store. По оценке заказчика, их аудитория превысила 100 000 активных пользователей.

Для бизнеса:

• Любая новая фича пишется один раз и становится доступна всем трём версиям — экономия на поддержке достигает 70%.
• Добавление четвёртой или пятой версии не требует изменения кода — только настройки параметров сборки.
• Краш-рейтинг менее 1%, жалоб на производительность не поступало.
• Проект занял около шести месяцев, заказчик принял работу без нареканий.

Для пользователей:

• Мгновенный доступ к скидкам в два клика.
• Чат-поддержка в реальном времени.
• Плавная работа без зависаний.