Как разработать приложение как Яндекс.Лавка: доставка за 15 минут

Разработать приложение с доставкой за 15 минут, как у Яндекс.Лавки, — значит построить логистическую систему, а не курьерский сервис: сеть дарксторов в радиусе 1,5–2 км от клиента, движок пересчёта маршрута в реальном времени и синхронизацию остатков склада с 1С без задержек. Бюджет такого MVP у подрядчика начинается от 500 000 руб, срок — от трёх месяцев.

из чего состоит приложение с доставкой за 15 минут

Яндекс.Лавка и её аналоги держат обещание «15 минут» на четырёх компонентах одновременно. Дарксторы — закрытые мини-склады без торгового зала, расставленные так, чтобы курьер добегал до 90% адресов района за 5–7 минут. Движок маршрутизации пересчитывает путь курьера каждые 15–30 секунд, а не строит маршрут один раз при получении заказа. Синхронизация остатков идёт в реальном времени: если товар закончился на складе, приложение обязано убрать его из выдачи в ту же секунду, а не через час выгрузки. И слой геолокации определяет зону покрытия динамически, а не по статичному полигону на карте.

Для бизнеса это означает, что разработка мобильного приложения под hyperlocal-модель — не «ещё один интернет-магазин с доставкой», а отдельная архитектура, где склад, курьер и клиент обмениваются данными в реальном времени через один backend.

нативная разработка или кроссплатформенный фреймворк

Для клиентского приложения на React Native или Flutter разница почти не заметна — каталог и оформление заказа одинаково быстро работают в обеих моделях. А вот курьерское приложение — другое дело: фоновая геолокация, которая не должна съедать батарею за смену, и push-уведомления, которые обязаны доходить за секунды, а не с задержкой в минуту, лучше держатся на нативном коде под iOS и Android. Смешанный вариант — кроссплатформенный клиент для покупателя и нативное приложение для курьера — обычно даёт лучшее соотношение бюджета и надёжности там, где надёжность считается секундами.

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

почему возникает задержка доставки при росте заказов

Пятница, 19:40, дарксторм в Хамовниках. На складе одновременно собираются 42 заказа, курьер стоит у двери с телефоном в руке — приложение показывает «зона временно недоступна», хотя он в 300 метрах от точки выдачи. Диспетчер в чате поддержки уже получил пять одинаковых жалоб за десять минут, а очередь на сборку только растёт.

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

Если не исправить это на уровне архитектуры, бизнес теряет не только отменённые заказы. Каждый просроченный заказ — это возврат денег клиенту, испорченный рейтинг в сторе и курьер, который в следующую смену объезжает точку стороной, потому что там «вечно долго». При среднем чеке дарксторм в 800–1200 руб и 15–20 сорванных заказах в пиковый час компания теряет десятки тысяч рублей выручки за вечер — не считая клиентов, которые один раз прождали 40 минут вместо 15 и больше не открыли приложение.

как исправить синхронизацию склада и маршрутизацию курьеров

Рабочая схема строится на трёх изменениях в архитектуре.

Во-первых, зона доставки должна пересчитываться не по статичному полигону, а по текущей загрузке склада: число активных сборщиков, объём заказов в очереди, средняя скорость сборки за последние 20 минут. Как только очередь превышает пропускную способность, зона автоматически сужается — приложение честно показывает клиенту 25 минут вместо того, чтобы обещать 15 и не выполнять.

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

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

Отдельно стоит вопрос офлайн-режима: курьер в лифте или на парковке торгового центра теряет связь на 10–20 секунд, и если приложение в этот момент теряет данные заказа, он вручную звонит диспетчеру, а это те самые потерянные секунды из 15 минут. Локальный кеш заказа на устройстве курьера с фоновой синхронизацией при восстановлении связи снимает эту проблему без изменения логики сервера.

что делать, если сбои повторяются после первого исправления

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

Здесь помогает не переписывание кода, а операционный контур: приложение для персонала склада, которое показывает менеджеру нагрузку в реальном времени и позволяет перераспределить заказы на соседнюю точку до того, как клиент увидит задержку. Для сети с несколькими складами и учётом на 1С такой контур обычно делают как B2B-приложение с 1С — отдельный интерфейс для сборщиков и диспетчеров, синхронизированный с клиентским приложением через общую базу.

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

как предотвратить падение приложения в пиковые часы

Профилактика строится на трёх уровнях.

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

Отдельный сервер под учётную систему, а не общий с сайтом или бухгалтерией: если склад и приложение упираются в одну базу 1С с другими нагрузками, пиковый час доставки конкурирует за ресурсы с закрытием месяца в бухгалтерии. Выделенный сервер под 1С стоит от 3300 руб/мес и снимает эту зависимость.

Мониторинг с оповещением дежурного, а не только логи для разбора постфактум: рост очереди заказов, падение скорости геолокации, ошибки синхронизации остатков должны поднимать тревогу за минуты, а не обнаруживаться по жалобам в поддержку через час. Дешевле настроить алерт на метрику, чем объяснять клиенту, почему заказ висел 50 минут.

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

сколько стоит разработать приложение как Яндекс.Лавка

Ключевое отличие hyperlocal-доставки от обычного интернет-магазина с доставкой — в требованиях к архитектуре, а не в дизайне экранов.

Разработка клиентского приложения с базовой логикой hyperlocal-доставки у подрядчика начинается от 500 000 руб — в эту стоимость входит геолокация, каталог, оформление заказа и push-уведомления. В MVP такого масштаба обычно закладывают три отдельных интерфейса: приложение покупателя, приложение курьера с фоновой геолокацией и минимальную панель диспетчера — без последней первые же 40 одновременных заказов превращаются в ручной хаос в чате поддержки. Складской контур, интеграция с 1С и динамическая маршрутизация оцениваются отдельно, потому что зависят от числа точек и текущей учётной системы заказчика. Сопровождение — доработка логики, мониторинг пиковых нагрузок, правки после запуска — обычно тарифицируется почасово, от 3800 руб/час.

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

Точную стоимость и сроки под конкретную сеть точек и объём заказов считаем на созвоне — актуальные тарифы и форматы сотрудничества смотрите на странице цен.

❓ Частые вопросы

Сколько стоит разработать приложение с доставкой за 15 минут?

Разработка клиентского приложения с базовой логикой hyperlocal-доставки начинается от 500 000 руб — в эту сумму входят геолокация, каталог, оформление заказа и push-уведомления. Складской контур, интеграция с 1С и динамическая маршрутизация оцениваются отдельно, потому что зависят от числа точек и текущей учётной системы заказчика.

Сколько времени занимает разработка такого приложения?

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

Почему приложение показывает «зона недоступна», хотя курьер рядом?

Чаще всего зона доставки задана статичным полигоном без учёта текущей загрузки склада: сборщики не успевают за потоком заказов, а система продолжает принимать новые в ту же зону. Решение — пересчитывать зону динамически по количеству активных сборщиков и объёму текущей очереди заказов.

Нужна ли интеграция с 1С, если склад уже ведёт учёт в другой системе?

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

Как быстро окупается разработка приложения с доставкой за 15 минут?

Срок окупаемости зависит от числа дарксторов, среднего чека и плотности заказов в районе, но основной эффект даёт не рост продаж, а удержание клиентов: при среднем чеке 800–1200 руб один сорванный заказ в пиковый час обходится дороже, чем доработка архитектуры под нагрузку.