Как мы разработали систему управления флотом для SWAPPZ и обеспечили 100% контроль транспорта в Дубае

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

Мы разработали единую цифровую экосистему SWAPPZ — кастомную систему управления флотом, которая связала владельцев, курьеров и сервисные команды в один прозрачный контур. Это кейс разработки ПО для логистики и автоматизации управления транспортом в условиях микромобильности ОАЭ.

3 мес.

от идеи до запуска MVP

5

уникальных ролей в системе

100%

контроль за юнитами

Логистика

отраслевой опыт

01. Проблема

Владельцы флота видели картину кусками, курьеры искали свободные юниты вручную, техники узнавали о поломках слишком поздно.

SWAPPZ управляет флотом электробайков и самокатов по всему Дубаю. По мере роста флота операционные пробелы стали критическими.

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

На уровне курьеров была своя проблема. В начале смены они тратили 15–20 минут на поиск свободных юнитов вручную — без приложения, без карты, без статусов.

Бизнес рос, но операционная модель не была рассчитана на рост. SWAPPZ нужна была кастомная система управления флотом, которая отражала реальную сложность процессов — не типовой SaaS, подогнанный под задачу.

Ключевые требования:

• Видимость каждого юнита флота в реальном времени
• Строгое разделение ролей — владельцы, администраторы, техники и курьеры с разными интерфейсами
• Мобильные инструменты для полевых сотрудников — фактически разработка мобильного приложения под логистику смены
• B2B-дашборд для инвесторов с чистой KPI-отчётностью
• Архитектура, которая масштабируется без полной переработки

02. Решение

Ролевая модель и права доступа

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

Проектирование ролевой модели — первое и самое критичное архитектурное решение. Ошибка здесь ведёт либо к дыре в безопасности (курьер видит данные владельца), либо к провалу UX (техник тонет в лишних меню).

Перед первой строкой кода мы прошли каждый рабочий сценарий вместе с командой SWAPPZ. Пять ролей — у каждой своя задача и свой интерфейс:

• Суперадмин — полный доступ, управляет всеми операторами и локациями
• Администратор — флот одного оператора, пользователи и отчёты
• Владелец — read-only B2B-дашборд, KPI флота и финансовые метрики
• Техник — мобильное приложение с очередью задач, историей юнитов и навигацией
• Курьер — поиск юнитов, старт аренды и репортинг проблем

Права реализованы на уровне API — не только скрыты в интерфейсе. Токен курьера не может запросить данные уровня владельца, как бы ни был собран клиент.

Ролевая модель и права

Многоролевая архитектура: курьер, техник, владелец, администратор и суперадмин.

B2B-дашборд для владельца

Дашборд владельца создавался с одной целью: полная картина состояния флота за 30 секунд.

Интерфейс показывает три слоя данных одновременно:

• Статус флота — сколько юнитов активны, свободны, на обслуживании или под флагом. Карта с цветовой индикацией и провалом до конкретного юнита. Владелец видит, где каждый актив прямо сейчас.
• Сервисные KPI — среднее время реакции техника, открытые заявки, юниты, закрытые за последние 24 часа. Раньше у SWAPPZ не было способа измерить эффективность техников.
• Отслеживание угонов и инцидентов — юнит, покинувший геозону, сразу даёт алерт. В логе — метка времени и последнее местоположение. Вместе с GPS в реальном времени это меняет экономику угона.

Дашборд стал инструментом и для ежедневной работы, и для отчётности перед инвесторами. Чистые экспортируемые данные заменили ручные месячные сводки.

Центр управления флотом

Единый дашборд: статусы, сервисные KPI и трекинг юнитов в реальном времени.

Требования и сценарии

До разработки зафиксировали сценарии по ролям: маршруты, статусы юнитов, сервисные передачи, старт и завершение аренды. Эта карта стала ТЗ — и не «плыла» в середине спринта.

Управление юнитами

Каждый актив флота получает цифровую карточку — она сопровождает юнит весь операционный цикл. По сути это система учёта транспорта на уровне единицы парка, а не только «точка на карте».

Карточка юнита содержит:

• Текущий статус (доступен, арендован, на обслуживании, под флагом)
• Полную историю аренд с метками времени и ID курьеров
• Лог сервисных событий с заметками техника
• Зафиксированные неисправности с фото
• Историю GPS-позиций

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

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

Карточка юнита и состояние

Страница юнита: статус, история аренд, сервисные события и текущее состояние.

Приложение техника

Полевые техники — операционный хребет флота. Инструмент должен быть быстрым, работать офлайн и быть сфокусированным — не урезанной админкой.

Приложение техника включает:

• Очередь задач — заявки от администратора, сортировка по приоритету и расстоянию. Без звонков диспетчеру: открыл приложение — видишь, что делать и в каком порядке.
• Навигация — один тап ведёт к последней GPS-позиции сломанного юнита. Без копирования координат в стороннюю карту.
• Логирование ремонта — тип неисправности, выполненный ремонт, детали и время. Данные сразу в карточке юнита и в KPI-дашборде.
• Офлайн-режим — очередь и данные юнитов кэшируются локально. Связь пропала — работа продолжается, синхронизация при восстановлении сети.

Автоматизация сервисного контура

Техник получает координаты поломки и историю обслуживания — меньше простоев и лишних звонков.

Приложение курьера

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

Шесть экранов — у каждого одна функция:

• Поиск свободного флота — карта ближайших доступных юнитов, фильтр по типу
• Карточка юнита — состояние, дата последнего ТО, зафиксированные проблемы до принятия
• Начало аренды — QR или ручной ввод ID
• Маршрут и навигация — активная аренда с пунктом назначения
• Завершение смены — возврат с подтверждением состояния и актом передачи
• Репортинг проблемы в один тап — неисправность с опциональным фото сразу в очередь техника

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

Технический стек

Backend:

• Node.js + NestJS — модульная архитектура под расширение
• PostgreSQL — транзакции: аренды, сервисные события, действия пользователей
• WebSocket — статусы юнитов в реальном времени для подключённых клиентов
• MQTT — IoT-телеметрия с GPS-трекеров

Мобильные приложения (курьер + техник):

• React Native — одна кодовая база для iOS и Android
• Офлайн-архитектура с локальным кэшем SQLite

Web (B2B-дашборд + админ-панель):

• React + TypeScript
• Mapbox GL — интерактивная карта флота с позициями в реальном времени

Инфраструктура:

• AWS (EC2, RDS, S3)
• CI/CD через GitHub Actions — автотесты и деплой

Процесс разработки: 90 дней до MVP

Недели 1–2 — Discovery. Воркшопы с командой SWAPPZ: каждый операционный сценарий, роли, матрица прав, приоритеты. Результат — ТЗ, которое не менялось в процессе разработки.

Недели 3–4 — дизайн и архитектура. UX-прототипы для пяти ролевых интерфейсов, схема БД, инфраструктура и CI/CD.

Недели 5–10 — разработка. Параллельно backend, мобильные приложения и web-дашборд. Еженедельные демо с клиентом. Обратная связь в том же спринте — без накопления бэклога.

Недели 11–12 — QA и запуск. Полевые тесты с пилотной группой техников и курьеров в Дубае. Нагрузка на real-time компоненты. Поэтапный запуск на весь флот.

03. Результат

Проект показал: глубокое проектирование требований и сценариев на старте позволяет запустить сложный продукт в сжатые сроки. Мы обеспечили 100% контроль за юнитами и прозрачность процессов — от учёта транспорта до сервисного контура.

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

Что изменилось операционно:

• Владельцы перешли от звонков и таблиц к дашборду реального времени — полная картина за 30 секунд
• Время реакции техников сократилось — приезжают с историей юнита, а не вслепую
• Начало смены курьера сократилось с 15–20 минут ручного поиска до менее 2 минут
• Реакция на угоны стала возможной — алерты геозоны впервые дали быстрый ответ
• Отчётность для инвесторов — экспорт из дашборда вместо ручных месячных сводок

Что даёт архитектура дальше:

Система рассчитана на масштабирование. Новые города, типы транспорта или операторские аккаунты — это конфигурация, а не переписывание продукта. SWAPPZ может расширять операции без пропорционального роста инженерной команды.

Нужна похожая система?

Управляете флотом или активами — и текущие инструменты не дают нужного контроля? Обсудим вашу задачу.

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

Обсудить проект — также решения для логистики и управление автопарком.