Переписали приложение доставки BBQ и ускорили ключевые сценарии до нативной скорости
Клиент пришёл с приложением на Cordova: меню открывалось по 10–15 секунд, первый запуск — более 10. За 2 месяца перевели продукт на нативную основу, сократили загрузку меню до 0,5 секунды и подняли средний рейтинг в сторах с 3,5 до 4,5.
Сеть шашлычных BBQ с высокой нагрузкой на ключевых сценариях
BBQ — сервис доставки еды в Сочи и пригороде. До переработки продукт работал на Cordova. Приложение обслуживает весь город: от центра до Красной Поляны, поэтому скорость и стабильность напрямую влияют на заказы и выручку.
При таком масштабе каждая секунда загрузки — это потерянные заказы.
Сократили время открытия меню с 15 секунд до 0,5 секунды
Время от открытия приложения до оплаты сократилось с ~4 минут до ~1,5 минуты.
Нужно было не просто обновить интерфейс, а заменить архитектуру, которая не давала расти
Задача не ограничивалась интерфейсом. Основные проблемы лежали в интеграциях, API и устаревшем клиентском контуре.
Bitrix API
- Плохая документация
- Частые падения сервиса
- Медленные ответы API
Интеграции
- Создание заказа занимало более 10 секунд в iiko
- Поиск заказа занимал 2-3 секунды из-за связи с 1С
Legacy-архитектура
- Все запросы проходят через Битрикс
- Telegram-боты курьеров нагружали основную систему
- Старая и медленная версия PHP
Мы добавили собственную API-прослойку для кэширования, валидации и нормализации данных, а клиент переписали на нативных технологиях Swift и Kotlin.
Пересобрали интерфейс и ключевые пользовательские сценарии
Интерфейс собрали заново вокруг основных действий пользователя: поиск товара, просмотр товара, работа с корзиной и оформление заказа. Приложение стало чище, понятнее и дает «нативные» ощущения от использования.
- светлая и тёмная темы
- упрощённая навигация по меню и категориям
- переработанные сценарии работы с экранами товара, корзины и оформления заказа
API-прослойка убрала зависимость клиента от медленного бэкенда
Раньше приложение напрямую обращалось к Bitrix API — интерфейс зависел от медленных ответов, нестабильных данных и ограничений старой платформы. Новая прослойка взяла на себя кэширование, валидацию и нормализацию данных — стабильность приложения увеличилась.
Добавили мониторинг, чтобы быстрее замечать и разбирать сбои
После запуска важно было не только ускорить приложение, но и сделать его доступным в плане обслуживания. Для этого сделали два инструмента: быстрые уведомления об ошибках в Telegram и панель логов для диагностики.
Telegram-бот
Бот сообщает о проблемах в рабочий чат: ошибках валидации, нестабильных ответах API и замедлении критичных сценариев.
Панель логов
Панель помогает отфильтровать события по коду ответа и методу HTTP-запроса, быстро найти причину сбоя и разобрать конкретный пользовательский сценарий.
Команда стала быстрее замечать сбои, понимать причину и возвращать сервис в рабочее состояние.
Стек, который позволил уложиться в 2 месяца
Общую логику вынесли в KMP, интерфейс собрали нативно для iOS и Android, серверную часть — на Bun + TypeScript с PostgreSQL, Redis и Docker.
Kotlin
Swift
KMP
Jetpack Compose
SwiftUI
Bun
TypeScript
PostgreSQL
Redis
Docker