Запустим через несколько недель. Это будет рабочее пространство, где клиент видит ход проекта и общается с командой без потери контекста.
статус выполнения ваших заказов и ближайшие шаги команды
обмен документами, схемами, материалами и решениями по проекту
предложения по улучшению бизнеса, которые мы видим по ходу работы
единый интерфейс взаимодействия с Gigonom без потери контекста
Оповестим о запуске
Оставьте e-mail, и мы сообщим, когда кабинет можно будет подключить к вашему проекту.
Разработка мобильных приложений и MVP сервиса аренды ТокБери | Кейс Gigonom | Gigonom
MVP сервиса аренды пауербанков ТокБери: приложения, backend, сайт, станции и MQTT
Спроектировали и собрали цифровой контур сервиса аренды устройств: мобильное приложение, backend, админку, сайт, модель станций, MQTT-связку и сценарии платежей. Сайт и приложения выведены в публичный контур, а продуктовая система готова к первым пользовательским сценариям.
ТокБери развивает сервис аренды устройств через физические станции и мобильное приложение. В таком продукте нельзя ограничиться красивыми экранами: пользователь должен найти станцию, начать аренду, получить устройство, оплатить услугу, вернуть его, а команда должна видеть состояние станций, слотов, платежей и обращений.
Gigonom подключился на этапе, где нужно было собрать не отдельный сайт или приложение, а цифровой контур продукта: discovery, пользовательский путь, UX мобильного приложения, backend, админку, модель станций, MQTT-брокер, платежные сценарии, уведомления и публичный сайт.
В результате у продукта появился публичный сайт, мобильные приложения и управляемая техническая основа для первой версии сервиса. Кейс описывает запуск MVP и сборку продукта к реальным пользовательским сценариям, а не долгую статистику массовой эксплуатации.
Что было до проекта
Идея сервиса аренды выглядит простой только снаружи: пользователь открывает приложение, выбирает станцию, берет устройство и возвращает его после использования. Внутри это продукт с несколькими связанными слоями.
Нужно было синхронизировать мобильное приложение, backend, физические станции, админку, платежи, уведомления и поддержку. Каждый слой влияет на остальные: если станция не отдала корректное событие, backend не понимает состояние аренды; если админка не хранит модель станции и слоты, команда не может управлять сетью; если сценарий оплаты не связан со статусами аренды, пользовательский путь становится рискованным.
При этом проект находился на стадии запуска первой версии. Требовалось проверить связку продукта на существующих станциях, подготовить основу для выбора вендора и масштабирования, но не раздувать MVP до большой инфраструктурной системы раньше времени.
Что нашли при разборе
Главный вывод: сервис аренды через станции нужно проектировать как систему состояний, а не как набор экранов приложения.
В проекте выделили несколько критичных зон:
мобильное приложение должно вести пользователя по первому пути аренды без лишних шагов;
backend должен хранить аренды, устройства, станции, слоты, платежные состояния и события;
MQTT-брокер является отдельным слоем между backend и станциями;
для каждой станции нужны отдельные учетные данные, чтобы управлять доступом и снижать риск подмены;
модели станций могут отличаться количеством уровней и слотов, поэтому структуру данных нельзя делать слишком жесткой;
админка нужна не после масштабирования, а уже в MVP, потому что без нее сложно управлять станциями, учетными данными и состояниями;
платежи, SMS, push-уведомления и поддержка должны быть продуманы заранее, даже если часть интеграций запускается поэтапно;
сайт нужен как публичная точка входа, чтобы продукт был понятен пользователю за пределами мобильного приложения.
Отдельно разобрали нагрузку и инфраструктуру. На первом этапе важнее было поднять понятный и тестируемый контур, чем сразу проектировать избыточную отказоустойчивую схему под будущий масштаб.
Как выбрали состав работ
В первую версию вошло то, что помогает проверить MVP как работающий сервис аренды:
discovery и исследование конкурентов;
user journey и сценарии первого пути;
прототипы мобильного приложения и админки;
дизайн-система токенов и темная тема;
сайт, тексты и перенос из Figma;
модель данных, ERD и state machine аренды;
API-контракты;
discovery по станции и контракту событий;
backend и связка со станциями через MQTT;
сценарии админки для управления станциями;
RnD по платежам, SMS, push-уведомлениям и внешнему чату поддержки.
Такой состав работ позволял не спорить абстрактно о будущем продукте, а собрать проверяемый контур: что видит пользователь, что происходит на backend, какие события приходят от станции, как администратор управляет объектами системы и какие интеграции понадобятся для запуска.
Что не стали делать
Не стали начинать с максимального инфраструктурного сценария. Для MVP важнее проверить реальную связку приложения, backend, станции и админки, чем заранее строить сложный кластер под нагрузку, которой еще нет в эксплуатации.
Не стали сводить проект только к мобильным экранам. В сервисе аренды экран аренды не имеет ценности сам по себе, если за ним не собраны статусы, события станции, платежи, учетные данные, модель слотов и административные сценарии.
Не стали завязывать первую версию на один неизменяемый тип станции. В проекте заранее учли, что у разных моделей может отличаться физическая структура: количество уровней, слотов и логика событий. Это важно для дальнейшего выбора оборудования и масштабирования сети.
Не стали описывать запуск как зрелую массовую эксплуатацию с накопленными метриками. Для этого этапа результатом стал собранный цифровой контур MVP: сайт, мобильные приложения, backend, админка, модель станций и техническая основа для проверки сервиса на реальных сценариях.
Что сделали
1. Провели discovery и собрали пользовательский путь
Сначала разобрали продуктовый сценарий: как пользователь узнает о сервисе, попадает в приложение, проходит первый путь, начинает аренду, получает устройство, возвращает его и завершает оплату.
Отдельно изучили конкурентов и похожие сервисы аренды. Это помогло не проектировать приложение в вакууме: у таких продуктов уже есть ожидания по карте станций, первому экрану, оплате, уведомлениям, меню, поддержке и настройкам.
2. Спроектировали мобильное приложение
Для приложения подготовили user journey, UX первого пути, меню, настройки, кликабельный прототип и темную тему. Дизайн-система токенов позволила держать интерфейс цельным и упростить дальнейшую работу над экранами.
Главная задача приложения — не показать все возможности сервиса, а довести пользователя до аренды без лишней неопределенности: где взять устройство, что произойдет после начала аренды, как вернуть устройство и где получить помощь.
3. Опубликовали сайт продукта
Для ТокБери подготовили сайт: тексты, прототип, дизайн-перенос из Figma и публичную страницу продукта.
Сайт решает отдельную задачу в публичном контуре. Он объясняет сервис, помогает собирать внимание аудитории и создает основу для дальнейших маркетинговых и продуктовых коммуникаций.
4. Спроектировали backend и модель аренды
Для backend подготовили модель данных, ERD, state machine аренды и API-контракты. Это основа продукта: аренда должна иметь понятные состояния, переходы, события и связи с пользователем, устройством, станцией, слотом и оплатой.
State machine особенно важна для сервиса аренды. В ней фиксируется не только успешный сценарий, но и пограничные состояния: устройство не выдалось, не вернулось, станция прислала неожиданные данные, платеж требует уточнения, пользователь обратился в поддержку.
5. Разобрали связку станций через MQTT
В проекте отдельно проработали архитектурный путь между приложением, backend, MQTT-брокером и станцией. Брокер выступает посредником между backend и физическими станциями: принимает и передает сообщения, через которые система понимает состояние оборудования.
Также разобрали безопасность доступа. Для станций нужна отдельная логика учетных данных: при создании станции в админке система должна выдавать уникальные данные для подключения, чтобы доступом можно было управлять и ограничивать риски подмены или несанкционированного подключения.
6. Спроектировали админку для управления станциями
Админка нужна не только для просмотра данных. В MVP она становится рабочим инструментом команды: создать станцию, задать модель, уровни и слоты, управлять учетными данными, видеть статусы и готовить систему к тестам.
Это снижает зависимость операционной команды от разработчиков. Когда у продукта появляются новые станции, тестовые подключения и изменения в оборудовании, базовые действия должны выполняться через управляемый интерфейс.
7. Проработали платежи, уведомления и поддержку
Для запуска сервиса аренды важны не только станции и приложение. Пользователь должен получать понятные уведомления, оплачивать аренду и иметь канал поддержки, если что-то пошло не по сценарию.
Поэтому в проект вошел RnD по платежам, SMS, push-уведомлениям и внешнему чату поддержки. Эти элементы не перегружают MVP, но заранее задают контур продукта, без которого аренда быстро превращается в ручную операционную работу.
Что изменилось после запуска MVP
У ТокБери появился публичный цифровой контур MVP сервиса аренды: сайт, мобильные приложения, backend, админка, модель станций, MQTT-связка и сценарии платежей.
Проект перешел от идеи и отдельных продуктовых гипотез к связанной системе: мобильное приложение, backend, админка, модель станций, MQTT-брокер, платежные сценарии, уведомления и поддержка описаны как единый продуктовый процесс.
Команда получила основу для проверки связки на реальных станциях. Можно тестировать не только интерфейс приложения, но и полный путь: администратор создает станцию, система связывает ее с backend, станция передает события через MQTT, пользователь проходит сценарий аренды в приложении.
На этом этапе еще нет накопленной статистики по удержанию, повторным арендам и экономике масштабирования. Текущий результат — запущенный MVP, публичная точка входа и техническая основа для проверки сервиса перед развитием сети.
Что можно развивать дальше
Пройти первый цикл пользовательских сценариев после публичного запуска приложений.
Проверить работу связки на реальных станциях в эксплуатации: выдача, возврат, события, ошибки и восстановление после сбоев.
Настроить продуктовую аналитику: установка, регистрация, первый путь, старт аренды, возврат, оплата, обращение в поддержку.
Развивать мониторинг станций и событий MQTT.
Уточнять модель оборудования после выбора вендора и тестов разных станций.
Расширять админку под операционное управление сетью.
Развивать платежный контур, уведомления и поддержку на основе первых реальных обращений.
Для каких задач подходит похожий подход
Похожий подход подходит компаниям, у которых:
мобильное приложение связано с физическими устройствами, станциями или оборудованием;
нужно проверить MVP до большой закупки или масштабирования сети;
пользовательский сценарий зависит от backend, платежей, уведомлений и состояния устройства;
нужен не только интерфейс, но и state machine, API-контракты и модель данных;
админка требуется уже в первой версии, потому что без нее невозможно управлять объектами системы;
есть IoT-связка, брокер сообщений или другой слой обмена событиями между backend и устройствами;
важно заранее отделить MVP от будущей инфраструктуры под большой масштаб.
Если продукт должен работать не только на экране телефона, а еще и в физической среде, начинать стоит с диагностики всей связки: пользовательский путь, backend, оборудование, события, платежи, админка и поддержка. Так MVP проверяет реальный сервис, а не только дизайн приложения.
Gigonom может разобрать такой продукт, спроектировать MVP, связать мобильное приложение с backend, админкой и физическими устройствами, а затем подготовить систему к тестам и запуску.
Хотите такой же понятный проект?
Разберём задачу, предложим структуру решения и покажем, с чего лучше начать.
