Sistema de delivery simplificado para el mercado paraguayo
Análisis técnico y comparativo de alternativas, oportunidades y requerimientos de implementación
- Objeto
- Evaluar la viabilidad de un sistema de pedidos y entrega de bajo costo frente a las plataformas dominantes (PedidosYa, Monchis).
- Ámbito
- Asunción, Gran Asunción y ciudades del interior.
- Estado
- Borrador para revisión. Cifras económicas marcadas como hipótesis.
- Método
- Fuentes públicas (prensa, sitios de las plataformas, asociaciones gremiales), relevadas en octubre de 2026.
1Resumen
El mercado de delivery en Paraguay está concentrado en dos plataformas que operan con comisión sobre ventas. Las asociaciones gremiales documentan una retirada de restaurantes por costos que no cierran, y la adquisición de PedidosYa por Uber agrega incertidumbre. En paralelo, el pago QR alcanzó adopción masiva y WhatsApp es el canal habitual de pedido directo.
Se evaluaron tres alternativas de producto. La que mejor combina simplicidad de implementación, bajo capital y alineación con el problema del mercado es un sistema de pedidos propio para restaurantes con tarifa fija y sin comisión. Las otras dos (marketplace local, despacho de repartidores) exigen operación logística o llegan tarde a un nicho ya ocupado.
2Situación del mercado
| Indicador | Valor | Fuente / año |
|---|---|---|
| Comisión de PedidosYa a restaurantes | ≈ 30 % | Jefe; ABC Color, 2026 |
| Costo efectivo con descuentos y promociones (región) | 24 – 33 % | Jefe, 2026 |
| Usuarios activos de Monchis | > 70.000 | InfoNegocios |
| Comercios adheridos a Monchis | > 700 | Club de Ejecutivos |
| Ciudades con cobertura PedidosYa | ≈ 20 | Diario HOY |
| Ciudades con cobertura Monchis | 4 | Club de Ejecutivos |
| Operaciones QR mensuales (Bancard) | > 13.000.000 | InfoNegocios, mar. 2025 |
| Comercios activos con QR Bancard | > 120.000 | InfoNegocios, 2025 |
| Participación del QR en pagos electrónicos | 55 % | Última Hora, 2026 |
| Restaurantes de la región que migraron ≥ 30 % del volumen a WhatsApp | ≈ 34 % | Watsi, 2025 |
2.1Hechos relevantes
- Uber adquirió PedidosYa en 2026. Asogapa, ARPY y Asomipymes expresaron expectativa de mejora de servicio y, a la vez, preocupación por concentración y abuso de posición dominante.
- ARPY declara que parte de sus asociados dejó de operar con PedidosYa por comisiones consideradas abusivas y descuentos impuestos.
- Monchis publicita "la comisión más conveniente del mercado" sin cifra pública; opera con logística propia.
- delivery.com.py prepara el lanzamiento de un servicio de cotización de repartidores por WhatsApp, sin comisión y sin aplicación.
3Comparativa de plataformas existentes
| Característica | PedidosYa (Uber) | Monchis | Herramientas WhatsApp regionales | delivery.com.py |
|---|---|---|---|---|
| Tipo | Marketplace | Marketplace | SaaS de pedido propio | Intermediación logística |
| Genera demanda al comercio | Sí | Sí (menor escala) | No | No |
| Logística | Flota propia | Flota propia | Del comercio | Repartidores independientes |
| Costo para el comercio | Comisión ≈ 30 % + promociones | Comisión (no publicada) | Mensualidad o ≈ 2 % por venta | Sin costo declarado |
| Precio al consumidor | Recargo de servicio y envío; precios de carta frecuentemente inflados | Costo de envío | Precio de carta + envío del comercio | Tarifa del repartidor |
| Medios de pago | Tarjeta, efectivo | Tarjeta, efectivo | Varía; sin QR local | Acordado con repartidor |
| Datos del cliente | Retenidos por la plataforma | Retenidos por la plataforma | Del comercio | No aplica |
| Adaptación a Paraguay | Completa | Completa | Ninguna (moneda, pagos, idioma regional) | Completa |
| Cobertura | ≈ 20 ciudades | 4 ciudades | Sin límite geográfico | Gran Asunción e interior |
| Estado | Operativa, en transición | Operativa | Operativas fuera del país | Pre-lanzamiento |
4Oportunidades identificadas
| Oportunidad | Evidencia | Forma de captura | Prioridad |
|---|---|---|---|
| Restaurantes que abandonan plataformas por comisión | Declaraciones de ARPY (2026); costo efectivo 24–33 % del ticket. | Herramienta de pedido propio con tarifa plana. Argumento: ahorro directo y cuantificable. | Alta |
| Pago QR sin pasarela de tarjetas | 13 M operaciones/mes; 120.000 comercios; Tigo Money integrado a red Bancard. | Cobro por QR Bancard o Tigo Money desde el flujo de pedido, sin costo de pasarela ni certificación PCI. | Alta |
| WhatsApp como canal ya instalado | Un tercio de restaurantes de la región opera ≥ 30 % por WhatsApp; el canal no requiere capacitación del cliente. | Pedido estructurado que llega al WhatsApp del comercio, sin app para el consumidor. | Alta |
| Incertidumbre por la compra de PedidosYa | Asociaciones gremiales anticipan posibles cambios de condiciones. | Ventana temporal para presentarse como alternativa de bajo riesgo mientras se redefinen las condiciones. | Media |
| Ciudades intermedias sin cobertura | Monchis en 4 ciudades; PedidosYa en ≈ 20 sobre más de 250 distritos. | Herramienta independiente de la geografía; directorio por ciudad cuando exista masa crítica. | Media |
| Ausencia de herramientas localizadas | Las soluciones SaaS existentes no manejan guaraníes, QR local ni efectivo con vuelto. | Localización completa como diferencial frente a herramientas regionales. | Media |
| Propiedad de los datos del cliente | Las plataformas retienen historial y contacto; el comercio no puede fidelizar. | Base de clientes propia del comercio, con historial de pedidos y re-pedido. | Baja |
5Segmentos y modelos de entrega
El producto cambia según quién pide, quién recibe y cuánto se transporta. No es lo mismo llevar una hamburguesa a una casa que repartir veinte bultos de descartables a despensas de tres ciudades. Esta sección ordena los modelos posibles para que el grupo elija con criterio.
| Modelo | Quién pide | Dónde se entrega | Carga típica | Vehículo | Frecuencia | Pago | Ejemplo |
|---|---|---|---|---|---|---|---|
| A. Comida al cliente final | Persona | Casa u oficina | Una bolsa | Moto | A demanda, 30 a 60 min | Efectivo, QR | Hamburguesería, pizzería |
| B. Comercio de barrio al cliente final | Persona | Casa | Una o varias bolsas | Moto, bicicleta | A demanda, 20 a 60 min | Efectivo, QR | Despensa, farmacia, minimarket |
| C. Distribuidora a comercios (reparto B2B) | Comercio cliente o preventista | Local comercial, varios por viaje | Bultos, cajas, fardos | Camioneta, camión chico | Programada, ruta por día o semana | Cuenta corriente, contra entrega | Distribuidora de plásticos, bebidas, limpieza |
| D. Flete y cargas | Empresa o persona | Depósito, obra, otra ciudad | Carga grande o pesada | Camioneta, camión | Eventual, por viaje | Cotización por viaje | Mudanza, materiales, mercadería entre ciudades |
5.1Qué cambia en el sistema según el modelo
| Componente | A y B · Cliente final | C · Reparto B2B | D · Fletes |
|---|---|---|---|
| Catálogo | Por unidad, con foto y precio único | Por bulto (caja, fardo, pack); precio según cliente; pedido mínimo | No hay catálogo; se describe la carga |
| Pedido | A demanda, se prepara al momento | Programado; se acumula y se entrega el día de ruta | Solicitud con origen, destino, carga y fecha |
| Entrega | Una parada por viaje | Ruta con varias paradas, ordenadas por zona | Un viaje, a veces de larga distancia |
| Quién entrega | Repartidor del comercio | Chofer de la distribuidora | Transportista independiente |
| Comprobante | Ninguno o foto | Remito firmado o foto de la entrega; devoluciones | Remito, estado de la carga |
| Pago | Efectivo con vuelto, QR, transferencia | Cuenta corriente, cobranza en la parada, QR | Cotización aceptada; seña y saldo |
| Seguimiento | Estado del pedido | Posición en la ruta y ventana horaria | Estado del viaje |
| Pantalla principal | Tienda pública en el celular del cliente | Hoja de ruta en el celular del chofer y panel de carga | Solicitud y cotizaciones |
5.2Reparto B2B de distribuidoras
Una distribuidora, por ejemplo de plásticos y descartables, atiende despensas, ferreterías y tiendas en varias ciudades. Hoy el circuito suele ser: el preventista toma el pedido en papel o por WhatsApp, el depósito arma la carga, el chofer sale con una hoja de ruta impresa y cobra en la parada. Los problemas habituales son pedidos mal tomados, rutas improvisadas, falta de confirmación de entrega y cobranza desordenada.
En este modelo el sistema no necesita una tienda pública para el consumidor. Necesita, en este orden: catálogo por bulto con precio por cliente, toma de pedidos por el propio comercio o el preventista, armado de la ruta del día por vehículo, hoja de ruta en el celular del chofer con paradas, estado y comprobante (foto o firma), y aviso al comercio con la ventana horaria de llegada. La cuenta corriente y la cobranza por parada son el módulo de pago.
Referencias regionales: Chiper (Colombia, México, Brasil y Chile) digitaliza la compra mayorista de tiendas de barrio con entrega en menos de 24 horas y optimización de rutas; Rupaq (Perú) vende gestión de rutas y seguimiento de pedidos a distribuidoras. En Paraguay, Plub (supermercado digital) contrató a Shipsy para su última milla. No se identificó una herramienta local accesible para distribuidoras pequeñas y medianas, que siguen operando con planilla y WhatsApp.
5.3Fletes y cargas
Aquí no hay catálogo ni pedidos recurrentes. Una persona o empresa describe la carga, el origen y el destino; transportistas con camioneta o camión cotizan; el solicitante elige y sigue el viaje. Es un mercado de transportistas, no un sistema de pedidos: requiere oferta de vehículos, confianza entre desconocidos y, en cargas de valor, seguro. Picap llegó a Paraguay con logística en moto, y delivery.com.py apunta a envíos chicos por WhatsApp; el segmento de cargas grandes entre ciudades sigue resolviéndose por contactos personales.
5.4Implicancia para el proyecto
El núcleo del sistema (catálogo, pedido, panel y estados) sirve para los modelos A, B y C. El modelo C agrega ruta, hoja de ruta móvil y comprobante de entrega. El modelo D es otro producto: sin catálogo, con cotización y transportistas externos. Puede sumarse después como módulo de envíos grandes, pero no conviene arrancar por ahí.
| Modelo | Esfuerzo extra | Qué hay que construir además del núcleo | Quién debe existir para que funcione |
|---|---|---|---|
| A. Comida | Ninguno | — | Restaurantes con repartidor propio |
| B. Comercio de barrio | Bajo | Catálogo más grande, control de stock simple | Despensas o farmacias con repartidor |
| C. Reparto B2B | Medio | Armado de ruta, hoja de ruta móvil, comprobante, cuenta corriente | Una distribuidora con vehículo y clientes |
| D. Fletes | Alto | Solicitud de viaje, cotizaciones, red de transportistas, seguro | Transportistas dispuestos a cotizar |
Si el grupo elige el modelo C, el MVP cambia de orden: la hoja de ruta del chofer y el panel de carga van antes que la tienda pública. Si elige A o B, se mantiene el alcance de la sección 8.
6Alternativas de producto
6.1Alternativa A — Sistema de pedidos propio para restaurantes
Cada comercio recibe un menú digital con enlace propio, carrito, confirmación por WhatsApp, panel de pedidos con estados y enlace de seguimiento. La entrega la realiza el comercio. Tarifa fija mensual.
Ventajas
- Resuelve el problema de costo documentado por el gremio.
- Sin flota, sin soporte a repartidores, sin subsidios.
- Alcance técnico reducido; desarrollo corto.
- Ingreso recurrente y previsible por comercio.
- Localización como barrera frente a herramientas regionales.
- Permite evolucionar a directorio por ciudad sin comisión.
Desventajas
- No genera demanda; depende de la clientela del comercio.
- Ticket mensual bajo; requiere volumen de comercios.
- Captación comercial presencial, uno a uno.
- Abandono si el comercio no logra volumen propio.
- Herramientas regionales podrían localizarse.
6.2Alternativa B — Marketplace local en ciudad del interior
Aplicación con catálogo de comercios de una ciudad intermedia y red de repartidores coordinada por la plataforma.
Ventajas
- Competencia directa escasa o nula en la ciudad elegida.
- Genera demanda; facilita la adhesión de comercios.
- Mayor ingreso por pedido (comisión y envío).
- Conocimiento local como barrera.
Desventajas
- Negocio de dos lados más repartidores: tres frentes de captación.
- Capital para subsidios iniciales.
- Operación diaria intensiva: incidencias, pagos, calidad.
- Reproduce el modelo de comisión que el gremio rechaza.
- Expuesto a entrada de PedidosYa o Monchis.
6.3Alternativa C — Despacho de repartidores independientes
Intermediación entre solicitante y repartidores independientes, con cotización y coordinación por WhatsApp.
Ventajas
- Complementa a comercios que venden por canal propio.
- Inversión tecnológica mínima.
- Demanda transversal: comida, paquetes, documentos.
Desventajas
- delivery.com.py ya ocupa el nicho en pre-lanzamiento.
- Sin diferencial; entrada tardía.
- Monetización difícil si pago y coordinación quedan fuera.
- Calidad dependiente de terceros sin control.
6.4Matriz de evaluación
| Criterio | Peso | A | B | C |
|---|---|---|---|---|
| Simplicidad de implementación | 0,20 | 5 | 2 | 4 |
| Capital inicial | 0,15 | 5 | 1 | 5 |
| Carga operativa | 0,15 | 4 | 1 | 3 |
| Alineación con el problema del mercado | 0,20 | 5 | 3 | 3 |
| Diferenciación | 0,10 | 3 | 3 | 1 |
| Previsibilidad de ingresos | 0,10 | 4 | 2 | 1 |
| Potencial de escala | 0,10 | 3 | 5 | 3 |
| Puntaje ponderado | 1,00 | 4,40 | 2,30 | 3,20 |
7Comparativa técnica de componentes
Se comparan las opciones de implementación para los tres componentes que determinan la complejidad del sistema: canal de pedido, medio de pago y notificación al comercio.
| Opción | Mecanismo | Costo | Complejidad | Limitaciones | Recomendación |
|---|---|---|---|---|---|
| Enlace wa.me con texto prearmado | El cliente confirma desde el carrito; se abre WhatsApp con el pedido redactado. | Ninguno | Baja | Sin confirmación automática; el comercio responde a mano. | MVP |
| WhatsApp Business API (Cloud API) | Mensajes salientes desde el servidor con plantillas aprobadas. | Por conversación; verificación de empresa | Media | Aprobación de Meta; plantillas; número dedicado por comercio. | Fase 2 |
| Chatbot conversacional | El cliente pide por chat y un bot arma el pedido. | Proveedor externo o desarrollo propio | Alta | Ambigüedad en pedidos; mantenimiento del flujo. | No |
| Panel web con notificación push / sonido | El pedido se registra en base de datos y el panel del comercio alerta. | Ninguno | Baja | Requiere que el comercio tenga el panel abierto. | MVP (complemento) |
| Opción | Mecanismo | Costo para el comercio | Integración | Conciliación | Recomendación |
|---|---|---|---|---|---|
| Efectivo contra entrega | Campo "paga con" para calcular vuelto. | Ninguno | Ninguna | Manual | MVP |
| QR estático del comercio (Bancard / Tigo Money) | Se muestra el QR del comercio en la confirmación; el cliente paga desde su app bancaria o billetera. | Arancel de red (acordado con Bancard / Tigo) | Ninguna; solo imagen del QR | Manual; comercio verifica acreditación | MVP |
| Transferencia SIPAP | Alias o cuenta del comercio en la confirmación. | Ninguno o mínimo | Ninguna | Manual | MVP |
| QR dinámico por pedido | Se genera un QR con monto e identificador por cada pedido. | Arancel de red | API del adquirente; convenio comercial | Automática | Fase 2 |
| Checkout con tarjeta (vPOS u otro) | Pasarela web. | Comisión por transacción + costo fijo | API, certificación, contrato | Automática | Fase 3 |
| Opción | Mecanismo | Complejidad | Recomendación |
|---|---|---|---|
| Enlace de estado | Página pública por pedido con estado actualizado por el comercio. | Baja | MVP |
| Mensaje de WhatsApp por cambio de estado | Requiere Cloud API o envío manual. | Media | Fase 2 |
| Ubicación en tiempo real del repartidor | App o PWA para el repartidor con geolocalización. | Alta | No, en esta etapa |
8Arquitectura propuesta (Alternativa A)
8.1Componentes
| Módulo | Función | MVP | Fase 2 |
|---|---|---|---|
| Catálogo | Categorías, productos, variantes, precios en guaraníes, disponibilidad, horarios. | Sí | Combos, extras, fotos |
| Tienda pública | Página por comercio con menú y carrito, optimizada para móvil. Sin registro del cliente. | Sí | Historial por número de teléfono |
| Zonas de entrega | Lista de barrios con costo fijo; retiro en local. | Sí | Polígonos en mapa |
| Pedido | Registro en base de datos; generación de texto para WhatsApp; enlace de seguimiento. | Sí | Cloud API |
| Panel del comercio | Pedidos entrantes, cambio de estado, impresión de comanda, gestión de catálogo. | Sí | Reportes, múltiples sucursales |
| Pagos | Efectivo con vuelto; QR estático; datos de transferencia. | Sí | QR dinámico con conciliación |
| Administración | Alta de comercios, planes, estado de suscripción. | Mínimo | Facturación automática |
| Directorio por ciudad | Listado público de comercios adheridos. | No | Sí, con masa crítica |
8.2Pila tecnológica
| Capa | Opción 1 | Opción 2 | Criterio de elección |
|---|---|---|---|
| Backend | PHP 8 + Laravel | Node.js + Fastify | Entorno local existente (Laragon) y disponibilidad de hosting PHP económico en el país favorecen la opción 1. |
| Base de datos | MySQL / MariaDB | PostgreSQL | Indistinto para el volumen previsto; opción 1 por compatibilidad con hosting compartido. |
| Frontend tienda | Blade + Alpine.js | SPA (Vue / React) | Opción 1: menor peso, mejor en redes móviles lentas, sin build complejo. |
| Panel comercio | Blade + Livewire | SPA | Opción 1 por consistencia y velocidad de desarrollo. |
| Tiempo real (panel) | Polling cada 10–15 s | WebSockets | Opción 1 en MVP; suficiente para el volumen y evita infraestructura adicional. |
| Despliegue | Docker + VPS | Hosting compartido | Opción 1 para reproducibilidad; el entorno local ya usa Docker. |
| Multi-tenencia | Base única con columna de comercio | Base por comercio | Opción 1; simplicidad operativa. |
8.3Modelo de datos (núcleo)
comercios · sucursales · zonas_entrega · categorias · productos · variantes · pedidos · pedido_items · estados_pedido · clientes (teléfono, dirección) · suscripciones
8.4Flujo de pedido
- El cliente abre el enlace del comercio, arma el carrito y elige zona, medio de pago y datos de contacto.
- El sistema registra el pedido con estado recibido y genera un identificador corto.
- Se abre WhatsApp con el pedido redactado y el enlace de seguimiento; el cliente lo envía al comercio.
- El panel del comercio muestra el pedido; el operador lo acepta y avanza los estados en preparación → en camino → entregado.
- El cliente consulta el estado por el enlace de seguimiento.
9Modelo económico (hipótesis)
| Concepto | Plataforma (30 %) | Sistema propio |
|---|---|---|
| Comisión sobre ventas | 3.000.000 | 0 |
| Tarifa fija mensual | 0 | 150.000 – 300.000 |
| Repartidor propio (estimado) | 0 | 1.500.000 – 2.500.000 |
| Costo total estimado | 3.000.000 | 1.650.000 – 2.800.000 |
| Diferencia a favor del comercio | — | 200.000 – 1.350.000 |
El costo del repartidor propio varía según modalidad (fijo, por entrega, compartido entre comercios). El beneficio adicional no cuantificado es la propiedad de los datos del cliente y la ausencia de precios inflados en carta.
| Variable | Valor |
|---|---|
| Costo de infraestructura mensual (VPS, dominio, correo) | ≈ 250.000 |
| Tarifa media por comercio | 200.000 |
| Comercios para cubrir infraestructura | 2 |
| Comercios para un ingreso de Gs. 5.000.000 netos | ≈ 27 |
10Riesgos
| Riesgo | Prob. | Impacto | Mitigación |
|---|---|---|---|
| El comercio no genera demanda propia y abandona | Alta | Alto | Seleccionar comercios con clientela establecida; entregar material de difusión (QR impreso, enlace para redes); medir pedidos por comercio desde el primer mes. |
| Herramienta regional se localiza para Paraguay | Media | Medio | Velocidad de salida; relación directa con comercios; integración QR local como diferencial. |
| Cambios en políticas de WhatsApp sobre enlaces o mensajes | Baja | Medio | Panel como canal principal; WhatsApp como notificación; Cloud API como vía formal en fase 2. |
| Volumen insuficiente de comercios | Media | Alto | Umbral de decisión tras el piloto (ver sección 11). |
| PedidosYa reduce comisiones tras la compra por Uber | Baja | Medio | El argumento de datos propios y precios sin inflar se mantiene aunque la comisión baje. |
| Carga de soporte por comercios con baja alfabetización digital | Alta | Medio | Carga inicial del catálogo hecha por el proveedor; panel con mínimo de opciones; soporte por WhatsApp. |
11Plan de validación
| Etapa | Duración | Actividades | Criterio de avance |
|---|---|---|---|
| 1. Entrevistas | 2 semanas | Entrevistar 5 a 10 restaurantes de una misma ciudad. Relevar volumen por plataforma, comisión real pagada, repartidor disponible, medios de pago aceptados. | Al menos 3 comercios dispuestos a probar. |
| 2. MVP | 4 a 6 semanas | Construir los módulos marcados como MVP en la tabla 8.1. Cargar catálogos de los comercios piloto. | Pedido de punta a punta operativo en los 3 comercios. |
| 3. Piloto | 8 semanas | Operación sin costo. Medir pedidos por semana, tiempo de aceptación, incidencias, uso de cada medio de pago. | Mínimo 30 pedidos por comercio por mes al cierre; 2 de 3 comercios dispuestos a pagar. |
| 4. Decisión | 1 semana | Revisar métricas, fijar tarifa, definir si se continúa, se ajusta o se cierra. | Decisión documentada. |
11.1Información pendiente
- Ciudad de inicio del piloto.
- Comercios o contactos gastronómicos disponibles para entrevistas.
- Condiciones comerciales de Bancard y Tigo Money para QR dinámico (fase 2).
- Comisión efectiva de Monchis, no publicada.
12Fuentes
- ABC Color (2026). Uber-PedidosYa: la compra que despierta expectativas y alertas entre comercios paraguayos.
- InfoNegocios. Con más de 70.000 usuarios activos, Monchis es la aplicación de delivery número 1 en Paraguay.
- Monchis. Propuesta para comercios.
- Club de Ejecutivos. El omnipresente delivery.
- Diario HOY. Quedarse en casa y el beneficio del delivery en Paraguay.
- 5días. La competencia redefine el mercado del delivery con nuevos servicios.
- Sensor Tower (2025). Top 5 Food Delivery Apps in Paraguay, Q2 2025.
- Jefe (2026). Comisión de PedidosYa: cuánto cobra a restaurantes.
- Fudo (2026). 10 mejores plataformas de delivery propio sin comisiones.
- Watsi (2025). Sistema de pedidos por WhatsApp para restaurantes.
- delivery.com.py. Envíos y entregas en Paraguay.
- InfoNegocios (2025). A cinco años de su llegada, el QR supera los 13 millones de pagos mensuales en Paraguay.
- InfoNegocios. Tigo Money y Bancard se unen para el pago QR.
- Última Hora (2026). El método QR avanza y acapara el 55 % de los pagos electrónicos.
- Forbes Colombia (2021). Chiper buscará atender 100.000 tiendas de barrio tras recaudar US millones.
- Descubre VC. Chiper: plataforma B2B para tiendas de barrio.
- Revista Economía (Perú). Rupaq Business, software de gestión de rutas para distribuidoras.
- PR Newswire (2025). Plub se asocia con Shipsy para su logística de última milla en Paraguay.
- LatamList. Picap expande su servicio de logística a Paraguay y Guatemala.