--- title: "Clon de Menulog: modelo histórico y desarrollo" description: "Conoce el cierre de Menulog en Australia y su flujo histórico de reparto; define un marketplace propio con comercios, zonas, costes y entrega." canonical: https://www.ordering.co/es/blog/menulog-clone-what-it-is-how-to-build-one/ lang: es --- # Clon de Menulog: aprende del modelo histórico y crea tu operación Conoce el cierre de Menulog en Australia y su flujo histórico de reparto; define un marketplace propio con comercios, zonas, costes y entrega. 4 min de lectura· Ordering.co· Guías ## Menulog es una referencia histórica para este desarrollo El [comunicado de Just Eat Takeaway.com del 12 de noviembre de 2025](https://newsroom.justeattakeaway.com/en-WW/257572-just-eat-takeaway-com-ceases-operations-in-australia/) 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](https://newsroom.justeattakeaway.com/en-WW/236620-just-eat-takeaway-com-to-end-operations-in-new-zealand/). 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](https://courier-help.menulog.com/hc/en-au/articles/900005556283-Delivery-Run-Basics), todavía accesible, describe zonas, turnos, disponibilidad y ofertas basadas en ubicación. Su [guía de experiencia de entrega](https://courier-help.menulog.com/hc/en-au/articles/900004604806-The-Delivery-Experience) 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](https://www.ordering.co/es/solutions/marketplaces/), [operación del comercio](https://www.ordering.co/es/platform/ordering-merchant/) y [reparto](https://www.ordering.co/es/platform/ordering-delivery/) 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](https://www.ordering.co/es/developers/source-code-license/). 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. ## Sigue leyendo. - ## [Clon de Deliveroo: qué es y cómo crear uno](https://www.ordering.co/es/blog/deliveroo-clone-what-it-is-how-to-build-one/) Crea un marketplace tipo Deliveroo: modelo de negocio, flujos esenciales, cuatro formas de desarrollo y factores que definen el costo y el lanzamiento. - ## [DiDi Food para restaurantes: alta, operación y canal propio](https://www.ordering.co/es/blog/didi-food-for-restaurants/) Evalúa DiDi Food como canal del restaurante con alta y operación oficiales de México, costes, reparto y límites frente a tus pedidos propios. - ## [Clon de DoorDash: qué es y cómo crear uno](https://www.ordering.co/es/blog/doordash-clone-what-it-is-how-to-build-one/) Planea un marketplace de entregas con flujos claros para comercios, clientes, repartidores y despacho antes de elegir cómo construirlo. ## Míralo funcionando con tu propio menú. La forma más corta de entender todo esto es ver cómo un pedido pasa de tu tienda en línea a la sucursal y de ahí al repartidor, en tus propias sucursales. [Agenda una demo](https://www.ordering.co/es/contact/?meeting=demo#book)[Ve una demo en vivo](https://www.ordering.co/es/demo/)