Как разработать приложение как Яндекс.Еда: архитектура, стек и экономика
*Что нужно для запуска агрегатора доставки еды уровня Яндекс.Еды: 4 типа приложений, AI-стек, юнит-экономика, реальные сроки и цена от Surf.*
Российский рынок онлайн-доставки еды растёт двузначными темпами третий год подряд, и Яндекс.Еда здесь — не просто сервис, а инженерный эталон: миллионы пользователей, сотни тысяч ресторанов, тысячи курьеров на смене одновременно. На этом фоне предприниматели и продуктовые команды всё чаще приходят к нам с вопросом: «Хотим как Яндекс.Еда, только под себя — что для этого нужно?».
В Surf мы 14 лет делаем мобильные приложения для лидеров фудтеха России — от Delivery Club до Бургер Кинга, Додо Пиццы и KFC. Эта статья — экспертный разбор: что внутри у агрегатора уровня Яндекс.Еды, какие приложения нужны, как считается экономика, какой стек, какие подводные камни в РФ и сколько это всё стоит «от» в реальных деньгах 2026 года.
Если вы CPO стартапа, директор по доставке в сети, бизнес-аналитик или CIO — читайте по порядку. Если хочется сразу обсудить ваш сценарий — внизу контакты.
Содержание
- Яндекс.Еда — что это с инженерной точки зрения
- Аналог Яндекс.Еды vs «приложение своего ресторана»: что вы строите
- Архитектура: четыре приложения и платформа под ними
- Функционал на запуск (MVP) и на масштабе
- Юнит-экономика заказа: куда уходит каждый рубль
- AI-стек агрегатора 2026
- Технологический стек: что и почему
- Юридическая и фискальная сторона запуска в РФ
- Реальные сроки и стоимость разработки
- Кейсы Surf в foodtech: что мы уже строили
- Чек-лист: 12 вопросов перед стартом
- FAQ
Ключевые моменты
1. Яндекс.Еда — что это с инженерной точки зрения
В быту Яндекс.Еда — это «приложение, в котором заказывают пиццу». С точки зрения IT-архитектуры — это трёхсторонний маркетплейс (двусторонний рынок плюс логистика), где три независимые роли работают синхронно вокруг одного заказа: гость, ресторан, курьер. Плюс четвёртая сторона — операционный персонал агрегатора, который видит всё это в админ-панели.
От чьего лица работает агрегатор: агент или принципал
Это первый вопрос, который определит вашу архитектуру, юридическую схему и налоги. Возможны две модели:
- Агентская модель. Агрегатор — посредник между рестораном и гостем. Деньги идут от гостя сразу ресторану, агрегатор берёт комиссию. Чек выбивает ресторан. Это базовая модель Яндекс.Еды для ресторанной доставки.
- Принципальная модель. Агрегатор сам покупает блюдо у ресторана и сам продаёт гостю. Деньги в моменте — у агрегатора. Чек выбивает он же. Это модель Самоката и большинства dark-kitchen-сервисов.
Выбор влияет на платёжный модуль, кассовую интеграцию, налоговую схему и UX вывода средств партнёрам. К этому ещё вернёмся в разделе про юридическую сторону.
Из чего состоит сервис: четыре приложения и один backend
«Приложение Яндекс.Еды» — это, грубо говоря, четыре отдельных продукта и общая платформа под ними:
Каждое из этих приложений ставит свои требования к стеку, дизайну, latency и режимам работы. И за каждым стоит общая «платформа» — оркестрация заказов, диспетчер курьеров, биллинг, аналитика, ML-сервисы. Подробно — в разделе 3.
Не уверены, что строить — свой агрегатор или приложение от ресторана?
Surf разберёт вашу ситуацию и пришлёт рекомендацию по архитектуре и MVP за 1 день
2. Аналог Яндекс.Еды vs «приложение своего ресторана»: что вы строите
Половина обращений «хотим как Яндекс.Еда» на поверку оказывается запросом совсем на другой продукт. Прежде чем считать смету, важно отделить четыре сценария — у них разная архитектура, разная экономика и разные сроки.
Самая частая путаница — между первой и второй колонкой. «Хочу как Яндекс.Еда» в большинстве случаев на интервью разворачивается в «хочу приложение своего ресторана, чтобы не платить агрегаторам комиссию». Это другой продукт, и про него у нас есть отдельная статья.
Если же вы действительно собираетесь делать многосторонний рынок — со множеством ресторанов-партнёров и собственным курьерским флотом — читайте дальше.
White-label-решения для агрегатора практически не существуют в зрелом виде: коробочные платформы вроде Foodpicasso закрывают сценарий «приложение от ресторана», а не «агрегатор». Поэтому для собственного маркетплейса остаётся один путь — кастомная разработка под вашу бизнес-модель и регион.
3. Архитектура: четыре приложения и платформа под ними
Опытный CTO ужмёт это до фразы «микросервисы плюс ML», но за этим стоит набор подсистем, без которых агрегатор просто не взлетит.
Клиентское приложение (iOS / Android / web)
Главная задача — за 5 секунд показать, что можно заказать тут и сейчас. Внутри:
- Геолокация и определение зоны доставки.
- Лента ресторанов с фильтрами и сортировкой по релевантности (ML-модель).
- Карточка ресторана с меню, модификаторами, наличием.
- Корзина с расчётом стоимости доставки.
- Оплата (карта, СБП, Apple/Google Pay, бонусы).
- Трекинг заказа в реальном времени.
- История заказов, повторение заказа в один тап.
- Программа лояльности (баллы, промокоды).
Сложность здесь не в фичах, а в скорости отклика и локальной релевантности: пользователь должен открыть приложение и через секунду увидеть, кто доставит ему за 30 минут.
Партнёрское приложение (планшет на кухне)
Это не сайт админки — это инструмент работы кухни. Главные требования:
- Громкий звук на новый заказ (планшет лежит в шумной кухне).
- Крупные кнопки, чтобы работать мокрыми руками.
- Стадии заказа: «принят → готовится → готов → передан курьеру».
- Стоп-лист по позициям в один тап (закончились яйца — выключили все блюда с яйцом).
- Печать чека (интеграция с фискальным регистратором).
- Расчёт времени готовки с учётом текущей загрузки кухни.
Часто это Android-приложение на дешёвых планшетах или интеграция с уже стоящей у ресторана iiko / R-Keeper. Большинство сетей не захотят ставить второй планшет, если у них уже есть POS — поэтому интеграция с iiko/R-Keeper становится обязательной, а не опциональной.
Курьерское приложение
Здесь главное — батарея, оффлайн и навигация.
- Регистрация и проверка курьера, документы, договоры (часто — самозанятый).
- Открытие/закрытие смены, выбор зоны.
- Получение заказа от диспетчера (push + звук + вибрация).
- Маршрут к ресторану и к гостю с навигацией.
- Подтверждение получения и доставки (фото, код у клиента).
- Учёт смены, начисление, чаевые, штрафы.
Курьерское приложение работает в режиме «по 8–10 часов на телефоне», поэтому критичен расход батареи и стабильность под слабым 3G.
Админская панель и кабинеты партнёров
Веб-приложения, на которых живёт операционная команда:
- Админка агрегатора: каталог ресторанов, модерация меню и контента, конфигурация зон доставки, ценообразование, рассылки, аналитика.
- Кабинет ресторана-партнёра: статистика заказов, выручка, остатки, рейтинг, выплаты.
- Кабинет курьерского флота / службы: смены, выработка, конфликты.
Эти панели часто недооценивают и делают «по остаточному принципу». А зря: операционка съедает 30–40% бюджета разработки и определяет, насколько быстро вы сможете масштабироваться без раздувания штата.
Backend и инфраструктура
Под всеми клиентами — микросервисная платформа. Минимальный набор для агрегатора:
- Каталог и поиск — индекс ресторанов и блюд, релевантность.
- Оркестрация заказа — конечный автомат «оплачен → принят → готовится → собран → в пути → доставлен».
- Диспетчер курьеров — алгоритм назначения заказа на курьера с учётом расстояния, нагрузки, рейтинга.
- Биллинг и платежи — приём денег, разделение между рестораном / агрегатором / курьером.
- Промо-движок — промокоды, кэшбэк, реферальные программы.
- Уведомления — push, SMS, email, голос.
- Аналитическое хранилище — DWH, BI, отчётность.
- ML-сервисы — рекомендации, прогноз, маршрутизация.
Это то самое «всё остальное», что неподготовленный заказчик не видит при словах «приложение как Яндекс.Еда». А по часам разработки именно бэкенд и операционка обычно больше, чем все четыре клиента вместе.
4. Функционал на запуск (MVP) и на масштабе
В первой версии не надо строить «как у Яндекса». Надо строить минимально жизнеспособный сервис, который запустится в одном городе с 20–50 ресторанами и подтвердит юнит-экономику.
MVP за 3–4 месяца: что входит, что отложить
Что обязательно:
- iOS + Android клиент (Flutter — кросс-платформа, две версии за одни сроки).
- Партнёрское приложение на Android-планшете.
- Курьерское приложение на Android.
- Веб-админка для опс-команды.
- Базовая логистика — назначение курьера ближе всего к ресторану.
- Платёжный модуль (карта + СБП).
- Уведомления (push).
- Простая программа лояльности (промокод на первый заказ).
Что отложить:
- iOS-приложение курьера (используем Android-телефон).
- Подписки и абонементы.
- Сложные ML-модели рекомендаций (берём правило «по популярности у вас в районе»).
- Динамическое ценообразование.
- Антифрод-движок (вначале хватит ручной модерации).
- Многоязычность.
- Чат-поддержка в приложении (заменяем телефоном/телеграмом).
Это MVP-подход, который мы используем для foodtech-стартапов: за 3–4 месяца получаем работающий маркетплейс в одном городе, замеряем, дорабатываем.
Полноценный сервис за 9–12 месяцев
После MVP добавляются именно те фичи, которые отличают зрелый агрегатор от «студенческого проекта»:
- ML-рекомендации блюд и ресторанов.
- Прогноз ETA на базе пробок и реальных времён готовки.
- Динамическое ценообразование доставки в часы пик.
- Подписочные модели (как Яндекс.Плюс или Самокат+).
- Многозональная логистика — несколько кухонь, несколько хабов курьеров.
- Антифрод (поддельные заказы, накрутка отзывов).
- Виджеты для партнёрских сайтов и интеграция через API.
- Голосовой помощник, фото-распознавание блюд, AR-меню (по необходимости).
К этому моменту команда обычно расширяется до 25–35 человек, появляется отдельный ML-юнит и отдельная команда поддержки.
Готовы запустить MVP агрегатора за 3 месяца?
Команда из 250 специалистов Surf и AI-ускоренная разработка — сделаем рабочий маркетплейс под ваш регион
5. Юнит-экономика заказа: куда уходит каждый рубль
Этот раздел невозможно найти ни у одного из наших конкурентов, и зря — без него любое обсуждение «сделаем как Яндекс.Еда» превращается в фантазии. На реальных проектах в foodtech структура расходов на средний заказ выглядит примерно так.
Условный заказ на 1000 ₽ в Москве:
Цифры приблизительные и зависят от региона, среднего чека и зрелости логистики, но порядок такой. Валовая маржа агрегатора — 5–10% от оборота (gross merchandise volume), а в первые месяцы — обычно отрицательная: маркетинг и привлечение партнёров не окупаются с одного заказа.
Где агрегатор делает наценку и сколько остаётся
На зрелом масштабе экономика улучшается за счёт трёх рычагов:
- Динамическое ценообразование доставки. В часы пик стоимость доставки растёт; пользователи готовы платить, потому что альтернатива — ждать дольше.
- Подписки. Самокат+ и Яндекс.Плюс закрывают комиссию за доставку в обмен на ежемесячный платёж. Это превращает разовых клиентов в LTV-ядро.
- Реклама на платформе. Промо-позиции в выдаче, спонсорские плашки, бустинг ресторанов. У Яндекс.Еды это уже значимая статья дохода, у Wolt — тоже.
Проблема курицы и яйца: как запускать двусторонний рынок
Главная инженерно-стратегическая задача нового агрегатора — двусторонний рынок. Клиенты не приходят, потому что мало ресторанов. Рестораны не подключаются, потому что мало клиентов. Эту проблему решают одним из двух подходов:
- Закрыть сторону ресторанов первой. Подключить 30–50 ресторанов в одном районе за счёт сниженной комиссии (5–10% вместо рыночных 25–30%) на старте. Когда в районе есть выбор — клиенты приходят сами.
- Закрыть сторону клиентов первой. Запустить агрегатор как extension существующей лояльной аудитории. Так это работает у крупного ритейла: X5 Доставка опирается на клиентов «Пятёрочки» и «Перекрёстка», а Купер от Сбера — на пользователей экосистемы Сбер. Прайм.
Универсального ответа нет. На наших проектах в foodtech мы рекомендуем гибрид: на старте — гиперлокальный фокус (один-два района Москвы или один город-миллионник), плотное покрытие ресторанами в зоне, агрессивная программа лояльности.
6. AI-стек агрегатора 2026
В 2026 году AI в фудтехе перестал быть «модной фичей» и стал базовой инфраструктурой. Если ваш агрегатор не использует ML — он проиграет конкурентам в скорости доставки, точности рекомендаций и качестве маршрутов.
Персонализация и рекомендации блюд
Рекомендация — это не «новинки за неделю». Это модель, которая на каждого пользователя предсказывает, что он закажет именно сейчас, исходя из:
- его истории заказов;
- времени дня и дня недели;
- погоды;
- ресторанов поблизости;
- что заказывают похожие пользователи (collaborative filtering);
- что хорошо комплектуется в корзину.
Эффект — рост среднего чека на 8–15% и удержание на 20%+. На MVP можно пропустить и использовать «топ ресторанов района», но к моменту 1000 заказов в день рекомендательная система окупается.
Прогноз спроса и динамическое ценообразование
Зная погоду на завтра, день недели, праздник и поведение пользователей, можно прогнозировать число заказов на районе с точностью ±10% — и заранее ставить курьеров под спрос. Без прогноза сервис проваливается в часы пик: либо не хватает курьеров, либо они стоят без работы и платите им вы.
Динамическое ценообразование — следующий уровень. Когда заказов в районе много, стоимость доставки повышается, что снижает спрос до доступного логистике уровня. Этот же механизм используют Uber и Яндекс.Такси.
Маршрутизация курьеров и предсказание ETA
Назначить заказ ближайшему курьеру — наивное решение. Реальная задача — оптимизация всего графа: курьер A везёт два заказа из одного ресторана в одну сторону, курьер B забирает заказ к своему текущему маршруту. Это задача vehicle routing problem с десятками ограничений (срок свежести блюда, рейтинг курьера, время смены).
ETA-модель должна учитывать пробки, реальное время готовки в ресторане (на основе истории), типичные задержки в подъезде. У зрелых сервисов точность ETA — 2–3 минуты, у наивных — 15–20.
Антифрод и контроль качества
ML здесь решает три задачи:
- Антифрод заказов. Поддельные заказы для накрутки рейтинга курьера или ресторана.
- Антифрод отзывов. Накрутка положительных, заказ негативных отзывов на конкурентов.
- Контроль качества по фото. Курьер фотографирует получение блюда — модель оценивает соответствие тому, что лежит на кухне. KFC применяет похожий подход для контроля комплектации.
Хотите внедрить AI как у Burger King или KFC?
мы делаем приложения для лидеров фудтеха России 14+ лет — и переносит лучшие AI-практики в новые проекты
7. Технологический стек: что и почему
Стек агрегатора — компромисс между скоростью разработки, надёжностью под нагрузкой и стоимостью эксплуатации.
Это не догма. На реальных проектах часть слоёв упрощается: для MVP мы часто запускаем монолит на Python с PostgreSQL и разбиваем на микросервисы, когда нагрузка реально вырастет. Преждевременная декомпозиция съедает 30–40% времени разработки.
8. Юридическая и фискальная сторона запуска в РФ
Это сторона, про которую программисты вспоминают на третьем месяце разработки. Лучше — на нулевом.
Агент или продавец: схема расчётов
Возвращаемся к выбору модели из раздела 1.
- Агентская схема. Деньги от клиента идут на счёт ресторана, агрегатор удерживает комиссию. Чек выбивает ресторан, у вас фискального обязательства по конкретному блюду нет. Этой схемой пользуется Яндекс.Еда.
- Принципальная схема. Деньги от клиента идут на счёт агрегатора, агрегатор закупает блюдо у ресторана. Чек выбивает агрегатор. Этой схемой пользуется Самокат.
Выбор влияет на:
- кто платит НДС (агент платит с комиссии, принципал — со всей суммы);
- как настроена касса (фискальный регистратор у партнёра или у вас);
- как разделяются деньги в эквайринге.
СБП, ОФД, агрегаторская касса
В РФ для крупных торгово-сервисных предприятий обязательна интеграция с СБП — порог оборота, при котором обязательство срабатывает, регулятор поэтапно снижает. Для агрегатора это и плюс (низкая комиссия 0,4–0,7% против 2% у эквайринга), и обязательство технической доступности.
Касса — отдельная история. Если работаете по агентской схеме, кассовая нагрузка лежит на ресторане. По принципальной — нужна собственная агрегаторская касса с интеграцией с ОФД (оператор фискальных данных). Поднимать её — отдельный проект на 1,5–3 месяца.
Защита персональных данных и фотоконтент
За последние годы 152-ФЗ был существенно ужесточён, и базовые требования для агрегатора такие:
- Согласие на обработку — явное, разделённое на категории (заказ, маркетинг, передача партнёрам).
- Локализация серверов — данные граждан РФ хранятся в России.
- Уведомление Роскомнадзора при обработке.
- Особый режим для биометрических данных (если используете face recognition в курьерском приложении).
Фотоконтент меню — отдельная история: фотографии блюд должны соответствовать тому, что приедет (Закон о защите прав потребителей). На MVP стоит сразу заложить процедуру модерации.
9. Реальные сроки и стоимость разработки
Сразу важная оговорка: кастомная разработка — это не «прайс-лист». Точная цена считается только после discovery-фазы под конкретный сценарий. Ниже — структура «от», которую мы используем как ориентир в первых разговорах.
Из чего складывается цена
MVP-агрегатор (1 город, 30–50 ресторанов, базовый функционал) — от 25 млн ₽:
- Discovery + продуктовое исследование: от 0,8 млн ₽
- UI/UX-дизайн четырёх продуктов: от 2,5 млн ₽
- Клиентское приложение (Flutter — iOS + Android): от 5 млн ₽
- Партнёрское приложение (Android): от 2 млн ₽
- Курьерское приложение (Android): от 2,5 млн ₽
- Веб-админка и кабинеты: от 3 млн ₽
- Backend и микросервисы: от 6 млн ₽
- Платёжный модуль и интеграция с СБП/ОФД: от 1,5 млн ₽
- QA, DevOps, инфраструктура: от 1,7 млн ₽
Полноценный сервис с ML и многозональной логистикой — от 60 млн ₽ и значительно выше в зависимости от объёма функционала.
Чтобы получить точную цифру под ваш сценарий, нужен discovery: на 2–4 недели команда продакт-менеджеров, аналитиков и архитекторов погружается в ваш бизнес, ограничения, регион. Результат — детальный план, бюджет и план релизов.
Сроки этапов
Общий горизонт «от старта дискавери до MVP в продакшене» — 4–5 месяцев. Если кто-то обещает запустить агрегатор «за месяц» — это либо обёртка над чужой платформой, либо незрелый продукт, который придётся переписывать.
Кому делать самим, кому отдавать подрядчику
- Силами штатной команды. Возможно, если у вас есть зрелый IT-блок (CTO, мобильные тимлиды, бэкенд-команда) и вы готовы выделить под проект 25–35 человек на 9–12 месяцев. Это путь, который выбрали Яндекс и крупные банки.
- Партнёр-разработчик. Чаще всего разумнее: подрядчик берёт на себя «фабрику разработки» — от дизайна до релиза, ваша команда фокусируется на стратегии, маркетинге, операционке. На рынке этой ниши — единицы зрелых команд с реальным опытом foodtech.
Пришлём вилку сроков и цены «от» для вашего сценария за 1 день
Без обязательств: укажите регион, число ресторанов, ожидания по запуску — Surf предложит варианты архитектуры и бюджета
10. Кейсы Surf в foodtech: что мы уже строили
«Сделаем как Яндекс.Еда» — звучит дерзко, и за такими словами должна стоять команда, которая такое уже делала. Вот несколько проектов, на которых Surf 14 лет нарабатывал foodtech-экспертизу.
- Delivery Club — мы делали мобильный дизайн для первого российского агрегатора доставки. Это прямой аналог сценария «как Яндекс.Еда» и наш самый ранний foodtech-проект.
- Burger King — приложение федеральной сети с 7 млн пользователей и 85% продаж через цифровые каналы. Логика отличается от агрегатора — это «приложение от ресторана» — но архитектура заказа, интеграция с кухней и платёжный модуль работают точно так же.
- Додо Пицца — единое приложение для 500+ пиццерий по миру с первым местом в App Store и Google Play. Здесь критичен масштаб и быстрая выгрузка меню по сотням точек.
- KFC — приложение для гостей и корпоративное приложение для 1100+ ресторанов сети. Здесь решали задачу автоматизации операционки сети на масштабе.
- Performance Food — сервис доставки готовых рационов. Сценарий ближе к Самокату/принципальной модели агрегатора.
Подробно про foodtech-практику — на странице surf.ru/food/. Там же — кейсы по автоматизации ресторанных сетей и сложным логистическим решениям.
11. Чек-лист: 12 вопросов перед стартом
До того как считать смету, ответьте письменно на эти 12 вопросов. Они закрывают 80% неопределённости проекта.
- Бизнес-модель. Агентская или принципальная схема? Почему?
- Регион запуска. В каком городе/районе тестируете гипотезу? Сколько там потенциальных ресторанов-партнёров?
- Стратегия двустороннего рынка. Закрываете сторону ресторанов или сторону клиентов первой?
- Курьерская служба. Свой флот, аутсорс или гибрид?
- Интеграции. С iiko/R-Keeper/Poster? С банковским эквайрингом? С СБП?
- Целевая аудитория. B2C, B2B (корпоративное питание), оба сегмента?
- Программа лояльности. Бонусы, кэшбэк, подписка? Когда внедряете?
- Юр.лицо. Готова ли структура для агентской/принципальной схемы? Кассовый узел?
- Команда. Есть ли продакт-менеджер, дизайнер, бизнес-аналитик у вас? Или подрядчик берёт это на себя?
- Бюджет на 12 месяцев. Не только разработка, но и маркетинг (минимум 50% от разработки), операционка, поддержка.
- Технические ограничения. Есть ли уже инфраструктура, которую нужно интегрировать?
- Метрики успеха MVP. По чему вы поймёте через 3 месяца после запуска, что идёте правильно?
Эти 12 вопросов — то, что мы задаём в первые две встречи discovery. Готовые ответы экономят 3–4 недели подготовки и сразу выводят на содержательный диалог об архитектуре.
FAQ
Можно ли сделать «приложение как Яндекс.Еда» за месяц-два?
Нет. Минимально жизнеспособный агрегатор с курьерами — это 4–5 месяцев работы зрелой команды от 12–15 человек. Если кто-то обещает быстрее — это либо white-label-обёртка под один бренд, либо несерьёзный подход к фискальной/юридической стороне.
Сколько стоит приложение как Яндекс.Еда?
MVP полноценного агрегатора — от 25 млн ₽. Полноценный сервис с ML — от 60 млн ₽. Точная цена считается после discovery-фазы под конкретный сценарий. Кастомная разработка не имеет фиксированного прайса.
Что выбрать: своё приложение или подключиться к Яндекс.Еде?
Это разные продукты под разные задачи. Если вы один ресторан или маленькая сеть — экономически разумнее работать через Яндекс.Еду, платя комиссию. Свой агрегатор уместен, если у вас уже есть рестораны, клиентская база и понимание региональной ниши, которую федеральные сервисы плохо закрывают.
Какой стек выбрать для мобильного приложения — Flutter или нативку?
Flutter — для клиентского приложения и кабинетов, где приоритет скорости разработки. Нативка — для приложений курьера и кухни, где критичны фон, батарея и периферия. Возможен гибрид: клиент на Flutter, курьер на нативном Android.
Чем агрегатор отличается от приложения dark kitchen?
Dark kitchen — это бизнес-модель кухни без зала, которая готовит для доставки. С точки зрения IT — это «приложение от ресторана», просто без обеденного зала. Агрегатор может работать с dark kitchen как с одним из типов партнёров.
Какие лицензии и разрешения нужны для запуска агрегатора?
Базово — статус ИП или ООО с подходящими ОКВЭДами (общепит/доставка), регистрация в качестве оператора персональных данных в Роскомнадзоре, интеграция с ОФД, согласие пользователя на 152-ФЗ. Для приёма платежей — договор с банком-эквайером или интегратором (CloudPayments, Тинькофф, ЮKassa). СБП — обязательна для крупных сервисов.
Что важнее на MVP — клиентское приложение или операционка?
Операционка. На 30–50 ресторанах ещё можно обойтись веб-таблицей вместо админки, но если ваша опс-команда не видит заказы и курьеров в одном окне — сервис не масштабируется. Заложите минимум 30% бюджета MVP на админ-инструменты.
Сколько курьеров нужно на старте?
Для одного района Москвы с 30 ресторанами на запуске — 15–25 курьеров на смену в часы пик. Точная цифра зависит от плотности заказов и геометрии района. Здесь зависимость нелинейная: если курьеров мало, заказы задерживаются — клиенты уходят — заказы падают.
Можно ли запустить агрегатор в одном маленьком городе и потом масштабировать?
Да, и это рекомендуемый подход. Гиперлокальный запуск проще и дешевле — 1 район в Москве или 1 город-миллионник. После подтверждения юнит-экономики масштабируется в соседние регионы без переписи кода (архитектура должна быть рассчитана на это сразу).
Что в проекте занимает больше всего времени?
Операционные веб-кабинеты и интеграции с фискальными системами / эквайрингом. Клиентское мобильное приложение — на удивление быстро. Курьерское приложение и кухонный планшет — средне. Главные сюрпризы по срокам обычно в интеграциях с iiko/R-Keeper и в фискальном узле.
Какие риски обычно недооценивают?
Три основных. Первый — двусторонний рынок (нет ресторанов — нет клиентов и наоборот). Второй — операционные расходы (поддержка, штраф за задержки, мошенничество). Третий — юр./фискальная сторона: команда часто закладывает «потом разберёмся», а потом приходится переписывать платёжный модуль за месяц до запуска.
Что делать, если конкретные цифры по проекту нужны срочно?
Заполните заявку на surf.ru — за 1 рабочий день вернёмся с вилкой сроков и стоимостью «от» под ваш сценарий, без обязательств с вашей стороны.
Заключение
«Приложение как Яндекс.Еда» — это не одно приложение, а система из четырёх продуктов плюс платформа с ML, операционкой и фискальным узлом. За полтора десятка лет в foodtech мы видели, как этот класс задач делает успешные стартапы и закрывает неподготовленные команды. Главные пять выводов:
- Решите бизнес-модель первой. Агент или принципал — это не «потом обсудим», это вход в архитектуру и в налоги.
- Не путайте агрегатор с приложением одного ресторана. Это четыре разных сценария с разной экономикой и сроками.
- MVP — 4–5 месяцев, 1 город, 30–50 ресторанов, от 25 млн ₽. Не пытайтесь сделать «как Яндекс» сразу — этот путь съедает деньги без обратной связи от рынка.
- AI в 2026 — не фича, а базовая инфраструктура. Рекомендации, прогноз спроса, маршрутизация — это не «через год добавим», это окупаемые блоки.
- Партнёр с опытом foodtech сокращает риски на 6–9 месяцев. Команда, которая уже делала Delivery Club, Burger King, Додо и KFC, не повторит ошибки, на которые у новой команды уйдёт первые полгода.
Готовы обсудить foodtech-проект?
Команда из 250 специалистов запустит ваш агрегатор в 2 раза быстрее и дешевле рынка за счёт AI-первого подхода
