App de delivery propia vs WhatsApp y marketplaces: cómo partir sin infraestructura (y qué construir primero)

Operar envíos sin infraestructura se siente “barato” hasta que deja de serlo: pedidos por WhatsApp, direcciones en Excel, el repartidor avisa por llamada y nadie sabe en qué estado quedó el paquete. Las pymes y mensajerías chicas que parten así no buscan “una app bonita”: buscan control — saber qué se pidió, a quién se asignó y con qué evidencia se entregó — sin pagar el peaje permanente de un marketplace ni inventar un Uber Eats desde cero.

Qué están buscando las empresas que parten sin app

En discovery con negocios pequeños (dark kitchen, courier local, retail con despacho propio, farmacia, B2B entre locales) el patrón se repite:

1. Canal de pedido improvisado. WhatsApp, Instagram o teléfono. Funciona con 5 envíos al día; se rompe a los 30.
2. Cero visibilidad operativa. No hay mapa, filtros ni historial. Si el rider no responde, el pedido “desaparece”.
3. Datos del cliente ajenos. En PedidosYa, Rappi o Uber Eats el marketplace se queda con la relación y cobra comisión alta (órdenes de magnitud típicas en LatAm: ~20–35% del ticket, más boost y empaque). Sirve para adquirir demanda; quema margen si es tu único canal.
4. Miedo a “desarrollar una app”. Asocian software propio con años, presupuesto infinito y un prototipo que no llega a producción.
5. Necesidad de tres roles, no de una pantalla. Quien crea el envío, quien asigna y quien reparte. Si falta uno, vuelves al Excel.

Lo que piden, en su lenguaje: “algo con mi marca”, “que el repartidor vea el pedido en el celular”, “que yo vea el mapa”, “foto de entrega”, “sin comisión por pedido”.

Señales de que ya no alcanza WhatsApp + Excel

• Pierdes pedidos entre chats o los duplicas.
• No puedes decirle al cliente dónde va sin llamar al rider.
• Contratas o mezclas flota propia y externos y no hay un solo registro de asignación.
• Quieres crecer a otra comuna o vertical y el proceso no escala.
• Ya pagas comisiones de marketplace y quieres canal propio para clientes recurrentes (aunque mantengas el marketplace como adquisición).

Si tu caso es “cinco envíos semanales entre amigos”, quizá no necesitas plataforma todavía. Si tu caso es “esto ya es el negocio”, sí.

App propia, SaaS genérico o white label: qué conviene

Enfoque	Cuándo encaja	Riesgo típico
Seguir en WhatsApp / planilla	Volumen muy bajo, validación temprana	Caos, sin auditoría, imposible escalar
Solo marketplace (PedidosYa, Rappi, etc.)	Necesitas demanda externa ya	Comisión, poco control del cliente, dependencia
SaaS logístico cerrado	Quieres operar rápido con reglas fijas del proveedor	Límites de marca, datos y personalización
White label / base de producto + partner	Quieres **tu marca**, tres superficies (cliente, admin, rider) y código/activo mantenible	Inversión inicial; a cambio de control
App 100% desde cero sin referencia	Requisitos muy raros o equipo interno grande	Plazo, costo y riesgo de no llegar a producción

Para la pyme que parte sin infraestructura, el sweet spot suele ser: no reinventar el modelo de datos de última milla, pero sí adaptar marca, tarifas, estados y vocabulario (paquetes ≠ menús).

Qué debe tener una plataforma de última milla (checklist real)

Olvida el pitch de “somos el próximo Uber”. Evalúa si el sistema cubre el ciclo completo:

1. Alta de pedido (app o panel cliente)

Direcciones de retiro y entrega, datos del envío, foto del paquete, estado inicial en base de datos — no en un chat que se archiva.

2. Operación (panel admin)

Listados con filtros y periodos, mapa, asignación o cambio de repartidor con registro de momento, finanzas por cliente cuando aplica, cola de solicitudes de riders nuevos.

3. Ejecución en calle (app rider)

Pedidos asignados / en progreso / entregados, ubicación, disponibilidad (conectar/desconectar), evidencias fotográficas tipadas.

4. Una sola fuente de verdad

Mismo modelo de datos entre las tres superficies. Sin “API improvisada” entre tres proveedores distintos.

5. Identificación del envío

QR u otro identificador para que cliente y operación hablen del mismo pedido. (Escaneo automático por el rider: solo si está en el alcance; no lo des por hecho.)

6. Listo para producción

Auth por roles, almacenamiento seguro de fotos, builds hacia tiendas, reglas de quién ve qué. Demo ≠ operación.

Cómo Genbia resuelve esto (referencia Golleva)

En Genbia implementamos plataformas de delivery / última milla con tu marca. La referencia que puedes ver en pantalla es Golleva: tres aplicaciones (panel web, app cliente, app rider) sobre el mismo Postgres y Supabase (Auth, Storage, Realtime).

Detalle del producto y capturas reales: Plataforma delivery white label · Genbia.

Flujo de un pedido (el que importa)

1. Cliente crea el pedido — direcciones, datos, foto, estado inicial.
2. Admin opera y asigna — filtros, mapa, cambio de rider con trazabilidad.
3. Rider ejecuta — pedidos activos, ubicación, evidencias en Storage.
4. Todo queda auditado — una base, políticas por rol, actualizaciones casi en tiempo real donde aplica.

Para quién sirve (no solo comida)

• Mensajería urbana y courier de paquetes.
• Retail / e‑commerce con flota propia o mixta.
• Dark kitchen o delivery de comida con marca propia.
• Farmacias, documentos, reparto B2B entre locales.
• Empresas que mezclan riders propios y contratistas bajo las mismas reglas.

Stack (para quien evalúa mantenibilidad)

• Panel: React, TypeScript, Vite, mapas Leaflet, Supabase JS.
• Apps: Expo / React Native (cliente y rider).
• Backend: Supabase (Postgres + RLS + Storage + Realtime); Edge Functions según pagos u otras integraciones.

No te vendemos “una plantilla genérica de comida”. Partimos de una base probada y adaptamos branding, naming y reglas de negocio a tu vertical y país.

Delivery propio vs marketplace: la decisión con números en la cabeza

No hace falta un Excel perfecto para decidir bien. Preguntas útiles:

• ¿Qué % de tus pedidos ya son clientes que te buscarían sin el marketplace?
• ¿Cuánto margen te comes hoy en comisión + publicidad interna del app?
• ¿Tienes (o puedes tener) 1–N riders propios o una red de externos gobernable?
• ¿Necesitas que el cliente final vea tu marca en el seguimiento?

Regla práctica que usamos en conversación: el marketplace puede seguir siendo canal de adquisición; el canal propio protege margen y relación. La plataforma white label es la capa operativa de ese canal — no un reemplazo mágico del marketing.

Errores que cometen las pymes al “hacerse la app”

• Pedir “una app” cuando en realidad faltan tres superficies + backend.
• Empezar por el diseño de iconos y olvidar asignación, evidencias y estados.
• Contratar un freelance que entrega pantallas sin modelo de datos ni roles.
• Copiar Uber Eats de comida cuando el negocio es paquetes (vocabulario y estados distintos).
• Asumir que el QR “ya escanea solo” sin haberlo pedido en el alcance.
• No planear handoff: sin traspaso, quedas atado a quien “entiende el lío”.

Cómo empezar con Genbia

1. Agenda una reunión corta de descubrimiento.
2. Trae tu flujo actual (aunque sea WhatsApp) y 1–2 dolores medibles: pedidos perdidos, tiempo de asignación, reclamos sin evidencia.
3. Revisamos si parte de la base Golleva / software-delivery encaja, qué se retematiza y qué se construye a medida (pagos, OMS/ERP, escaneo QR, telemetría de flota, etc.).
4. Salimos con alcance acotado hacia producción, no hacia un prototipo de feria.

Puedes escribirnos desde Contacto, por WhatsApp o a [email protected]. La página del servicio con capturas y FAQ está en genbia.com/cl/software-delivery.

Genbia — consultoría tecnológica: software, automatización e IA para empresas que quieren operar con menos fricción. Golleva es una referencia de producto de última milla desarrollada/operada en el ecosistema Genbia; Uber Eats, PedidosYa, Rappi y marcas afines pertenecen a sus respectivos titulares. Genbia no está afiliada a esas plataformas; implementamos software white label e integraciones según el alcance acordado.