Algunas grandes cadenas sí desarrollan su software de catering internamente. Waitrose, en el Reino Unido, lleva años operando su propio servicio «Food Made To Order». Puede funcionar. Pero los compromisos reales no suelen ser los que asume el business case inicial.
La línea del business case suele decir «proyecto de desarrollo de 800 K€». La realidad, tomada de referencias públicas de proyectos internos en la distribución alimentaria, se parece más a esto:
| Fase | Realidad típica | Coste orientativo |
|---|---|---|
| Descubrimiento y especificación | 3–6 meses de entrevistas, visitas a tiendas y evaluación de proveedores. A menudo produce un documento de 200 páginas que se vuelve a especificar 12 meses después. | 100–200 K€ |
| Desarrollo del MVP (año 1) | Catálogo, pedidos, programación de recogidas, administración básica. Un equipo interno de 6–8 personas o un integrador. Se retrasa de 3 a 9 meses. | 0,8–1,5 M€ |
| Motor de reglas (año 2) | Capacidad, fecha de recogida, hora de recogida, precios, cupones. Siempre infravalorado en el plan original; normalmente exige rearquitecturar. | 0,6–1,2 M€ |
| Despliegue multitienda (años 2–3) | Interfaces de configuración por tienda, formación de responsables, piloto, expansión. Cada oleada de despliegue saca a la luz nuevos casos límite que exigen trabajo de producto. | 400–800 K€ |
| Continuo (año 3+) | Equipo de plataforma de 4–6 personas a perpetuidad: correcciones, actualizaciones regulatorias, nuevas integraciones de TPV, compatibilidad de navegadores, parches de seguridad. | 0,6–1 M€ / año |
| Total hasta una plataforma madura | 3–4 años para alcanzar la paridad funcional con lo que DeliChain ofrece hoy, más un coste continuo permanente. | 3–5 M€ una vez + 0,6–1 M€/año |
Rangos de coste orientativos, tomados de referencias públicas de proyectos retail-tech. Las plataformas de catering de desarrollo interno rara vez se documentan públicamente porque rara vez se consideran ventajas competitivas que merezca la pena revelar.
Para una cadena de 50 tiendas que empieza desde cero hoy.
Las especificaciones internas asumen que el dominio del catering es más simple de lo que es. Estos son los puntos que aparecen sistemáticamente en el año 2 y obligan a rearquitecturar.
No una única cifra por tienda, sino por día, por familia de productos, por turno. Más excepciones de temporada. Más topes de emergencia cuando el personal está de baja.
Una antelación de 3 días a las 18:00 no es lo mismo que a las 09:00 de la mañana siguiente. Las fechas deben avanzar correctamente entre zonas horarias, fines de semana y festivos propios de cada tienda.
B2B vs. consumidor. Descuento familiar acumulable con cupón pero no con promoción de temporada. Solo el motor de reglas de precios suele ser el 20 % de la plataforma.
Cinco vistas distintas (hoja de producción, albarán, pedido completo, sin pagar, todos). Cada una tiene convenciones de formato que los responsables de tienda esperan del antiguo proceso en papel.
Productos a medida con más de 30 opciones, selecciones dependientes, precios dinámicos, campos de texto libre (el nombre en la cinta de mazapán del Kagemand). Los generadores de formularios genéricos no lo manejan.
El cliente cancela 6 horas antes de la recogida; la producción ya ha empezado. ¿Qué hace la política de reembolso y cómo la aplica la plataforma sin que una persona decida caso por caso?
No estamos en contra de construir. Hay situaciones reales en las que es la decisión correcta:
Si se cumplen dos o más de estos criterios, merece la pena modelar en serio la vía interna. Si no se cumple ninguno, las cuentas casi siempre favorecen comprar.
Para cadenas de menos de 200 tiendas, construir en casa casi nunca es la decisión correcta — el coste de desarrollo supera el resultado del catering.
Para cadenas de 200 a 1.000 tiendas, construir puede salir a cuenta, pero solo con un equipo de plataforma estratégico ya en marcha y una ventana de paciencia de más de 3 años.
Para todos los demás — incluida la ambición de «tenemos TI, podríamos construirlo» que suele surgir en los comités de dirección — DeliChain acorta al menos dos años el camino de la decisión a la operación.
Lo que preguntan de verdad los comités de dirección cuando las cifras del coste real están sobre la mesa.
Probablemente no parar, sino replantear. El trabajo hecho hasta ahora en el esquema de catering, el motor de reglas o las herramientas de administración rara vez se desperdicia — las lecciones se trasladan. La pregunta difícil es si seguir hasta la v1 o cambiar a DeliChain y reutilizar el desarrollo interno para lo que es realmente único de vuestra cadena (integración de fidelización, conexión con el ERP, lógica de cupones a medida). La mayoría de las cadenas descubren que el catálogo, los pedidos, la gestión de franjas y el aislamiento entre empresas no es donde quieren pasar los próximos 18 meses.
Hoy no. DeliChain se ofrece como producto configurado, no como biblioteca de componentes. Las cifras del coste real de esta página asumen que compráis toda la plataforma e integráis en los bordes (autenticación, ERP, pagos, fidelización). Si queréis una relación solo de componentes, es otra conversación y casi con seguridad la forma equivocada — el modelo de empresas, el motor de reglas y el flujo de pedidos están profundamente entrelazados.
Sí — dentro de las superficies de extensión de la plataforma. Tenéis una API pública, webhooks para cada evento relevante, motores de reglas configurables y acceso a vuestra propia réplica de Postgres para analítica. Lo que no tenéis es acceso de escritura directo al esquema operativo, porque rompería el contrato de actualización. Si vuestros requisitos de personalización obligaran a cambios a nivel de esquema, construir en casa está realmente sobre la mesa — ved la sección «Cuándo construir» más arriba.
A menudo los requisitos parecen únicos pero resultan ser variantes de las mismas seis formas de reglas (capacidad, antelación, franja, precio, cupón, surtido). El motor de reglas es la respuesta a la mayoría de las objeciones del tipo «pero nuestra cadena hace X de otra forma». Las excepciones suelen ser fidelización, ERP y facturación a franquicias — eso es trabajo de integración, no de plataforma, y es donde vuestro equipo de TI debería dedicar su tiempo de todos modos.
De referencias públicas: el gasto de Waitrose en su plataforma de catering, la replataformación de Tesco F&F y varios grandes programas digitales de la distribución alimentaria de los que ha informado la prensa de consultoría. En DeliChain también hemos calculado lo que nos costaría reconstruir desde cero — las cifras caen en la misma franja. No son previsiones precisas por cadena; son el orden de magnitud que todo comité de dirección debería incluir en una comparación honesta del coste total.
Sí — ese es el modelo de despliegue previsto. No intentamos ser vuestro proveedor de identidad, vuestro ERP, vuestro motor de fidelización ni vuestra pasarela de pago. La integración con esos sistemas se hace mediante API y webhooks y es exactamente donde vuestro equipo de TI aporta valor. Un primer proyecto de integración típico son 4–8 semanas de trabajo para una cadena de 50 tiendas, gran parte de ellas gestión del cambio interna, no programación.
Os guiaremos por el plan de despliegue real de una cadena de 50 tiendas — qué pasa en los meses 1, 4 y 9.
Solicitar una demoO escríbenos directamente a hello@delichain.com