DEV3 Ladlero – Food Delivery Laravel Script with Kitchen Timers, Rider Dispatch & Food Halls (Flutter Apps)

Ladlero is a food delivery platform that you host yourself, built by DEV3 Technologies on Laravel 12 and Filament 4, with three Flutter apps for customers, restaurants and riders. Customers order from independent kitchens or from a food hall, kitchens accept and prepare against a timer, and riders are offered deliveries by radius. Staff work in an admin panel, restaurants in their own panel. The demo business serves the fictional seaside city of Cassimar.

No live demo: 118 grouped screenshots and two video tours show the 3D marketing site, the public ordering site, the admin and restaurant panels and all three apps. Install it with the demo data to try every role on your own server.

Ordering

• A public ordering site with a restaurant wall (each kitchen as a tile with rating, speed and delivery cost), search and filters, menus with required and optional modifier groups, a cart, checkout with a rider tip and a total that is re-quoted on every change.
• Food halls: mix up to three kitchens in one order with one rider, one delivery fee and a subtotal per kitchen. If one kitchen declines, the customer sees the refund first and chooses to continue with the others or cancel everything.
• Card, wallet and cash on delivery, vouchers and restaurant-funded promos.
• Order tracking, delivered and rating screens, and a refund status that shows every refund, its amount and whether it is paid.

Kitchens

• A restaurant panel and a restaurant app with a ticket rail (new, cooking, ready), accept or reject with a reason, prep time from 10 to 45 minutes, a one-time extension, sold-out switches for dishes and single modifier options, pause and opening hours, earnings and period statements.
• Accept deadlines are enforced under a lock when an order is read, so nothing depends on the cron firing on time.

Riders and dispatch

• The rider app offers deliveries with a countdown ring, expanding the radius in rounds (2, 4 and 7 km by default), then guides to the kitchen, takes the pickup code, guides to the customer and takes the drop code. Cash orders need the exact cash entered, and a drop that cannot be completed has its own reasons.
• Earnings with a daily chart, cash owed and cash-out.
• An ops panel with unassigned orders, an offers log showing who got each offer and how they answered, zones, and a live order board.
• Only the assigned rider can complete a handoff; kitchen staff cannot.

Money

• Commission rules by default, cuisine and restaurant with dates and priority, refunds up to an ops limit with a reason, and a refund table that decides who bears each cost (the tip returns to the customer only when the rider is at fault).
• Restaurant statements per period with food, commission, refunds and VAT, as print-ready HTML. Reports for GMV, take rate, acceptance rate, delivery time and refund rate per restaurant.
• Money is applied only when the gateway confirms payment, and the concurrency checks include parallel payouts.

The apps

• Customer, restaurant and rider apps in Flutter with light and dark themes, a tablet layout, English and Arabic with right-to-left layout, and bundled fonts.
• Each app starts in demo mode with built-in data and switches to your server with two build flags.

What is included

• The Laravel application with Composer packages and compiled assets inside (no Node.js or Composer on the server), the three Flutter projects in apps/, the shared DEV3 Flutter package, a web installer and HTML documentation.
• Demo data for the fictional city: 41 kitchens, 845 dishes and 57 riders at the start, with about 18,000 orders of history and a keep-alive command that keeps orders in flight.

Good to know

• The admin and restaurant panels are English only. The public site, the customer account and all three apps include Arabic with right-to-left layout.
• Restaurant statements are HTML only (print-ready), not PDF files.
• The apps use simulated GPS. The rider's position and the tracking line come from a simulator, and the dispatch map is a stylised drawn map. For real tracking you need to add a GPS plugin to the apps and connect a map provider.
• There is no address geocoder. An address typed on the site is pinned near the middle of the active restaurants unless the browser supplies a location. Add a geocoding provider for production.
• Scheduled orders are available through the API and the apps; the web checkout orders as soon as possible.
• Payments, SMS and push are simulated by default. Stripe, Razorpay and PayPal drivers are included but were not run against real accounts, and push and SMS were not tested with real providers.
• The apps were not tested on physical devices. They build as debug Android packages and run on the iOS simulator.
• Fonts: the apps bundle a display font with Latin glyphs only; Arabic text falls back to a system Arabic font.
• Use MySQL or MariaDB on a live site. Some payout and cash unit tests pass without their fixes on SQLite, and the concurrency checks that prove them run on MySQL 8.
• Name: Ladlero is a working name checked by a web search only, not a trademark clearance. Check it before you launch under it.
• No hosted demo. All restaurants, dishes and people in the screenshots are fictional; the dish art is drawn in code.

Quality checks

Ladlero 1.0.0 passed the seven release gates of the DEV3 Laravel suite on the final code: static analysis (Larastan level 6, 0 errors), 359 Pest tests with 4,525 assertions, a front-end size budget, migrations and seeding on MySQL 8 and SQLite, a headless-browser pass over 150 pages and 44 happy paths with parallel-request race checks on MySQL, an installer test from the zip, and a secret scan. The apps passed analysis and tests with debug Android and iOS simulator builds: 128 tests for the customer app, 136 for the restaurant app and 184 for the rider app. Lighthouse scores were not measured.