Menulog is a historical reference for this build
Just Eat Takeaway.com's announcement dated November 12, 2025 states that Menulog would stop accepting orders in Australia on November 26, 2025. The group had separately announced the end of its New Zealand operation on April 16, 2024.
A “Menulog clone” therefore means an independently branded local marketplace informed by a historical operating model. It is not a way to join Menulog's current Australian service, acquire its customers, or obtain its software. Use your own identity and implementation, with the rights required for any code or assets you use.
Learn from the published courier workflow, not a screenshot
Menulog's still-accessible courier run guide describes designated delivery zones, runs, availability, and location-based offers. Its delivery-experience guide describes accepting an offer, confirming pickup, sharing status, and resolving delivery difficulties.
Read those pages as historical documentation; their availability does not reverse the closure announcement. The relevant engineering lesson is the connection between merchant readiness, courier availability, service area, and the customer's next update. A customer app showing restaurants cannot operate that connection by itself.
For your marketplace, write down who owns each handoff. The merchant controls preparation. Dispatch must know whether a delivery can be assigned. The customer needs an honest status. Support needs authority to recover the order when those states diverge.
Start with one service area and a merchant promise
Choose the stores and hours you can actually serve. Define menu ownership, acceptance expectations, preparation updates, delivery zones, customer charges, cancellations, and support. Do not make a city-wide promise before you know where merchants and delivery capacity overlap.
Decide whether each merchant supplies delivery, your operation assigns drivers, or a connected provider fulfills the order. That is a decision for your independent business, not an assertion about a currently available Menulog product. Describe the tracking and failure responsibility separately for each model.
Onboard a merchant with a real menu, required modifiers, unavailable items, opening hours, and the payment arrangements it accepts. The merchant agreement must also explain commercial terms, refunds, and settlement. A copied interface does not create those agreements or a reliable supply network.
Test the order whose preparation misses the courier window
Use an illustrative pilot: a merchant accepts an order, but preparation takes longer than expected while the available courier is completing another delivery. The operator must determine whether to wait, reassign, contact the customer, or cancel under the agreed policy.
Follow the same order reference through merchant acceptance, the updated ready time, assignment, pickup confirmation, delivery status, and payment outcome. Do not mark the order as collected merely because a driver was assigned. If the driver leaves the run, identify who can recover the assignment and how the customer is informed.
Then test a merchant rejection after payment and a recipient who cannot be reached. Record the final fulfillment state, refund or charge decision, and merchant settlement effect. These tests expose the operational work a polished “clone” demo can conceal.
Design your own economics without importing historical rates
Separate the value of merchandise from platform revenue. For each completed order, model the contractual merchant/platform charges and customer service or delivery charges, then subtract the costs your operation bears: processing, delivery, support, refunds, promotions, and software.
For a rejected or failed order, recalculate who keeps which charge and who absorbs the delivery attempt. A gross order value is not profit, and a merchant balance is not a completed payout. Validate the actual payment provider, onboarding, settlement, and reconciliation process.
Do not treat an old Menulog commission, courier earning, or delivery fee as a current quote or a rate your business should copy. Obtain the costs and terms for your own territory and workload before deciding the public price.
Choose the implementation by the work it actually covers
A licensed script requires code and license review, hosting, security, payments, app builds, and a maintenance owner. Custom development lets the team implement a distinct model, with the corresponding engineering and operating responsibilities. A configured platform can reuse existing commerce and delivery products when those workflows fit.
For a hybrid, specify which service owns menus, orders, dispatch, payments, and refunds. Keep one authoritative state transition for each event; two systems that can cancel the same order independently need a recovery rule.
Ordering.co's marketplace foundation, merchant workspace, and delivery workflow can be evaluated against that model. Its frontend code is open source and included with each product, while the backend and API are managed by default under the source-code terms. None of that supplies Menulog's proprietary code, trademarks, network, or historical customer records.
Release a supported local service before adding territory
Price implementation separately from ongoing operation: catalog setup, branding, payment and delivery connections, custom rules, releases, merchant training, and support coverage. Include recurring provider and platform charges rather than relying on an app-license price alone.
Start with a small merchant group and a defined service window. Accept the pilot when ordinary orders, preparation delays, unavailable drivers, payment failures, and refunds can be resolved by the working team. Measure the events and costs you actually observe; this article does not promise a launch deadline or a Menulog-like result.
The objective is a business that can explain and fulfill each order under its own brand. Historical marketplaces offer useful design lessons, but your contracts, service capacity, and customer responsibility have to exist independently.