A multi-courier delivery platform for restaurants and retailers
RouteMasters is a delivery service for restaurants and retailers, and VLO Labs built the multi-tenant software that runs it. Merchants connect once and the platform handles quoting, courier selection, tracking, refunds and financial reporting across several courier networks.
- Industry
- Logistics and last-mile delivery
- Status
- Live in production
- Platforms
- Web admin panel, Web merchant portal, Public marketing and onboarding site, REST API
The challenge
A restaurant or retailer that offers delivery usually does not want to run a fleet, and it does not want to integrate with each courier network separately either. Each network has its own API, its own price for the same trip, its own status updates and its own rules for what it will carry. A merchant that connects to one network directly is tied to that network's pricing and availability.
RouteMasters needed a single layer between merchants and couriers. It had to accept orders from a merchant's own systems and from restaurant ordering platforms, price each delivery before the merchant committed, choose a courier, and report back as the order moved from pickup to drop-off.
The money side was just as demanding. The business pays couriers and bills merchants, so it needs per-order visibility into cost, price, refunds and disputes. Merchants, in turn, need to see their own orders without seeing courier costs or margins.
Our approach
VLO Labs built RouteMasters as a multi-tenant Laravel application with business logic organized into services by domain: quotes, orders, courier integrations, refunds, reporting and webhooks. Each merchant has its own API credentials, pricing, courier settings and webhook endpoints. Courier integrations sit behind a shared abstraction, and inbound status updates from every network are normalized into one order lifecycle.
Work that can wait runs asynchronously. Queue workers process courier requests on separate high and low priority queues, and scheduled jobs send merchant updates and build financial reports. Web traffic and background processing run on separate AWS infrastructure and deploy independently, so the async tier can be released without touching the web servers.
The merchant portal was built as a separate application area from the internal panel, with its own layout, stylesheet and access middleware. Keeping it separate makes it easier to enforce what merchants may see: their own orders and refunds, and not courier identities or platform margins.
What we built
Quoting and order API
A REST API where merchants check service coverage, request a time-limited, single-use quote, accept it to create a delivery, then add a tip, cancel or request a refund. A separate sandbox lets integrators test without live deliveries.
Courier selection and dispatch
Orders are quoted across courier networks and dispatched automatically, with separate handling for order types that need it.
Ordering platform integrations
Dedicated endpoints with their own authentication for restaurant ordering and order aggregation platforms, so orders placed in those systems flow straight into delivery.
Merchant portal
A self-service area where merchants view orders and driver location, cancel orders, manage locations, inspect and retry webhooks, submit refund requests and contact support.
Operations panel and financial reporting
An internal panel for orders, stores, refunds, courier disputes and driver messaging, with billing, profitability and courier reports. Hourly and daily financial reports are pre-aggregated by scheduled jobs.
Public site and AI assistants
A marketing site with merchant onboarding, call scheduling and a ZIP code coverage check, plus an AI chat that lets customers ask about the status of a same-day order. Merchants have their own chat assistant inside the portal.
Engineering highlights
One order lifecycle across different courier APIs
Each network reports status in its own format. Provider-specific event handlers record every inbound webhook and translate it into a single set of order statuses, which then drive merchant webhooks and live updates.
Accurate timing data when couriers change status
Couriers can move an order back and forth between statuses, and a redelivery can overwrite earlier timestamps. Actual pickup and delivery times are stored as their own fields on the order, separate from the status timeline and from scheduled times, so merchant reports reflect what happened.
Merchant data kept separate by design
Portal queries are explicitly scoped to the signed-in merchant's store, and portal views are built to leave out courier names and internal financial fields. Customer-facing chat is limited to a single order lookup that returns customer-safe details such as status, driver first name and ETA.
Secrets kept out of images, tests kept away from data
Container images ship without secret values and read them from AWS Secrets Manager when they start. The unit test suite does not boot the application and will refuse to run unless it is configured for an in-memory database.
Where it stands
- Public site
- Live at routemasters.io, including merchant onboarding, call scheduling and coverage check pages
- Active development
- 4,285 commits, with the most recent on November 5, 2026
Technology
Links
Have something similar in mind?
Tell us what you need to build and we will give you a straight answer on how to approach it.
Get a free consultation