Приложение для дилеров: заказы с телефона и один код под все платформы

Зачем дилеру приложение, если есть B2B-портал

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

• Монтажник или прораб на объекте видит, чего не хватает, — и заказывает с телефона сразу, а не диктует список в мессенджер «кому-нибудь в офисе».
• Продавец в торговом зале дилера проверяет наличие и цену при клиенте — за время разговора, а не «я уточню и перезвоню».
• Push-уведомление «заказ отгружен» или «счёт выставлен» приходит в момент события — вместо письма, которое прочитают завтра.
• Повтор прошлого заказа с телефона занимает минуту — а у дилеров почти все заказы повторные.
• Руководитель дилера смотрит баланс, задолженность и статусы поставок из машины, не дожидаясь офиса.

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

Что умеет мобильное приложение для дилеров

Функционально это тот же дилерский кабинет, упакованный в карман — с несколькими возможностями, которые есть только у приложения:

• Каталог с персональными ценами и честными остатками — как на портале, те же данные.
• Корзина с кратностью и минимальной партией, повтор заказа, черновики.
• Статусы заказов и push-уведомления: подтверждение, сборка, отгрузка, новые документы.
• Документы и взаиморасчёты: счета, накладные, баланс и лимит — без запроса в бухгалтерию.
• Офлайн-режим для склада и объекта: заказ собирается без сети и уходит при её появлении.
• Вход по биометрии вместо пароля — мелочь, от которой зависит, будут ли приложением пользоваться каждый день.

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

Адаптивный портал, два нативных приложения или Flutter

«Дилерам нужно мобильное» решается тремя разными способами, и у каждого есть честная зона применимости:

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

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

Приложение — клиент к вашей системе, а не отдельная разработка

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

• Если B2B-портал или кабинет уже есть — приложение подключается к нему через API. Переделывать работающее не нужно; если API нет, он проектируется отдельным этапом.
• Если системы ещё нет — приложение строится вместе с backend: я делаю обе части, и связка «клиент — сервер — обмен с учётом» проектируется целиком, а не собирается из кусков.
• Офлайн проектируется заранее: операции на складе или объекте складываются в локальную очередь и синхронизируются при появлении сети — это часть архитектуры, а не «прикрутим потом».
• Роли и права — те же, что в кабинете: закупщик заказывает, бухгалтер видит документы, руководитель — всё.

Публикация и запуск у дилеров

Готовое приложение — половина запуска; вторая половина — чтобы дилеры его поставили и начали пользоваться:

• Публикация в RuStore, App Store и Google Play входит в работу; аккаунты разработчика оформляются на вас — приложение и код принадлежат вам.
• Веб-версия из того же кода — запасной вход для дилеров, которые не хотят ничего устанавливать: та же функциональность по ссылке.
• Пилотная группа: запускать стоит на нескольких самых активных дилерах — они дадут обратную связь и станут примером для остальных.
• Обновления выходят одновременно на всех платформах — один код означает один цикл доработок, а не «на Android уже есть, на iOS ждём».
• Тестовые сборки на устройство вы получаете ещё в процессе разработки — приложение видно и можно щупать задолго до релиза.

Сколько стоит приложение для дилеров и как идёт работа

Работа начинается с разбора задачи — сценарии, платформы, состояние backend — и идёт этапами:

1. 1Разбор задачи — 1 неделя. Результат — карта MVP приложения и честный ориентир бюджета.
2. 2MVP — 4–8 недель. Ключевой сценарий дилера на всех нужных платформах, связка с backend, тестовые сборки на устройство по ходу работы.
3. 3Публикация и развитие — вывод в сторы, затем этапы по 2–4 недели по реальному использованию.

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