Pyaterochka Never Called Back: How I Built Supermarket Delivery Without a Single API

Pyaterochka Never Called Back: How I Built Supermarket Delivery Without a Single API

When I started building Vecin2Vecin — a neighbor-to-neighbor grocery delivery service — I thought I had a clear engineering problem. The user picks a supermarket, fills a cart, a neighbor-courier goes to the store, buys everything, and brings it to the door. For that you need a live catalog: product names, prices, availability. And a catalog, I reasoned, should come from the chains themselves — they have apps, so they have data, so there must be an API.

That turned out to be the most naive assumption of the entire project.

The expectation: "we bring you orders — give us an API"

The logic seemed airtight. I'm not competing with the store. On the contrary — I bring them extra sales. A neighbor buys their products, at their prices, at their checkout. From the chain I need essentially one thing: an up-to-date assortment with prices, so the buyer sees the cart before placing an order.

I made a list of chains in each country where we were launching: in Russia — Pyaterochka, Perekrestok, Magnit, Lenta, VkusVill, and others; in Moldova — Kaufland, Linella, Nr.1, Green Hills. I wrote to partnership, B2B, and digital departments. Described the product, the model, the value. Attached a link to the working app.

And waited.

Reality: silence

There was no answer. Not "no" — silence. Sometimes an auto-reply: "thank you for reaching out." Sometimes "we forwarded it to colleagues." Once — "that's not our area of responsibility," without saying whose it was.

At first I thought I wrote a bad email. Rewrote it. Silence. Decided I was writing to the wrong people. Found people on LinkedIn, submitted "become a partner" forms on websites. Silence.

At some point it clicked: no response is the response. And the reason isn't that my product is bad.

Why chains stay silent (and it's not about you)

When I stopped taking it personally and looked at it soberly, the picture came together.

They already have their own app. For a large chain, a third-party delivery service isn't "extra sales" — it's a competitor to their own channel. They invested in their own delivery and aren't eager to hand customers to someone else.

There's no process for small partners. Partnership teams at big chains are built for aggregators the size of Yandex and Samokat — with lawyers, volumes, and guarantees. A letter from a startup with an MVP simply doesn't hit anyone's KPI. It hangs between IT, marketing, and procurement, and nobody owns it.

Data is an asset. Full assortment and prices are trade secrets. An open assortment API is essentially a gift to competitors and market analysts. Chains protect that data on purpose.

Legal risk. If my catalog shows the wrong price or a product that's "in stock on paper" but not on the shelf — who answers to the buyer? For the chain that's reputational risk with no clear upside.

None of these reasons has anything to do with the quality of my product. These are systemic barriers, and it was important to understand them before spending another six months on emails.

What I did instead of an API

I'll be honest: I still don't have a live assortment API. The in-app catalog is filled by seed scripts — sets of typical products with placeholder prices for each chain. The landing page says "prices and availability visible right away." Technically that's true for the demo. Operationally and legally — not yet, and I'm not pretending otherwise.

But that's exactly where the project turned in a direction that turned out to be right.

Maybe an API was never needed

My model isn't Instacart. The courier isn't a store employee — they're someone from the same neighborhood. An order is often not an exact SKU from the shelf but "milk, bread, something for tea." And then I realized: for a neighbor-based model, a precise chain catalog isn't a launch requirement.

What you actually need:

• a trusted list of stores and a clear set of products;
• a "neighbor buys from a list" flow with a receipt;
• honest accounting: prepayment, reimbursement to the courier for what was actually bought plus a reward.

All of that is already in my payment logic. The buyer pays upfront, the courier buys the goods, the service reimburses the product total and commission. The gap between expected and actual price is resolved at the receipt level, not at the level of a perfect API.

In other words: I was chasing an integration that big aggregators need, while my model only needs trust, a receipt, and reimbursement.

Approaches that exist

If you're building something similar, here's an honest map of options — with all the downsides.

• Approach — Upside — Downside
• Official API / partnership — Legal, up-to-date prices — Chains don't reply for months
• Scraping the site or app — Fast, no approvals — Terms violations, blocks, constant breakage
• "Neighbor buys from a list" — Launch without the chain — Price mismatches possible
• Manual / demo catalog — Full control — Doesn't scale, prices go stale

There's no silver bullet. At the start, the winner isn't whoever has more SKUs in the database — it's whoever delivers orders and reconciles receipts.

What I'd tell myself at the beginning

Budget months, not weeks, for retail. API access isn't an engineering sprint. It's sales, lawyers, and internal chain politics. Often — unsuccessful.

Start with a pilot, not an integration. One neighborhood, a limited product list, a manual catalog or even a list in a messenger. Test whether orders close, not how pretty the catalog is.

Measure the right metric. Not "how many products in the database" but "how many orders delivered with an acceptable receipt gap and a happy buyer."

Don't take silence personally. A chain that didn't reply wasn't evaluating your product. It simply has no process to hear you. That says something about how they're built, not about your idea.

Bottom line

I wanted an assortment API. Instead I got a working model: a neighbor, a cart, a store receipt, and honest reimbursement. The supermarkets never called back — and, strangely, the project didn't die because of that; it found its real shape.

Sometimes the wall you hit isn't an obstacle on the path — it's a sign you were on the wrong path.