Разработать приложение как Яндекс.Еда: архитектура и бюджет от 500 тыс ₽

Сделать полный аналог Яндекс.Еды с нуля — это не одна разработка, а минимум три параллельных продукта: приложение клиента, кабинет курьера и панель ресторана, синхронизированные через общий бэкенд. Для малого и среднего бизнеса реалистичный путь — не копировать монстра целиком, а собрать MVP с ядром той же архитектуры и бюджетом от 500 000 ₽, добавляя модули по мере роста заказов.

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

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

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

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

стек: что выбрать и почему это не вопрос вкуса

Выбор между нативной разработкой (Swift для iOS, Kotlin для Android) и кроссплатформенным фреймворком (Flutter, React Native) определяет не только сроки, но и то, во сколько обойдётся каждое следующее обновление.

нативная разработка

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

кроссплатформенный стек

Один код на iOS и Android сокращает время разработки MVP примерно вдвое по сравнению с раздельной нативной сборкой. Для сети из 5-20 точек, где приоритет — быстрый запуск и единая база кода для дальнейших правок, это разумный компромисс.

Бэкенд в обоих случаях строят на микросервисной архитектуре: отдельный сервис заказов, отдельный — платежей, отдельный — уведомлений. Такая разбивка позволяет чинить один модуль, не останавливая остальные, но требует DevOps-компетенций с первого дня, а не «когда вырастем».

где рвётся связка с учётом: сцена из практики

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

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

Цена такой недоделки — не абстрактная «потеря эффективности», а конкретные часы бухгалтера каждый вечер и риск отгрузить то, чего уже нет на складе, если остатки в приложении и в 1С разошлись на пару часов.

как выглядит правильная интеграция с 1С

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

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

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

экономика: во что реально выливается запуск

Разработка мобильного приложения такого уровня стартует от 500 000 ₽ — это MVP с каталогом, корзиной, оплатой и базовой интеграцией с учётной системой, без отдельного приложения курьера и без сложной логистической логики. Полный аналог с тремя приложениями и микросервисным бэкендом обходится в разы дороже и редко нужен бизнесу с оборотом до нескольких десятков заказов в день.

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

Отдельная статья расходов — сопровождение: правки под новые акции, обновления под изменения в API платёжных систем, устранение багов после обновлений iOS и Android. Час работы специалиста по сопровождению 1С и системного администрирования стоит от 3 800 ₽, и для компании без своего IT-отдела это дешевле, чем держать разработчика в штате ради двух правок в месяц.

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

Не нужно закладывать в первую версию всё сразу. MVP-архитектура, которая закрывает 80% задач малого и среднего бизнеса, выглядит так: одно кроссплатформенное приложение для клиента, простая панель для ресторана или магазина (часто достаточно веб-интерфейса вместо отдельного мобильного приложения) и прямая интеграция с 1С через API.

Курьерский модуль на старте можно заменить готовой службой доставки, подключённой через её API — это откладывает самую дорогую и сложную часть системы (реальную геолокацию, маршрутизацию, расчёт зарплаты курьеров) до момента, когда объём заказов оправдает собственный курьерский сервис.

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

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

Сколько стоит разработать приложение уровня Яндекс.Еды с нуля?

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

Нужен ли отдельный сервер для такого приложения?

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

Можно ли обойтись без отдельного приложения для курьеров?

На старте — да. Многие компании подключают внешнюю службу доставки через её API и добавляют собственный курьерский модуль позже, когда объём заказов вырастет и появится смысл контролировать логистику самостоятельно.

Почему заказы из приложения расходятся с данными в 1С?

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

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

Кроссплатформенный стек (Flutter, React Native) подходит для MVP и сети до 15-20 точек — он вдвое быстрее в разработке. Нативная разработка оправдана при высокой нагрузке и сложной работе с геолокацией курьеров.