мобильное приложение для маркетплейса запчастей

ООО «Сервис» — компания, специализирующаяся на продаже легковых автомобилей и коммерческого транспорта малой грузоподъёмности.

В дополнение к основному ассортименту компания также занимается торговлей автозапчастями и комплектующими — как оригинальными, так и аналогами от проверенных поставщиков.

Ассортимент включает:

• новые легковые автомобили различных марок;
• малотоннажные грузовые автомобили для бизнеса;
• запасные части и расходные материалы: тормозные системы, фильтры, шины, аккумуляторы, детали подвески и др.

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

До нашего привлечения проект находился в начальной стадии MVP с участием нескольких сторонних специалистов, что не позволило довести его до полноценного релиза.

Компания искала команду, которая сможет:

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

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

Создание мобильного приложения (маркетплейса автозапчастей и техники) с учётом:

• сложной бизнес-логики;
• масштабируемой архитектуры;
• кросс-ролвого взаимодействия (один аккаунт = несколько ролей и профилей).
• наработок предыдущей команды

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

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

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

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

В работе над проектом с нашей стороны участвовала команда из шести человек: два разработчика на Flutter, два backend-разработчика, менеджер проекта и тестировщик.
Работа над проектом началась с технического аудита и анализа текущего состояния: команда провела ревизию кода, API и требований, чтобы определить слабые места и риски.

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

Работа над проектом была разделена на четыре этапа:

1. Разработка функционала по разделами “Склад” и “Заявки”
2. Реализация разделов “Заказы” и “Корзина”
3. Интеграция со службами доставки для отслеживания статусов доставки в транспортных компаниях и интеграция с платежными системами для проведения платежных операций
4. Реализация разделов “Профиль”, “Уведомления”, “Чаты” и “Обучение”

В первую очередь команда занялась доработкой уже существующего решения, а также реализовала недостающий функционал. Параллельно велась разработка backend-части: было спроектировано и реализовано API, работа с товарами, заказами и ролями. 

Раздел «Заявки» является одним из центральных в бизнес-логике приложения — как для продавцов, так и для покупателей. В этом разделе отображаются все входящие для продавца и исходящие для покупателя запросы на приобретение товаров, а также взаимодействие между сторонами сделки.

Основной функционал:

• Листинг заявок для покупателя и продавца: покупатель видит свои отправленные запросы, а продавец поступившие заявки от всех покупателей. Для продавцов реализованы фильтрация, поиск и сортировка для быстрого ориентирования в большом объёме данных.
• Детальная карточка заявки с информацией о товаре и сторонах сделки с возможностью для продавца добавить заявку в избранное и для покупателя просмотреть все доступные предложения по его заявке.
• Действия по роли пользователя: покупатель может создавать, копировать, отправлять заявки в архив или размещать их под заказ; продавец просматривать листинг, создавать предложения и добавлять заявки в избранное.
• Интерфейс под каждую роль: покупатели и продавцы видят разные кнопки, статусы и сценарии, что упрощает работу и снижает ошибки.
• Организация заявок: покупатели создают папки для удобного управления своими запросами, а продавцы сохраняют подборки по заявкам для фильтрации по заданным параметрам и получения уведомлений о новых релевантных запросах.

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

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

Основной функционал для покупателя:

• Листинг товаров для покупателя и продавца: покупатель видит доступный каталог, продавец собственный ассортимент.
• Детальная карточка товара с описанием, характеристиками и фото; покупатель может сразу добавить товар в корзину.
• Добавление новых позиций на склад и редактирование уже созданных карточек для продавца — обновление цен, фото, описаний, остатков.
• Массовые действия с товарами для продавца: выделение нескольких или всех позиций и выполнение сразу нескольких операций. Для активных товаров — перемещение в архив или в папку; для архивных — возврат в актуальное или удаление.
• Фильтрация, сортировка и поиск по складу для всех ролей — быстрый доступ к нужным товарам даже при большом объёме данных.
• Автоматическое уменьшение доступного количества товара на складе у продавца после оформления заказа на определённое количество данного товара.
• Организация каталога: продавцы могут создавать папки для группировки ассортимента, а покупатели подборки товаров под свои интересы.

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

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

Основной функционал:

• Просмотр заказов: пользователи видят все активные и завершённые заказы, что позволяет отслеживать историю покупок и статусы текущих заказов.
• Детальная карточка заказа: содержит информацию о товарах, покупателе/продавце и текущем статусе, что облегчает контроль и обработку каждого заказа.
• Подтверждение получения товара: при самовывозе покупатель и продавец фиксируют факт передачи, обеспечивая прозрачность и точность расчётов.
• Изменение статусов: статусы обновляются автоматически (для доставки) или вручную (для самовывоза), что обеспечивает актуальную информацию для всех участников.
• Добавление накладных: продавцы должны прикреплять сканы ТТН для контроля отправлений и подтверждения отправки.
• Способы доставки: «Самовывоз» и «Доставка до ПВЗ» с отображением актуального состояния заказа и возможностью выбора удобного варианта получения.
• Отмена заказов: заказы могут быть отменены вручную пользователями или автоматически системой при несоблюдении сроков оплаты, отправки или получения, что поддерживает актуальность данных и снижает нагрузку на участников.

Особенности реализации раздела:

• Сложная бизнес-логика формирования заказов из корзины, с учётом группировки по продавцам;
• Привязка заказов к конкретному аккаунту и роли — доступ и действия строго разграничены;
• Синхронизация с разделами «Заявки» и «Склад»: зарезервированные товары помечались, а при подтверждении — списывались с остатка;
• Система уведомлений по изменениям статуса заказа;
• Статусная система с возможностью трекать каждый этап — от оформления до завершения.

Раздел «Корзина» реализован как инструмент для покупателей, позволяющий собрать интересующие позиции от разных продавцов перед оформлением заказа. В корзину можно добавлять товары продавцов
со склада и предложения продавцов по заявкам.

Основной функционал:

• Добавление товаров и предложений: покупатели могут добавлять товары со склада и предложения по заявкам для оформления заказа.
• Изменение и отмена заказа: покупатель может корректировать количество товаров или полностью удалять позиции из корзины до оформления заказа.
• Проверка доступности: система автоматически проверяет наличие товаров у продавцов, предотвращая оформление недоступных позиций.
• Оформление заказа: покупатель может оформить заказ на все позиции из корзины, система автоматически подставляет данные профиля, позволяет выбрать способ доставки («Самовывоз» или «Доставка до ПВЗ») и обеспечивает контроль остатков товаров.
• Сохранение корзины между сессиями: корзина сохраняется при выходе из приложения или переключении аккаунтов и ролей, что обеспечивает непрерывность работы.

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

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

Если товар был перемещен в архив или предложение по заявке было отменено продавцом, тогда у пользователя нет возможности оформить заказ, только удалить его из корзины.

Особенности реализации раздела:

• Корзина синхронизировалась с backend и локальным хранилищем;
• Реализована логика восстановления корзины после выхода или переключения аккаунта;
• Применялось кэширование и оптимизация перерисовок при изменении состояния.

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

Основной функционал:

• Продавец указывает транспортную компанию и трек-номер при оформлении отправки;
• В карточке заказа отображаются сведения о перевозчике и текущий статус доставки;
• Покупатель получает актуальную информацию о перемещении заказа в режиме реального времени;
• Поддержка уведомлений об изменении статуса доставки;
• Информация обновляется автоматически через API транспортной компании.

Особенности реализации раздела:

• Интеграция реализована через REST API ведущих транспортных компаний;
• Система периодически запрашивает обновления по активным трек-номерам;
• Реализована проверка и обработка ошибок в случае недоступности API;
• Возможность масштабирования под новых перевозчиков без изменения бизнес-логики.

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

Номинальный счёт

На первом этапе была внедрена работа с номинальным счётом ТБ
— специальным банковским счётом, через который осуществляется приём
и распределение денежных средств между пользователями маркетплейса. Все платежи от покупателей поступали на этот счёт, после чего идентифицировались на конкретного продавца (бенефициара). Далее создавалась «сделка» — банковская операция по выводу средств продавцу.

Особенности реализации:

• Проверка валидности реквизитов продавца (ИНН, КПП, БИК и т.д.) при регистрации, чтобы избежать проблем с выплатами;
• Автоматическое создание бенефициаров на стороне банка для каждого продавца;
• Обработка возвратов, отмен и частичных выкупов с соблюдением требований банка;
• Интеграция через API с обязательной криптографической подписью (RSA);
• Прозрачный процесс для пользователя: все средства доставляются только после успешной проверки и идентификации.

Эквайринг ТБ

Позже был подключён эквайринг от Точка Банка для приёма онлайн-платежей по картам. Это позволило пользователям оплачивать заказы напрямую в системе. Однако особенности эквайринга (например, агрегированные платежи за день и отложенные переводы) потребовали пересмотра логики учёта.

Особенности реализации:

• Подключение эквайринга через API Точка Банка с поддержкой агрегированных платежей;
• Учет возвратов: при частичном или полном возврате суммы корректировались данные внутреннего баланса продавца;
• Защита от повторной обработки: система исключала дублирование поступлений при повторной отправке данных со стороны банка;
• Автоматическая сверка платежей с заказами на стороне платформы;
• Реализация сценариев на случай ошибок при проведении платежей или отмен.

Реализация интеграции с платёжной системой Точка Банка позволила платформе обеспечить надёжный и прозрачный процесс обработки финансовых операций. Мы учли как требования регуляторов, так и реальные сценарии взаимодействия между продавцами и покупателями.
В результате платформа получила стабильную и масштабируемую платёжную инфраструктуру, соответствующую требованиям законодательства и удобную как для покупателей, так и для продавцов.

Раздел «Профиль» — это центральная точка управления учётной записью пользователя, включающая доступ к данным аккаунта, балансу, документам, обучающим материалам и службе поддержки. Он адаптирован под разные сценарии использования и различается в зависимости от текущей роли (продавец / покупатель) у выбранного аккаунта.

Раздел «Профиль» — покупатель

Раздел «Профиль» — продавец

Основной функционал:

• Раздел “Информация”: просмотр и редактирование данных аккаунта: название организации, ИНН, платежные и контактные данные, и т. д.;
• Раздел “Техника”: управление карточками техники пользователя, создание новых карточек, редактирование и удаление существующих;
• Раздел “Мой рейтинг”: отображение текущего рейтинга пользователя на основе отзывов других пользователей, просмотр всех отзывов;
• Раздел "Баланс": отображение текущих средств, истории операций и возможность вывода средств;
• Раздел "Техническая поддержка": создание заявки для обращения в техподдержку;
• Раздел “Партнерская программа”: отображение персонального промокода по реферальной программе, просмотр списка существующих рефералов пользователя;
• Раздел “Инструкция/обучение: доступ к обучающим материалам и документации;
• Раздел “Документы”: доступ ко всем юридическим материалам, связанным с использованием платформы.

Логика разделения по типам пользователя

В системе реализовано разделение аккаунтов на физических и юридических лиц как для покупателей, так и для продавцов, от этого зависит:

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

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

Раздел “Партнерская программа”

На платформе реализована простая и прозрачная реферальная программа, позволяющая пользователям получать бонусы за привлечение новых участников.

• Каждый пользователь получает уникальный реферальный промокод, который можно передать другим людям.
• Новый пользователь указывает промокод при регистрации. Это закрепляет его как реферала за пригласившим.
• После того как реферал оформляет свой первый заказ, пригласившему пользователю начисляется 1% от суммы заказа на внутренний баланс.

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

Особенности реализации раздела:

• Все данные и действия в профиле были строго привязаны к текущему активному аккаунту и роли — это исключало возможность случайного вмешательства между контекстами;
• Были реализованы проверки прав доступа к определённым разделам в зависимости от роли.

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

Таким образом, в рамках одной пользовательской сессии необходимо поддерживать до восьми различных состояний профиля
(4 аккаунта × 2 роли).

Это требовало продуманной логики по:

• Управлению текущим активным профилем: четкое определение и поддержка данных для выбранной в данный момент комбинации «аккаунт-роль».
• Хранению и изоляции данных: надёжный механизм для сохранения, загрузки и очистки данных при переключении между аккаунтами и ролями, чтобы информация одного профиля не смешивалась с другим.
• Синхронизации состояния между сессиями: обеспечение согласованности данных о выбранном аккаунте и роли между:
• Адаптации интерфейса и функционала: мгновенное отображение соответствующего интерфейса, контента и доступных функций в зависимости от currently active (текущей активной) роли (покупатель или продавец).

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

Это позволило:

• Чётко разделить логику отображения и поведения интерфейса в зависимости от роли;
• Избежать повторной авторизации при переключении аккаунтов и ролей;
• Гибко управлять состоянием приложения и кэшированием данных;
• Синхронизировать контекст между несколькими вкладками или устройствами.

Особенности реализации раздела:

• На стороне мобильного приложения логика работы с ролями была реализована с учётом BLoC-архитектуры: переключение между аккаунтами инициировало соответствующие события и пересоздавало нужные состояния.
• Для корректной работы реализовано жёсткое разделение данных по ролям и аккаунтам — это исключает отображение некорректной информации и защищает от конфликтов при одновременной работе с несколькими вкладками или устройствами.
• Все действия пользователя (например, добавление в корзину, отправка заявки, открытие чата) выполнялись в контексте активного аккаунта и роли — при переключении контекста происходит полная перегрузка связанных данных и интерфейсных компонентов.

Раздел «Уведомления» был разработан для оперативного информирования пользователей о событиях, связанных с их аккаунтами, заказами, товарами, заявками и чатом. Уведомления позволяют пользователям не пропускать важные изменения и быстрее реагировать на действия контрагентов.

Основной функционал:

• Отображение уведомлений по ключевым событиям: новые заявки, отклики на заявки, обновления заказов, новые сообщения в чатах, изменения по товарам и тд.;
• Разные типы уведомлений в зависимости от роли пользователя (покупатель / продавец);
• Визуальный индикатор новых уведомлений;
• Отображение списка уведомлений по каждой роли для одного аккаунта;
• Поддержка push-уведомлений через Firebase Messaging.

Особенности реализации раздела:

• Уведомления приходили в реальном времени — через WebSocket-соединение;
• Сообщения автоматически группируются по типу событий и отображаются в зависимости от активного профиля и роли;
• Реализована логика "прочитано / непрочитано" и очистки уведомлений.

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

Раздел «Чаты» — покупатель

Раздел «Чаты» — покупатель

Основной функционал:

• Чаты по каждой заявке, товару или заказу (привязка к конкретной сущности);
• Отображение истории переписки, в том числе по завершённым сделкам;
• Система уведомлений о новых сообщениях;
• Возможность быстрого перехода из карточки заявки/заказа в соответствующий чат.

Особенности реализации раздела:

• Реализация через WebSocket для обновления сообщений в реальном времени;
• Чаты интегрированы в общую систему аккаунтов и ролей — при переключении контекста загружаются соответствующие переписки;
• при разработке пришлось учитывать сложность идентификации участников: сообщения формируются с учётом активного аккаунта и его роли (продавец или покупатель);
• Реализация защиты от повторной отправки сообщений и обработки ошибок соединения.

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

В результате были выявлены следующие ключевые сложности:

• Отсутствие документации

Как по frontend-, так и по backend-части отсутствовали технические описания, что усложняло вхождение в проект и замедляло работу на старте.

• Разрозненная кодовая база

Код, доставшийся от предыдущих исполнителей, был фрагментирован, плохо структурирован и содержал устаревшие решения. Это требовало масштабного рефакторинга и выстраивания единого подхода к архитектуре.

• Сильная связанность компонентов

Из-за отсутствия модульности изменения в одном участке приложения затрагивали множество других, что снижало надёжность и усложняло масштабирование.

• Частые изменения бизнес-требований

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

• Неудобный и несогласованный API

Интерфейсы API содержали дублирующиеся или конфликтующие эндпоинты, непоследовательную логику и не отражали реальную бизнес-модель.

• Неясность в логике аккаунтов и ролей

Бизнес-логика, связанная с ролями пользователей и их связями с профилями, не была определена на старте и прояснялась по ходу реализации.

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

Приложение было выпущено в продакшн, и им уже начали пользоваться реальные пользователи:

• за первые недели зарегистрировалось около 50 пользователей, из них до 30 аккаунтов продавцов;
• размещено более 20000 товарных позиций и создано 70 заявок на покупку.