Мобильное приложение с велотрекером

Главное о кейсе

Проект стал стратегическим инструментом: приложение превращается в новый вход в экосистему бренда, усиливает продажи на маркетплейсах и готовится к будущей монетизации, аналогичной моделям топовых сервисов (например, Strava).

Провели глубокое продуктовое исследование, сформировали фич-лист и создали новую архитектуру: разработали мобильное приложение с нуля на Flutter с гибким, масштабируемым бэкендом на Java.

Как проект изменил жизнь пользователей

Для конечных пользователей мы создали продукт, который:

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

Бизнес-задача и ее решение

Задача №1: создать дополнительный канал продаж.
Новое приложение — это отдельный вход в основной бизнес клиента, который продает велосипедные запчасти на маркетплейсах. Пользователь не просто трекает поездки, но и начинает взаимодействовать с брендом регулярно, что подогревает спрос на товары.

Задача №2: подготовить фундамент для монетизации.
Как и Strava, клиент планирует вводить платный контент и премиальные функции. Сырой no-code продукт не давал возможностей для роста. Новый стек (Flutter + Java) обеспечивает гибкость: можно добавлять подписки, расширенные функции трекинга, аналитику, социальные механики.

Задача №3: ускорить выход на рынок.
Мы предложили разработать мобильное приложение в приоритете, а все динамические элементы (ачивки, баннеры) временно захардкодить. Это позволило добиться цели клиента — как можно быстрее выпустить MVP в Store, получить реальные отзывы и скорректировать фич-лист.

Крафт (мастерство), реализация, технические детали

Клиент пришёл с прототипом приложения, реализованным на no-code конструкторе Flutter Flow. Приложение не развивалось, не поддерживалось, было технически ненадежным и лишено полноценного бэкенда — вместо него использовался Firebase в виде набора разрозненных костылей. Это мешало бизнесу использовать приложение как дополнительную воронку продаж и полностью блокировало любые планы по монетизации.

Мы полностью переработали проект. Технологический стек:
Frontend: Flutter
Backend: Java

Firebase — только там, где он оправдан и не мешает гибкости.

Архитектура построена так, чтобы приложение можно было развивать годами, без ограничений no-code инструмента.

Почему отказались от Flutter Flow:
— Отсутствие нормального контроля качества разработки
Невозможность гибко масштабировать функциональность
Ограничения в кастомизации
— Нестабильная работа, приводящая к критическим багам

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

На данный момент выполнено около 60% MVP, и продукт уверенно движется к релизу.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

Процесс работы оказался особенно ценным по нескольким причинам:

Клиент впервые получил полноценное продуктовое исследование — и был удивлён глубине анализа. Именно оно стало отправной точкой для формирования фич-листа.

В процессе мы вместе с клиентом поняли, что админка сейчас не критична. Гораздо важнее — быстрое появление MVP на рынке.
В итоге мы приняли стратегическое решение:
не откладываясь, собирать приложение, а контент временно захардкодить.

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

Мы протестировали старое приложение и собрали список багов. Количество и серьёзность ошибок фактически подтвердили: переписывать с нуля — дешевле и быстрее, чем пытаться чинить конструктор.
Для клиента это стало важным инcайтом, который позволил избежать долгих и дорогих попыток “латать” устаревшее решение.

Скриншоты