Flutter On-Demand App Boilerplate

Every on-demand app is the same four pieces

Strip away the branding and a rideshare, a home-cleaning app, and a dog-walking app share one spine: a user with an account, a request they create, a payment that settles it, and push notifications that keep both sides informed. The Flutter Kit ships that spine so you don't rebuild it per vertical. Firebase Auth handles accounts (including role-aware buyer/provider context), a request lifecycle is modeled as streamable Firestore documents, RevenueCat covers the digital monetization layer, and FCM handles the notifications. It all lives in BLoC/Cubit with get_it, so the reusable core is testable and your vertical logic plugs into clean seams.

• Accounts with optional requester/provider roles
• Request lifecycle: requested → accepted → in-progress → completed
• Real-time status via streamable Firestore documents
• FCM push so both sides see updates the moment they happen

The request lifecycle, concretely

The heart of an on-demand app is a request that two parties watch change. The kit models it as a Firestore document with an explicit status, exposed as a stream a Cubit subscribes to — so when a provider accepts, the requester's screen updates live, and when the job completes, both sides transition together. This is the same plumbing for a ride being accepted, a cleaner being dispatched, or an errand being claimed; only the fields differ. Because it is behind a repository in get_it, your dispatch logic (a Cloud Function, a backend matcher) writes to the same document the app already streams.

class RequestCubit extends Cubit<RequestState> {
  RequestCubit(this._repo) : super(const RequestIdle());
  final RequestRepository _repo;
  StreamSubscription? _sub;

  Future<void> create(ServiceRequest req) async {
    final id = await _repo.submit(req); // status: requested
    _sub = _repo.watch(id).listen((r) {
      emit(RequestUpdated(r)); // accepted -> inProgress -> completed
    });
  }

  @override
  Future<void> close() { _sub?.cancel(); return super.close(); }
}

Payments and push for the on-demand model

On-demand apps have two money paths, and it helps to be precise. RevenueCat — wired here with trials, restore, and entitlements — is the right tool for digital monetization: a membership, a priority tier, or unlocking premium service, all StoreKit 2 / Play Billing compliant. Paying a provider for a real-world service (a ride, a cleaning) is an external-processor transaction the stores permit; the kit gives you the request, account, and entitlement structure to attach that processor. On the notification side, FCM and local notifications are wired with a diagnostics screen, so 'your provider is on the way' and 'job complete' pushes are about triggering, not plumbing.

• RevenueCat for memberships, priority tiers, premium unlocks
• Real-world service payments via an external processor you connect
• FCM push for accept/dispatch/complete events on both sides
• Material 3 design tokens — rebrand the whole app from one file

When a different starting point is the honest choice

On-demand businesses live or die on supply-side logistics — matching, routing, dispatch, surge — and most of that value is in your backend, not any front-end starter; a boilerplate gives you the client core, not the marketplace dynamics. If your specific vertical already has a tighter-fitting template (a pure food-delivery or booking starter), begin there instead of the generic core. If you have no Dart experience and need to test demand with a concierge MVP, a no-code tool or even manual coordination may validate the idea before you build an app at all. The Flutter Kit's on-demand base is the right call when you want a code-first service app you fully own, with the account + request + payment + push core already wired so you can pour your effort into the matching and the market.

The Flutter Kit vs building an on-demand core yourself

Frequently Asked Questions