The Flutter Kit logoThe Flutter Kit
Boilerplate · E-Commerce

Flutter E-Commerce App Boilerplate

Catalog, cart, and payments scaffolding for a Flutter store app — built on BLoC, Firestore, and RevenueCat so you start at a working storefront instead of an empty main.dart.

Last updated: 2026-06-08 7 min read By Ahmed Gagan, Flutter Engineer
Quick Answer

The Flutter ecommerce app boilerplate from The Flutter Kit is a $69 one-time, production-ready Dart starter that ships catalog, cart, and payments scaffolding for a store app across iOS, Android, and Web from a single codebase. Product lists, detail screens, and a cart Cubit are wired with flutter_bloc and Firestore, while RevenueCat handles entitlement-based purchases for digital goods and unlocks. It is not a full physical-goods commerce platform with shipping, tax, and inventory engines — it is the app-layer scaffolding you'd otherwise spend weeks rebuilding.

Price
$69 one-time (was $149), unlimited stores
Store stack
BLoC/Cubit cart + Firestore catalog + RevenueCat
Platforms
iOS, Android, Web from one Dart codebase
Payments
RevenueCat entitlements (StoreKit 2 / Play Billing)

What 'catalog, cart, and payments scaffolding' actually means here

A store app is three problems stacked on top of each other, and most Flutter starters only solve zero of them. The Flutter Kit gives you the app-layer scaffolding for all three. Catalog: a Firestore-backed product collection with list and detail screens, image loading through Cloud Storage, and category filtering — driven by a ProductRepository so you can later point it at Supabase, Shopify Storefront, or your own API without touching the UI. Cart: a CartCubit holds line items, quantities, and a running subtotal as ValueObjects, so add-to-cart, quantity changes, and clear-cart are pure state transitions you can unit-test. Payments: RevenueCat wires the checkout for digital entitlements — a premium tier, a credit pack, a 'pro storefront' unlock — with restore, trials, and receipt validation already handled. You are editing real screens on day one, not scaffolding them.

Who this fits — and who should look elsewhere

This page exists for a specific kind of store. It fits if your commerce is digital or entitlement-based, or if you're building an MVP catalog-and-checkout to validate demand before committing to a heavy commerce backend. It does NOT fit if you need a full physical-goods platform on day one.

  • Great fit: digital products, content unlocks, credit packs, subscription storefronts, marketplace MVPs validating product-market fit
  • Great fit: teams who want BLoC + Firebase scaffolding now and will swap in a custom catalog API later
  • Reach for a real commerce backend instead: complex shipping zones, sales-tax calculation, multi-warehouse inventory, and returns — pair Flutter with Shopify, Medusa, or Stripe + a server
  • Not the goal: this is app-layer scaffolding, not an order-management or fulfillment system

How the store screens are wired

Every store surface follows the same repository + Cubit pattern the rest of The Flutter Kit uses, so a developer who learns the auth flow already understands the cart. Dependency injection via get_it makes the ProductRepository and CartCubit injectable and mockable, which matters when you write the inevitable 'cart total is wrong' test.

  • ProductRepository abstracts Firestore reads so the catalog source is swappable
  • CartCubit emits CartState with items, subtotal, and item count for badge UI
  • RevenueCat Offerings drive the checkout sheet; entitlements gate purchased content
  • Material 3 design tokens retheme the whole store from one file — brand colors, cards, buttons
  • go_router deep links route straight to a product detail screen for share/campaign links
  • GA4 events (view_item, add_to_cart, purchase) are stubbed for analytics from launch

Why start here instead of from scratch or FlutterFlow

Building a store app from an empty Flutter project means hand-rolling state management, a cart model, Firebase wiring, RevenueCat integration, and analytics before you've shown a single product — realistically two to four weeks of plumbing. FlutterFlow gets you a visual catalog fast, but a real cart with testable state, custom checkout logic, and full source ownership is where visual builders get awkward and you end up exporting anyway. The Flutter Kit's bet is that the catalog/cart/payments scaffolding is commodity work you shouldn't pay for twice: $69 once, you own every line of Dart, and you spend your weeks on the part that's actually your business — your products, your pricing, your conversion.

The Flutter Kit vs. building the store from scratch

The Flutter Kit vs Build from scratch comparison
FeatureThe Flutter KitBuild from scratch
Time to a working catalog + cartHours — screens & CartCubit included2–4 weeks of plumbing
Cart state managementflutter_bloc CartCubit, unit-testableYou design and test it
Payments wiringRevenueCat entitlements pre-integratedManual StoreKit 2 / Play Billing
Catalog backendFirestore via swappable ProductRepositoryWire Firebase or API yourself
iOS + Android + WebOne Dart codebase, all threeConfigure each target yourself
Source ownershipFull source, unlimited storesYours — but you wrote it all
Cost$69 one-timeYour engineering time

Frequently Asked Questions

Does this Flutter ecommerce boilerplate handle physical-goods shipping and tax?
No, and we won't pretend it does. The scaffolding covers catalog, cart, and payments at the app layer. Shipping zones, sales-tax calculation, and inventory are backend concerns — pair the kit with Shopify, Medusa, or Stripe plus a server if you sell physical goods. The cart and product screens still save you weeks regardless of the backend.
Can I use Stripe instead of RevenueCat for the store checkout?
RevenueCat ships wired for in-app digital entitlements (StoreKit 2 on iOS, Play Billing on Android), which is the right tool for digital products and unlocks. Because you own the full source, you can add Stripe for web or physical-goods checkout via its Flutter SDK — see our Stripe-alternative-for-Flutter notes for the trade-offs around app-store policy.
How is the cart state actually structured?
A CartCubit (from flutter_bloc) holds the line items, quantities, and a running subtotal, emitting a CartState the UI listens to for the cart badge and totals. It's injected via get_it, so add-to-cart, quantity updates, and clear-cart are pure, testable state transitions rather than setState spaghetti.
Is the product catalog locked to Firestore?
No. The catalog reads through a ProductRepository abstraction, so Firestore is the default but swappable. You can repoint it at Supabase, a headless commerce API, or your own backend without rewriting the list and detail screens — the UI depends on the repository interface, not the data source.
Can one store app target iOS, Android, and Web?
Yes — the entire kit, including the store screens, builds for iOS, Android, and Web from one Dart codebase. RevenueCat purchases run natively on iOS and Android; for Web checkout you'd typically swap in a web payment provider since app-store billing is mobile-only.
Is this a marketplace boilerplate with multiple sellers?
Not out of the box — it's a single-store catalog/cart/payments scaffold. It's a strong starting point for a marketplace MVP, but multi-seller payouts, seller dashboards, and commission splits are features you'd build on top. If that's your core product, budget for that backend work beyond the app layer.

Keep exploring

Start at a working storefront, not an empty main.dart

Get the catalog, cart, and RevenueCat payments scaffolding for your Flutter store app — $69 one-time, full source, unlimited projects, iOS/Android/Web from one Dart codebase.

Get The Flutter Kit — $69

One-time purchase · Lifetime updates · Unlimited projects