Flutter Food Delivery App Boilerplate

What a food delivery MVP actually has to get right first

A delivery app looks simple from the outside — browse, add to cart, pay — but the failure modes are all in the state. A user opens the app while offline and their cart has to survive; they background the app mid-checkout and the order can't double-submit; they sign in on a second device and their address book should follow them. The Flutter Kit gives you that backbone instead of a screenshot of one. Authentication, a persisted cart, an order lifecycle (placed → confirmed → out for delivery), and account state all live in BLoC/Cubit with get_it dependency injection, so the logic is testable and sits outside your widgets. You spend your time on the menu and the brand, not on re-discovering why a cart cleared itself.

• Firebase Auth (email, Google, Apple, anonymous) so guests can browse and convert later
• Cart state in a Cubit that survives backgrounding and login/logout
• Order lifecycle modeled as Firestore documents you can stream in real time
• Address/location-shaped models ready for a maps or geocoding package

Location and order models, concretely

The kit ships idiomatic Dart models and a repository layer rather than maps baked into a black box — a deliberate choice, because every delivery app picks a different mapping and routing provider. Restaurants, menu items, and orders are plain models with a Firestore repository behind a get_it-registered interface, so adding Google Maps, Mapbox, or a geocoding call is a clean swap, not surgery. Because orders are Firestore documents, a customer's 'out for delivery' status updates live as your backend (or a Cloud Function) writes to it.

class OrderRepository {
  OrderRepository(this._db);
  final FirebaseFirestore _db;

  Future<String> placeOrder(Order order) async {
    final ref = await _db.collection('orders').add(order.toJson());
    return ref.id; // status starts as OrderStatus.placed
  }

  Stream<Order> watchOrder(String id) => _db
      .collection('orders')
      .doc(id)
      .snapshots()
      .map((s) => Order.fromJson(s.data()!));
}

Cart, checkout, and the payments seam

Checkout is a CartCubit that totals line items, applies your fees, and exposes a clear submitting/success/error state so the button can never fire twice. For monetization, the kit wires RevenueCat — the right tool when you want a paid tier, a delivery-pass subscription, or to gate premium restaurants, because in-app digital purchases on iOS and Android must go through StoreKit 2 and Play Billing. One honest caveat specific to delivery: charging for physical food itself is a real-world payment, which Apple and Google permit through an external processor (Stripe-style), and that processor is the one piece you bring — the kit gives you the cart, order, and entitlement structure to plug it into.

• CartCubit with submitting/success/error states — no double-charges
• RevenueCat scaffolding for delivery-pass subscriptions or premium tiers
• Material 3 design tokens — rebrand every screen from one file
• FCM push wired for 'order confirmed' and 'driver on the way' notifications

When a different starting point is the honest choice

If your delivery business is fundamentally a logistics and dispatch platform — live courier routing, batched orders, surge pricing — most of that value lives in your backend, and any front-end starter is a small slice of the work. If you only need a single restaurant's ordering screen and have no Dart experience, a no-code builder like Adalo or Glide may get a v1 live faster, at the cost of source ownership and the clean architecture that survives feature growth. And if you are web-only with complex Stripe billing, a web stack is the more natural fit than a mobile-first RevenueCat kit. The Flutter Kit is the right call when you want a code-first, multi-platform delivery app you fully own, with the auth/cart/order/payment plumbing already done so you can focus on the menu and the market.

The Flutter Kit vs a generic Flutter template for delivery

Frequently Asked Questions