Как разработать приложение как Delivery Club: история и архитектура
*Полная история Delivery Club от запуска в 2009 до перехода под Яндекс в 2022 и архитектура агрегатора доставки. Опыт Surf на разработке DC с 2012 и стек для 2026.*
Delivery Club — это история российского foodtech. Сервис, который в 2009 году запустили два предпринимателя и который к 2015 стал одним из самых популярных агрегаторов доставки еды в стране. Через две смены собственников, многомиллионные инвестиции и эпоху мобильных приложений, в 2022 году бренд перешёл к Яндексу, в 2023-м был переименован сначала в «Маркет Деливери», а затем в «Деливери». Самостоятельный бренд Delivery Club перестал существовать, но архитектура и продуктовые механики, которые он задал, по-прежнему лежат в фундаменте российского foodtech.
Эта статья — про то, как был устроен Delivery Club изнутри, почему он определял рынок десять лет и что забрать из его опыта в новый проект 2026 года. Материал — для основателей foodtech-стартапов, продуктовых команд и аналитиков рынка. Мы делали мобильные приложения Delivery Club с 2012 года — публичный кейс по DC лежит в основе аналитической части.
Если вы ищете архитектурный гайд по действующему лидеру рынка — у нас есть отдельный материал «как разработать приложение как Яндекс.Еда». Здесь — фокус на истории и на том, чему научила нас целая эпоха.
Содержание
- Что такое Delivery Club и его место в истории foodtech
- Хронология: 2009 → 2022 → Деливери
- Архитектура приложения Delivery Club
- MVP 2012-2013: с чего всё начиналось
- Почему Delivery Club проиграл Яндекс.Еде
- Текущая карта рынка foodtech-агрегаторов 2026
- Что взять из опыта DC в проект 2026 — 7 уроков
- Архитектура агрегатора 2026 — обязательный минимум
- Стоимость и сроки разработки сегодня
- Кейсы Surf в смежных задачах
- FAQ
Ключевые моменты
Ключевое за 30 секунд
- Delivery Club основан в 2009 году Левоном Оганесяном и Анной Шкириной. До 2014 года развивался как независимый сервис.
- Главные сделки: 2014 — Foodpanda (Rocket Internet) купила 100% акций; ноябрь 2016 — Mail.ru Group выкупил Delivery Club у Rocket Internet за $100 млн; 2019 — переход в O2O-Холдинг (СП VK и Сбера); август-сентябрь 2022 — продажа Яндексу.
- Бренд переименован в 2026: сначала «Маркет Деливери» (5 июня), затем «Деливери» (16 ноября). Сервис продолжает работать в составе Яндекса.
- Главные уроки для архитектуры: мультиплатформенность (iOS / Android / Windows Phone / планшеты на старте), глубокая интеграция с банками (Delivery Club — один из первых кейсов Apple Pay в РФ), оркестрация в реальном времени заказа, итерации каждые 2-4 недели.
- Стоимость аналогичного приложения сегодня: региональный MVP — от 15 млн ₽, федеральная платформа — от 60 млн ₽.
1. Что такое Delivery Club и его место в истории foodtech
В 2009 году у Левона Оганесяна и Анны Шкириной возникла идея: собрать в одном веб-сервисе рестораны Москвы, которые соглашаются принимать заказы онлайн и доставлять их. На тот момент в России не было ни единого канала заказа еды из ресторанов — каждый клиент звонил в кафе по телефону, диктовал заказ и адрес. Мобильных приложений у заведений не было, агрегаторов не существовало.
Через несколько лет, после Android-приложения 2013 года и инвестиций раундом, Delivery Club превратился в первый по-настоящему массовый российский foodtech-агрегатор. К пику развития на платформе работали тысячи ресторанов, а большинство заказов клиенты делали через мобильное приложение.
Категориально Delivery Club был двусторонним маркетплейсом — он соединял ресторан, готовый принимать заказы, и клиента, готового платить за доставку. На разных этапах сервис экспериментировал с тремя моделями логистики:
- Только агрегатор — ресторан везёт сам, платформа берёт комиссию за лид.
- Платформа с собственной курьерской службой — DC организует доставку из ресторанов без своей логистики.
- Гибрид — крупные сети везут сами, маленькие — через курьеров DC.
Эти три модели сегодня стандарт всех агрегаторов, но в 2014 году DC первым в РФ показал, как они работают вместе. Подробнее про класс задач — на странице приложения для агрегатора доставки еды.
2. Хронология: 2009 → 2022 → Деливери
Полный жизненный цикл бренда — 14 лет, три смены собственников, два переименования. Это редкая для российского технологического рынка история, где каждый этап даёт продуктовый урок.
Surf начал работать с Delivery Club в 2012-2013 годах, в период активного роста и старта мобильной эры — и продолжал вести проект на протяжении нескольких лет, включая период владения Mail.ru Group. Конкретные публичные данные — в нашем кейсе DC.
3. Архитектура приложения Delivery Club
Архитектурно Delivery Club — это типовой пример того, как двусторонний foodtech-маркетплейс эволюционировал из веб-сервиса в мультиплатформенное мобильное приложение. На пике в системе одновременно жили несколько приложений и платформ:
- Клиентское приложение для пользователей: iOS, Android, Windows Phone, отдельные планшетные версии.
- Веб-сайт как альтернативный канал заказа и SEO-вход для клиентов из поиска.
- B2B-кабинет ресторана для управления меню, расписанием, ценами, акциями.
- Приложение курьера (для городов, где работала собственная логистика DC).
- Внутренний оператор-интерфейс для обработки сложных кейсов (отмены, претензии, ручная маршрутизация).
- Backend-платформа с очередями заказов, биллингом, программой лояльности, аналитикой.
Главное архитектурное решение, которое потом тиражировал весь рынок — разделение фронт-уровня (приложений) и оркестратора заказа. Когда клиент нажимал «Заказать», в системе одновременно срабатывали:
- Создание заказа в общем оркестраторе.
- Маршрутизация в ресторан (через интеграцию или ручной телефонный канал в раннюю эпоху).
- Списание оплаты через банковский эквайринг или сохранённую карту.
- Push-уведомление клиенту с подтверждением.
- Запуск таймера приготовления / доставки.
Эта пятишаговая модель — и есть базовая архитектура любого современного foodtech-агрегатора. Detal-by-detail — в нашем архитектурном разборе приложения как Яндекс.Еда.
Что Delivery Club сделал первым в РФ:
- Apple Pay в foodtech 2016 — один из первых крупных кейсов внедрения в стране. Сегодня этот способ оплаты — стандарт, но тогда DC был ранним адаптером.
- Сохранение карт для повторных заказов — снижение трения в чек-ауте, ключевой драйвер роста conversion.
- Реферальная программа с deep linking и QR-кодами — масштабируемый канал привлечения новых клиентов с привязкой к источнику.
- Чистая архитектура для аудита кода — этот фактор позднее помог при сделках со сменой собственников.
4. MVP 2012-2013: с чего всё начиналось
Когда в 2013 году DC запускал Android-приложение, Surf взял проект и собрал прототип за три дня. Это была не финальная версия — но кликабельный продукт с анимацией и базовой логикой, на котором можно было показать инвесторам и команде, как будет работать сервис.
С этого прототипа начался цикл итеративной разработки. Дальше — два года полной разработки до передачи проекта внутренней команде DC и обновления каждые 2-4 недели вплоть до 2019 года. Это редкая для российской разработки практика — обычно скорость итераций падает после первого года, у DC она держалась около шести лет.
Что было в MVP 2013 года (из публичного кейса):
- Каталог ресторанов с фильтрами по городу и кухне.
- Меню ресторана с фотографиями и описаниями блюд.
- Корзина и оформление заказа.
- Интегрированная оплата картами Альфа-Банка и Сбербанка (на старте).
- Сохранение карт для повторных заказов.
- Базовый статус заказа.
Чего в MVP не было (добавилось в более поздних релизах):
- Apple Pay (внедрён в 2016).
- Полноценная программа лояльности.
- Реферальная программа с deep linking.
- Live-трекинг курьера.
- Подписочная модель.
Этот баланс — критичный для любого MVP foodtech-агрегатора: на запуск идёт минимум функций, которые проверяют главную гипотезу (люди заказывают через приложение). Всё остальное — итеративно. Сегодня этот подход — стандарт, но в 2013-м он был ещё не очевиден. Подробнее про подход — на странице MVP foodtech-приложения за 2-3 месяца.
Из публичного кейса: «Чтобы создать поистине массовый продукт, нужно видеть его в перспективе и работать с теми, кто разделяет это видение» — Даниил Шулейко, на тот момент Product/Marketing Director Delivery Club.
5. Почему Delivery Club проиграл Яндекс.Еде
К 2020 году Delivery Club был всё ещё крупнейшим игроком — но динамика рынка уже сместилась. К моменту продажи Яндексу в 2022 году бренд явно проигрывал Яндекс.Еде по продуктовому темпу, экосистемному эффекту и UX. Несколько причин этого ухода — поучительны для любого нового foodtech-проекта.
Причина 1 — экосистемный эффект. Яндекс.Еда работала в связке с Яндекс.Картами, Яндекс.Поиском, Яндекс.Плюсом, Яндекс.Лавкой и Яндекс.Доставкой. DC после ухода в VK / Сбер пытался строить аналогичную экосистему через Самокат, но интеграции там работали менее плотно.
Причина 2 — единый ID и UX. Один аккаунт «Яндекс.ID» открывал доступ ко всем сервисам — от поиска до подписки. Авторизоваться в Яндекс.Еде — секунда. Авторизоваться в DC после ребрендинга в VK — требовало переключения экосистемы.
Причина 3 — Яндекс.Плюс как удержание. Подписка с бесплатной доставкой, кэшбэком, скидками во всех сервисах удерживала пользователей сильнее, чем разовые промокоды DC. Подробнее про эту модель — в статье «как Самокат+ и Сбер. Прайм».
Причина 4 — продуктовый темп. Яндекс наращивал команду продуктовых разработчиков быстрее, и темп релиза новых функций (Яндекс.Лавка под зонтиком, AR-меню, AI-рекомендации) в Яндексе перегнал DC.
Причина 5 — корпоративная нестабильность. Каждая смена собственника — Foodpanda → Mail.ru → O2O → Яндекс — это месяцы реорганизаций, заморозка раундов найма и иногда уход ключевых людей. Бренд, который десять лет менял владельцев, не мог конкурировать с проектом, на котором никогда не менялся ни состав акционеров, ни стратегия.
Урок здесь нестандартный: дело было не в технологии, а в продукте, экосистеме и стратегической стабильности. DC проиграл не потому, что плохо разработан, а потому что у конкурента появилась платформенная история, которую двусторонний агрегатор без своих карт, поиска и подписки догнать не мог.
Хотите собрать foodtech-агрегатор с прицелом на лидерство?
мы соберём ТЗ за 30 минут и пришлёт план запуска от MVP до федеральной платформы
6. Текущая карта рынка foodtech-агрегаторов 2026
После закрытия бренда DC рынок российского foodtech-агрегатора фактически разделился между несколькими игроками. Карта 2026 года выглядит так:
Главные направления, в которых ещё есть место для нового игрока:
- Региональные агрегаторы в городах, где Яндекс.Еда работает поверхностно.
- Узкие вертикали — национальные кухни, веганские рестораны, фуд-рескью (см. как Too Good To Go).
- B2B-агрегаторы — корпоративные обеды, кейтеринг, доставка в офисы.
- HoReCa-снабжение — двусторонние маркетплейсы между поставщиками и ресторанами.
Делать прямой клон Яндекс.Еды в 2026-м без экосистемы — путь в никуда. Делать узкую, специализированную модель с уникальным UX — вполне разумная стратегия.
Полный аналитический разбор индустрии — в материале про foodtech-тренды 2026.
7. Что взять из опыта DC в проект 2026 — 7 уроков
10 лет жизни Delivery Club — это набор продуктовых и инженерных решений, которые остаются актуальными.
Урок 1 — мобайл-первый с первого дня. Когда DC запускал Android в 2013-м, доля мобильных заказов была меньше 10%. Через 6 лет — 70%. Сегодня запускать foodtech без мобильного приложения с дня 1 — это сразу проиграть рынку.
Урок 2 — итерации каждые 2-4 недели. Не «релиз раз в квартал», не «большая весенняя версия». В DC цикл релиза не падал ниже двух недель шесть лет подряд — это и держало продукт впереди.
Урок 3 — глубокая интеграция с банками. Apple Pay в 2016, сохранение карт, СБП в эпоху ухода Apple Pay — каждая такая интеграция снижала трение в чек-ауте на проценты, которые в сумме дают рост конверсии.
Урок 4 — чистая архитектура с возможностью аудита. Это пригодилось при каждой смене собственника. Сегодня — это пригодится при привлечении инвестиций или партнёра. Грязный код = сорванная сделка через 3 года.
Урок 5 — реферальная программа как канал роста. Deep linking + QR-коды + промокод за приведённого друга — это то, что DC масштабировал раньше других и что до сих пор работает в Яндекс.Еде и Самокате.
Урок 6 — много платформ на старте, чтобы не упустить аудиторию. В 2013-м DC выпустил Windows Phone-версию. С 2026 года смысла в WP нет, но логика та же: если есть AppGallery / RuStore / HMS — закладывайте сборки под них с дня 1.
Урок 7 — экосистема важнее технологии. Это уже про судьбу DC. Технически продукт был отличный, но в одиночку, без поиска, карт, банка и подписки — он не выдержал конкуренцию с Яндексом. Если делаете агрегатор сегодня — сразу думайте, какая экосистема будет вокруг.
8. Архитектура агрегатора 2026 — обязательный минимум
Если вы делаете аналог DC в 2026 году, минимальный архитектурный набор смотрится примерно так.
Этот стек — рабочая база для агрегатора любого масштаба, от регионального MVP до федеральной платформы. Конкретная конфигурация — определяется на этапе проектирования.
9. Стоимость и сроки разработки сегодня
Ориентировочные цифры для агрегаторов в 2026 году:
Все цифры — «от», без верхней границы (стоимость зависит от числа моделей логистики, интеграций, объёма SKU, требований к лояльности и аналитике).
Подробный разбор формирования бюджета — в гайде «сколько стоит приложение доставки еды». Сроки по форматам — в разборе сроков разработки foodtech-приложения. Если бюджет ограничен и нужно проверить узкую гипотезу за 2-3 месяца — стартуйте с MVP foodtech-приложения.
Что важно понимать про экономику агрегатора:
- На старте юнит-экономика отрицательная — нужно набрать критическую массу клиентов и партнёров, чтобы заказы перекрыли costs логистики и маркетинга.
- Маркетинг — отдельный крупный бюджет: первые годы Delivery Club тратил десятки миллионов рублей в год на привлечение.
- Без экосистемного эффекта (поиск, карты, банк) — будет тяжело конкурировать с лидерами на федеральном рынке.
Не уверены, какой формат foodtech-агрегатора стартовать?
Пришлём план в 3 фазы и вилку стоимости за 1 день — без обязательств
10. Кейсы Surf в смежных задачах
— наш главный публичный кейс по теме статьи. Мы разрабатывали мобильные приложения DC с 2012-2013 годов: первый Android-прототип за 3 дня, итерации каждые 2-4 недели, чистая архитектура для аудита кода при смене собственников, мультиплатформенность (iOS / Android / Windows Phone / планшеты), интеграция Apple Pay одной из первых в стране. К пику развития DC — 10 000 ресторанов на платформе, 3 млн заказов в месяц, по публичным данным кейса — место в верхних строчках рейтингов Android-приложений в категории.
— приложение для 7+ млн пользователей, 85% продаж в digital, AR-меню, программа лояльности. Опыт построения мобильного приложения федерального масштаба для ресторанной сети.
— мультирегиональная архитектура для 1 100+ ресторанов в РФ и СНГ. Опыт работы с распределёнными сетями.
— №1 в App Store / Google Play в категории, 500+ пиццерий, программа лояльности. Опыт QSR и конструкторов блюд.
— подписка на готовые рационы, личный кабинет, доставка. Опыт subscription-foodtech.
— приложение быстрой доставки продуктов с интеграциями к крупным торговым сетям. Запуск занял 90 дней — это редкий публичный пример того, что foodtech-приложение можно собрать в очень сжатые сроки при готовом ТЗ.
Больше — на странице foodtech-практики Surf.
Готовы обсудить foodtech-агрегатор?
мы разрабатывали Delivery Club с 2012 года и собирал мобильные приложения BK, KFC, Додо, Performance Food. Поможем и вам
FAQ
1. Существует ли Delivery Club сейчас?
Самостоятельный бренд — нет. 5 июня 2026 года сервис был переименован в «Маркет Деливери», а 16 ноября 2023-го — в «Деливери». Сейчас платформа функционирует как часть Яндекс-экосистемы.
2. Когда Surf начал работать с Delivery Club?
В 2012-2013 годах — на этапе старта мобильной эры компании. Android-прототип был собран за 3 дня, дальше шла итеративная разработка с обновлениями каждые 2-4 недели вплоть до передачи проекта внутренней команде. Подробности — в публичном кейсе DC.
3. Сколько стоит сделать аналог Delivery Club сегодня?
Региональный MVP (один город, базовая функциональность) — от 15 млн ₽, срок 4-5 месяцев. Полнофункциональная региональная платформа — от 25 млн ₽. Мультирегиональная (5-15 городов) — от 40 млн ₽. Федеральная — от 60 млн ₽. Детально — в гайде по стоимости приложения доставки еды.
4. Можно ли запустить агрегатор быстро — за 2-3 месяца?
За такой срок можно собрать узкий MVP-эксперимент на 1 город с базовой функциональностью. Полноценный агрегатор с собственной курьерской службой и серьёзной лояльностью за 2-3 месяца не делается — закладывайте 5-7 месяцев минимум. Подробнее — в MVP foodtech-приложения за 2-3 месяца и сроках разработки foodtech.
5. Есть ли смысл делать новый агрегатор, если Яндекс.Еда — лидер?
Прямой клон Яндекс.Еды — не имеет смысла, экосистему конкурента не догнать. Смысл есть в узких нишах: региональный игрок там, где Яндекс работает поверхностно; узкая вертикаль (например, веганские рестораны, национальная кухня, food rescue); B2B-агрегатор для корпоративного питания.
6. Какой стек технологий выбрать для агрегатора в 2026?
Базовая рекомендация: Flutter для мобильных клиентов (одна команда), Python (Django / FastAPI) или Kotlin + Spring Boot на бэке, PostgreSQL + ClickHouse, Redis, Yandex Maps API, российские облака (Yandex Cloud, VK Cloud, Selectel). Полная таблица — в главе 8 этой статьи.
7. Что делать с платежами после ухода Apple Pay из РФ?
Главный канал в РФ 2026 — СБП через банковский эквайринг (Сбер, Альфа, Тинькофф, ЮKassa). На Android — Mir Pay и SberPay. На iOS — банковские карты через эквайер и СБП через QR-код в чек-ауте. Apple Pay в стране не работает с 2022 года, но архитектуру лучше закладывать так, чтобы при изменении ситуации канал можно было подключить обратно.
8. Как закладывать архитектуру с прицелом на масштабирование на 5-50 городов?
Главное — отделить регионо-зависимую логику (зоны доставки, цены, локализация) от регионо-независимой (профиль пользователя, корзина, оплата, биллинг). Тогда добавление нового города — это «довести данные» (POI, зоны, рестораны), а не «переписать систему».
9. Чему стоит научиться у самого Delivery Club, кроме архитектуры?
Скорости релизов (2-4 недели), мультиплатформенности с дня 1, глубокой интеграции с банками, чистой архитектуре с возможностью аудита, реферальной программе как масштабируемому каналу роста. Подробнее — в главе 7 этой статьи.
10. Где посмотреть кейсы Surf в foodtech?
На странице foodtech-практики Surf и в отдельных кейсах: Delivery Club, Burger King, KFC, Додо Пицца, Performance Food, Golama.
Заключение
История Delivery Club — это история первого российского foodtech-агрегатора, который десять лет задавал стандарты рынка. Бренд переименован в 2026 году, но архитектурные и продуктовые решения, которые задал DC — мультиплатформенность, итерации каждые 2-4 недели, глубокая интеграция с банками, чистая архитектура для аудита кода, реферальные программы с deep linking — остаются стандартом для любого нового foodtech-проекта.
Главный вывод для 2026 года: технология одна не выигрывает. Выигрывает связка «отличный продукт + сильная экосистема + стратегическая стабильность». Если делаете новый агрегатор — сразу думайте, в какую экосистему он встроится. Если делаете узкую вертикаль — найдите нишу, где конкурент-Яндекс работает поверхностно.
Мы делаем foodtech-приложения 14+ лет — от Delivery Club до Burger King, KFC, Додо Пиццы, Performance Food и Golama. Если у вас есть гипотеза foodtech-агрегатора — обсудим её, соберём план запуска от MVP до полной платформы и пришлём вилку стоимости.
Готовы обсудить foodtech-проект?
мы разработаем приложение под ваш бизнес с прозрачным бюджетом и сроками. Команда, которая делала Delivery Club с 2012 года, ждёт вашей задачи
