Pyaterochka nunca devolvió la llamada: cómo construí un servicio de entrega de supermercado sin una sola API

Pyaterochka nunca devolvió la llamada: cómo construí un servicio de entrega de supermercado sin una sola API

Cuando empecé a construir Vecin2Vecin —un servicio de entrega de la compra entre vecinos—, creí que tenía un problema de ingeniería claro. El usuario elige un supermercado, llena un carrito, un vecino repartidor va a la tienda, lo compra todo y lo lleva hasta la puerta. Para eso hace falta un catálogo en vivo: nombres de productos, precios, disponibilidad. Y un catálogo, razoné, debería venir de las propias cadenas: tienen aplicaciones, así que tienen datos, así que tiene que haber una API.

Esa resultó ser la suposición más ingenua de todo el proyecto.

La expectativa: «te traemos pedidos, dame una API»

La lógica parecía impecable. No compito con la tienda. Al contrario: le traigo ventas extra. Un vecino compra sus productos, a sus precios, en su caja. De la cadena necesito esencialmente una cosa: un surtido actualizado con precios, para que el comprador vea el carrito antes de hacer el pedido.

Hice una lista de las cadenas de cada país donde íbamos a lanzar: en Rusia —Pyaterochka, Perekrestok, Magnit, Lenta, VkusVill y otras—; en Moldavia —Kaufland, Linella, Nr.1, Green Hills—. Escribí a los departamentos de alianzas, B2B y digital. Describí el producto, el modelo, el valor. Adjunté un enlace a la aplicación en funcionamiento.

Y esperé.

La realidad: silencio

No hubo respuesta. No un «no», sino silencio. A veces una respuesta automática: «gracias por escribirnos». A veces, «lo hemos pasado a nuestros colegas». Una vez: «eso no es competencia nuestra», sin decir de quién era.

Al principio pensé que había escrito un mal correo. Lo reescribí. Silencio. Decidí que estaba escribiendo a las personas equivocadas. Busqué gente en LinkedIn, envié formularios de «conviértete en socio» en los sitios web. Silencio.

En algún momento lo entendí: la no respuesta es la respuesta. Y el motivo no es que mi producto sea malo.

Por qué las cadenas guardan silencio (y no es por ti)

Cuando dejé de tomármelo como algo personal y lo miré con frialdad, el cuadro encajó.

Ya tienen su propia aplicación. Para una cadena grande, un servicio de entrega de terceros no son «ventas extra»: es un competidor de su propio canal. Han invertido en su propia entrega y no tienen prisa por ceder clientes a otro.

No existe un proceso para socios pequeños. Los equipos de alianzas de las grandes cadenas están pensados para agregadores del tamaño de Yandex y Samokat: con abogados, volúmenes y garantías. Una carta de una startup con un MVP simplemente no entra en los KPI de nadie. Queda colgada entre IT, marketing y compras, y nadie se hace responsable de ella.

Los datos son un activo. El surtido completo y los precios son secretos comerciales. Una API de surtido abierta es, en esencia, un regalo para los competidores y los analistas de mercado. Las cadenas protegen esos datos a propósito.

Riesgo legal. Si mi catálogo muestra un precio equivocado o un producto que «hay en stock sobre el papel» pero no está en la estantería, ¿quién responde ante el comprador? Para la cadena es un riesgo reputacional sin un beneficio claro.

Ninguno de estos motivos tiene que ver con la calidad de mi producto. Son barreras sistémicas, y era importante entenderlas antes de pasar otros seis meses enviando correos.

Qué hice en lugar de una API

Seré honesto: todavía no tengo una API de surtido en vivo. El catálogo de la aplicación se rellena con scripts de seed —conjuntos de productos típicos con precios de ejemplo para cada cadena—. La landing page dice que «los precios y la disponibilidad se ven al instante». Técnicamente es cierto para la demo. Operativa y legalmente, todavía no, y no voy a fingir lo contrario.

Pero fue justo ahí donde el proyecto giró en una dirección que resultó ser la correcta.

Quizá nunca hizo falta una API

Mi modelo no es Instacart. El repartidor no es un empleado de la tienda: es alguien del mismo barrio. Un pedido a menudo no es un SKU exacto de la estantería, sino «leche, pan, algo para el té». Y entonces me di cuenta: para un modelo basado en vecinos, un catálogo preciso de la cadena no es un requisito para lanzar.

Lo que realmente necesitas:

• una lista fiable de tiendas y un conjunto claro de productos;
• un flujo de «el vecino compra de una lista» con recibo;
• una contabilidad honesta: pago por adelantado, reembolso al repartidor de lo que realmente compró más una recompensa.

Todo eso ya está en mi lógica de pagos. El comprador paga por adelantado, el repartidor compra los productos y el servicio le reembolsa el total de la compra y la comisión. La diferencia entre el precio esperado y el real se resuelve a nivel de recibo, no a nivel de una API perfecta.

En otras palabras: perseguía una integración que necesitan los grandes agregadores, mientras que mi modelo solo necesita confianza, un recibo y un reembolso.

Enfoques que existen

Si estás construyendo algo parecido, aquí tienes un mapa honesto de las opciones, con todas sus desventajas.

• Enfoque — ventaja — desventaja
• API oficial / alianza — legalidad, precios actualizados — las cadenas no responden hasta meses después
• Scraping del sitio o de la aplicación — rapidez, sin aprobaciones — incumplimiento de los términos de uso, bloqueos, roturas constantes
• «El vecino compra de una lista» — lanzar sin la cadena — posibles desajustes de precio
• Catálogo manual / de demostración — control total — no escala, los precios se quedan obsoletos

No hay bala de plata. Al principio, no gana quien tiene más SKUs en la base de datos, sino quien entrega pedidos y cuadra los recibos.

Lo que me diría a mí mismo al principio

Presupuesta meses, no semanas, para el retail. El acceso a una API no es un sprint de ingeniería. Es ventas, abogados y política interna de las cadenas. A menudo, sin éxito.

Empieza con un piloto, no con una integración. Un barrio, una lista limitada de productos, un catálogo manual o incluso una lista en una app de mensajería. Prueba si los pedidos se cierran, no lo bonito que queda el catálogo.

Mide la métrica adecuada. No «cuántos productos hay en la base de datos», sino «cuántos pedidos se entregan con una diferencia de recibo aceptable y un comprador satisfecho».

No te tomes el silencio como algo personal. Una cadena que no respondió no estaba evaluando tu producto. Sencillamente no tiene ningún proceso para escucharte. Eso dice algo de cómo están construidas, no de tu idea.

Conclusión

Quería una API de surtido. En su lugar obtuve un modelo que funciona: un vecino, un carrito, un recibo de la tienda y un reembolso honesto. Los supermercados nunca devolvieron la llamada y, por extraño que parezca, el proyecto no murió por eso: encontró su forma real.

A veces el muro con el que chocas no es un obstáculo en el camino: es una señal de que ibas por el camino equivocado.