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

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

Когда я начинал делать Vecin2Vecin — сервис доставки продуктов «от соседа к соседу» — у меня была понятная, как мне казалось, инженерная задача. Пользователь выбирает супермаркет, собирает корзину, сосед-курьер идёт в магазин, покупает и приносит к двери. Для этого нужен живой каталог: названия товаров, цены, наличие. А каталог, рассуждал я, можно взять у самих сетей — у них же есть приложения, значит, есть и данные, значит, должен быть API.

Это оказалось самым наивным предположением за весь проект.

Ожидание: «мы приводим вам заказы — дайте API»

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

Я составил список сетей по странам, где запускался: в России — Пятёрочка, Перекрёсток, Магнит, Лента, ВкусВилл и другие; в Молдове — Kaufland, Linella, Nr.1, Green Hills. Написал письма в отделы партнёрства, B2B, digital. Описал продукт, модель, пользу. Приложил ссылку на работающее приложение.

И стал ждать.

Реальность: тишина

Ответа не было. Не «нет» — а именно тишина. Где-то автоответ «спасибо за обращение». Где-то «передали коллегам». Один раз — «это не наша зона ответственности», без указания, чья.

Сначала я думал, что плохо написал письмо. Переписал. Тишина. Решил, что пишу не туда. Нашёл людей в LinkedIn, отправил через формы «стать партнёром» на сайтах. Тишина.

В какой-то момент до меня дошло важное: отсутствие ответа — это и есть ответ. И причина не в том, что мой продукт плохой.

Почему сети молчат (и это не про вас)

Когда я перестал принимать это на свой счёт и посмотрел трезво, картина сложилась.

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

Нет процесса для маленьких партнёров. Отделы партнёрства больших сетей заточены под агрегаторов уровня Яндекса и Самоката — с юристами, объёмами и гарантиями. Письмо от стартапа с MVP просто не попадает ни в чью KPI. Оно зависает между IT, маркетингом и закупками, и им не занимается никто.

Данные — это актив. Полный ассортимент и цены — коммерческая тайна. Открытый API ассортимента — это, по сути, подарок конкурентам и аналитикам рынка. Сети защищают эти данные намеренно.

Юридические риски. Если в моём каталоге цена окажется неверной или товар будет в наличии «на бумаге», но не на полке — кто отвечает перед покупателем? Для сети это репутационный риск без понятной выгоды.

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

Что я сделал вместо API

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

Но именно здесь проект свернул в сторону, которая в итоге оказалась правильной.

Может, API и не нужен был

Моя модель — не Instacart. Курьер у меня не сотрудник сети, а человек из того же района. Заказ — это часто не точный SKU с полки, а «молоко, хлеб, что-нибудь к чаю». И тут я понял: для соседской модели точный каталог сети — не обязательное условие запуска.

Что действительно нужно:

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

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

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

Какие подходы вообще есть

Если вы делаете что-то похожее, вот честная карта вариантов — со всеми минусами.

• Подход — Плюс — Минус
• Официальный API / партнёрство — Легально, актуальные цены — Сети не отвечают месяцами
• Парсинг сайта или приложения — Быстро, без согласований — Нарушение правил, блокировки, постоянные поломки
• «Сосед покупает по списку» — Запуск без участия сети — Возможны расхождения по цене
• Ручной / демо-каталог — Полный контроль — Не масштабируется, цены неактуальны

Серебряной пули нет. На старте выигрывает не тот, у кого больше SKU в базе, а тот, у кого заказ доезжает и чек сходится.

Что я бы сказал себе в начале

Закладывайте на работу с ритейлом не недели, а месяцы. Подключение API — это не инженерная задача на спринт. Это продажи, юристы и внутренняя политика сети. Часто — безуспешные.

Начинайте с пилота, а не с интеграции. Один район, ограниченный список товаров, ручной каталог или даже список в мессенджере. Проверяйте, закрываются ли заказы, а не насколько красив каталог.

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

Не принимайте молчание на свой счёт. Сеть, которая вам не ответила, не оценивала ваш продукт. Она просто не имеет процесса, чтобы вас услышать. Это говорит о её устройстве, а не о вашей идее.

Итог

Я хотел получить API ассортимента. Вместо этого получил рабочую модель: сосед, корзина, чек из магазина и честное возмещение. Супермаркеты так и не перезвонили — и, как ни странно, проект от этого не умер, а нашёл свою настоящую форму.

Иногда стена, в которую ты упёрся, — это не препятствие на пути, а знак, что путь был выбран не тот.