Menulog es una referencia histórica para este desarrollo
El comunicado de Just Eat Takeaway.com del 12 de noviembre de 2025 indica que Menulog dejaría de aceptar pedidos en Australia el 26 de noviembre de 2025. El grupo había anunciado por separado el fin de su operación en Nueva Zelanda el 16 de abril de 2024.
Por tanto, “clon de Menulog” significa aquí un marketplace local independiente inspirado en un modelo histórico. No permite incorporarse a un servicio australiano actual de Menulog, adquirir sus clientes ni obtener su software. Usa identidad e implementación propias y los derechos necesarios sobre código y recursos.
Aprende del flujo de reparto publicado, no de una captura
La guía de turnos de repartidores de Menulog, todavía accesible, describe zonas, turnos, disponibilidad y ofertas basadas en ubicación. Su guía de experiencia de entrega describe aceptación, recogida, estados y resolución de dificultades.
Léelas como documentación histórica: que sigan disponibles no revierte el comunicado de cierre. La enseñanza técnica es conectar preparación del comercio, disponibilidad del repartidor, zona y próxima actualización al cliente. Una app que muestra restaurantes no opera por sí sola esa conexión.
Define para tu marketplace quién controla cada traspaso. El comercio prepara; despacho determina si puede asignar; el cliente necesita un estado honesto; soporte requiere autoridad para recuperar el pedido si esos estados divergen.
Empieza con una zona y una promesa a los comercios
Elige tiendas y horarios que realmente puedes cubrir. Define control del menú, aceptación, preparación, zonas, cargos, cancelación y soporte. No prometas atender toda la ciudad antes de conocer dónde coinciden comercios y capacidad.
Decide si cada comercio entrega, tu operación asigna repartidores o cumple un proveedor conectado. Es una decisión de tu negocio independiente, no una afirmación sobre un producto Menulog actual. Describe seguimiento y responsable de fallos para cada modelo.
Da de alta un comercio con menú real, modificadores, agotados, horarios y pagos aceptados. Su acuerdo también debe explicar condiciones comerciales, reembolsos y liquidación. Copiar una interfaz no crea acuerdos ni una red de oferta confiable.
Prueba el pedido cuya preparación no coincide con el reparto
Usa un piloto ilustrativo: el comercio acepta, pero la preparación se retrasa mientras el repartidor disponible termina otra entrega. El operador debe decidir si espera, reasigna, contacta al cliente o cancela según la política.
Sigue una referencia por aceptación, nueva hora de preparación, asignación, confirmación de recogida, entrega y resultado del pago. No marques recogido porque se asignó un conductor. Si termina su turno, identifica quién recupera la asignación y cómo se informa al cliente.
Prueba después rechazo del comercio tras pagar y destinatario inubicable. Registra cumplimiento final, decisión de reembolso o cargo y efecto sobre la liquidación. Estas pruebas muestran trabajo operativo que una demo visual de “clon” puede ocultar.
Diseña tu economía sin importar tarifas históricas
Separa valor de mercancía e ingreso de plataforma. Por pedido completado, modela cargos contractuales al comercio y cargos de servicio o reparto al cliente; resta costes que soportas: procesamiento, entrega, soporte, reembolso, promociones y software.
Para rechazo o fallo, recalcula quién conserva cada cargo y quién absorbe el intento. Valor bruto del pedido no es utilidad, ni saldo del comercio es pago realizado. Valida proveedor, alta, liquidación y conciliación reales.
No uses comisión, ingreso del repartidor o tarifa histórica de Menulog como cotización actual ni tasa que debas copiar. Obtén costes y condiciones de tu territorio y carga antes de fijar precios públicos.
Elige implementación por el trabajo que realmente cubre
Un script licenciado requiere revisar código y licencia, hosting, seguridad, pagos, builds y responsable de mantenimiento. El desarrollo custom permite implementar un modelo distinto con su responsabilidad técnica y operativa. Una plataforma configurada reutiliza productos comerciales y de reparto si encajan.
En un híbrido, especifica quién controla menú, pedidos, despacho, pagos y reembolsos. Mantén una transición autorizada por evento; si dos sistemas pueden cancelar independientemente, necesitan una regla de recuperación.
Evalúa la base de marketplace de Ordering.co, operación del comercio y reparto contra ese modelo. El frontend abierto se incluye con cada producto; backend y API se gestionan por defecto según los términos de código. Eso no aporta código propietario, marcas, red ni registros históricos de clientes de Menulog.
Activa un servicio local atendible antes de ampliar territorio
Cotiza por separado implementación y operación: catálogo, marca, pagos, reparto, reglas específicas, publicación, capacitación y cobertura de soporte. Incluye cargos recurrentes de proveedores y plataforma, no solo licencia.
Empieza con pocos comercios y ventana definida. Acepta cuando el equipo resuelva pedidos normales, preparación tardía, falta de repartidores, pagos fallidos y reembolsos. Mide eventos y costes observados; el artículo no promete plazo de lanzamiento ni un resultado como Menulog.
El objetivo es un negocio capaz de explicar y cumplir pedidos con su marca. Los marketplaces históricos aportan lecciones, pero contratos, capacidad y responsabilidad ante clientes deben existir independientemente.