The Flutter SaaS Boilerplate Built Around Recurring Revenue
Multi-tier subscriptions, entitlement gating, and account state — wired end to end in BLoC so your SaaS bills before your trial ends. iOS, Android, and Web from one Dart codebase.
The Flutter SaaS boilerplate is a $69 one-time Flutter (Dart) starter built around the part of SaaS that actually pays the bills: recurring revenue. It ships RevenueCat multi-tier subscriptions, trials, and restore, plus an entitlement layer that gates features by plan and an account-state Cubit that survives login, logout, and plan changes. You own the full source, ship to iOS, Android, and Web from one codebase, and get lifetime updates — no subscription, no per-seat fee.
A SaaS lives or dies on its recurring-revenue backbone
Most boilerplates treat payments as a single 'unlock pro' button. A real SaaS is more demanding: a user can be on Free, Pro, or Team; mid-cycle they upgrade, downgrade, hit a trial, churn, or restore on a second device — and your UI has to reflect the truth in every one of those states. The Flutter Kit's SaaS angle is that backbone. RevenueCat models your tiers as offerings and packages, and a dedicated entitlement layer answers one question everywhere in the app: what is this account allowed to do right now? That answer flows through a Cubit, so a downgrade or an expired trial repaints gated screens without you hand-threading booleans through widgets.
- Multiple tiers as RevenueCat offerings (Free / Pro / Team), not a single boolean
- Trials, intro offers, restore, and proration handled by StoreKit 2 and Play Billing
- Entitlement checks centralized — one source of truth, not scattered `if isPro` flags
- Account state survives login, logout, plan switch, and reinstall
How subscription state is wired in Dart
The kit uses flutter_bloc with Cubits and dependency injection through get_it, so subscription logic is testable and lives outside your widgets. On launch, RevenueCat's CustomerInfo is fetched and mapped to an EntitlementState; a Cubit exposes the active tier and a set of capabilities. Widgets read that state reactively, so when RevenueCat fires a customer-info update — a renewal, an upgrade, a billing lapse — gated UI rebuilds automatically. Firebase Auth ties the RevenueCat app user ID to your real account so entitlements follow the human across devices, and Cloud Functions give you a server-side seam for receipt webhooks if you need to grant access in Firestore for web or cross-platform reads.
- RevenueCat CustomerInfo → EntitlementState mapping done once, reused everywhere
- Cubit + get_it keeps billing logic out of the widget tree and unit-testable
- Firebase Auth links app user ID so entitlements follow the account, not the device
- Cloud Functions hook for webhooks when web or backend needs to read plan status
What you skip versus building the billing layer yourself
The unglamorous SaaS bugs are the expensive ones: a user who restored on a new phone but still sees the paywall, a downgraded customer who keeps Team features until next launch, a trial that never converts because the entitlement didn't refresh. The kit ships those edge cases already handled — restore flows, plan-change repaints, trial-state UI, and a settings screen where users can see and manage their subscription. Material 3 theming with centralized design tokens means your pricing and paywall screens match your brand by editing one file. GA4 with consent management is wired in so you can actually watch trial-to-paid conversion instead of guessing. AI (OpenAI streaming chat, Vision, DALL·E via a Flask proxy) is a feature-flagged module — if your SaaS is AI-powered you flip it on, if not it stays out of your bundle.
When a different starting point is the honest choice
If your product is a one-time purchase or fully free, the recurring-revenue backbone is weight you don't need — a lighter starter or the open-source Very Good CLI scaffold may suit you better. If your billing is genuinely web-first and complex (usage-based metering, seats, invoices), Stripe on a web stack is the mature path, and this kit's RevenueCat-centric, mobile-first model will fight you. If you have zero Dart experience and want to click your UI together, FlutterFlow gets you moving faster up front — though you trade away the source ownership and clean BLoC architecture that make a SaaS maintainable past month three. The Flutter Kit is the right call when you want a code-first, subscription-driven mobile SaaS you fully own and can ship to three platforms from day one.
The Flutter Kit vs building the billing layer yourself
| Feature | The Flutter Kit | Build from scratch |
|---|---|---|
| Price | $69 one-time, unlimited projects | Your engineering time (weeks) |
| Multi-tier subscriptions | RevenueCat offerings pre-wired | Hand-roll StoreKit 2 + Play Billing |
| Entitlement gating | Centralized EntitlementState + Cubit | Scattered booleans, easy to drift |
| Restore & plan changes | Handled, with reactive UI repaint | Common source of edge-case bugs |
| Account state across devices | Firebase Auth ↔ RevenueCat app user ID | You design the linking yourself |
| Source ownership | Full source, lifetime updates | You own it (and maintain it all) |
| Platforms | iOS, Android, Web — one codebase | Per-platform billing plumbing |
Frequently Asked Questions
How does the kit handle a user who upgrades from Pro to Team mid-cycle?
Can I run more than two pricing tiers, like Free, Pro, and Team?
What happens to entitlements when a subscriber reinstalls or switches phones?
My SaaS bills on the web too — does this cover that?
Is the AI module required for a SaaS build?
Can I track trial-to-paid conversion out of the box?
Keep exploring
Ship a subscription SaaS, not a payments to-do list
Start with the recurring-revenue backbone already wired — multi-tier subs, entitlement gating, and account state in BLoC. $69 one-time, full source, lifetime updates, iOS + Android + Web from one Dart codebase.
Get The Flutter Kit — $69One-time purchase · Lifetime updates · Unlimited projects