Flutter + Firebase for SaaS Mobile Apps in 2026

A Flutter and Firebase SaaS stack gives you one Dart codebase across six platforms and a backend you never provision. It leaves two problems that stay hard: tenant isolation and billing. If you're about to start, your first action is to open your data model and ask how many documents would have to move if you onboarded a second tenant tomorrow.

I've been building that stack on BookBed, the property management SaaS I built solo, since October 16, 2025. The same Dart code targets iOS, Android, Web, macOS, Linux and Windows, Firebase holds the data and Stripe takes the payment. This post covers what a Flutter Firebase SaaS stack contains, where Firebase bills you, the one architectural decision you can't undo, and the platform changes of the last twelve months that older Flutter SaaS advice hasn't caught up with. Every price below was checked on the vendor's own page on 30 September 2026.

What Does a Flutter + Firebase SaaS Stack Include?

A production Flutter and Firebase SaaS needs six layers: auth with tenant claims, a tenant-scoped datastore, server-side functions, a billing broker, message delivery, and crash telemetry. Miss one and it shows up as an incident instead of a missing feature.

• Auth. Firebase Authentication with a custom claim on the token naming the tenant. If a third-party social login is your primary sign-in on iOS, Apple's App Review Guidelines (4.8) require an equivalent login option that limits data collection to name and email and lets users keep their email private. Sign in with Apple is the usual way to meet that, so plan it before review, not during. BookBed offers Apple and Google Sign-In.
• Data. Cloud Firestore for document-shaped data, or Firebase SQL Connect when the domain is relational.
• Server. Cloud Functions for every webhook, privileged write and claim mutation. The client should never write its own subscription status. That's a design rule I hold, not a Firebase requirement.
• Billing. RevenueCat, Stripe, or both.
• Delivery. Firebase Cloud Messaging for push, plus a transactional email provider. BookBed runs eighteen-plus Resend email templates alongside FCM push notifications.
• Telemetry. Crashlytics, which Firebase's pricing page lists at no cost on both Spark and Blaze. Without it, a crash on a device you don't own is invisible.

State management is deliberately missing from that list. Riverpod, Bloc and Provider are all workable, and in my view none of them decides whether a SaaS succeeds.

Firestore, SQL Connect or Supabase for a Firebase SaaS Backend?

Choose Firestore when your data is document-shaped and your queries are known in advance, and SQL Connect when you need joins, aggregates or window functions. Supabase is the third option if you're willing to leave the Firebase console.

The question is live again because Firebase Data Connect became Firebase SQL Connect at Cloud Next on April 29, 2026. The Firebase blog lists realtime query subscriptions through an @refresh directive, query-level and entity-level offline caching, and raw SQL inside .gql operation files. Operations cost $0.90 per million from May 1, with 250,000 free a month on Blaze.

The Firestore quotas come from Firebase pricing, and the Supabase figures from Supabase pricing. The number that catches people is reads, not writes. A dashboard rendering forty bookings costs forty reads every time someone pulls to refresh, and a 50,000-a-day allowance goes quickly once a handful of tenants develop a refresh habit. For a side-by-side view, see the Supabase vs Firebase comparison.

Why Can't You Retrofit Multi-Tenancy?

Put the tenant ID in the document path before you write the first screen, because moving it there later means migrating every document, index, rule and query at once.

Firebase's rules and auth guide documents the mechanism: custom claims are read in Security Rules through the auth.token variable, for example request.auth.token.admin == true. For a tenant boundary that becomes a tenant_id claim compared against the tenant segment of the path.

The subtle part is queries. Firestore's rules and queries docs say "Rules are not filters—queries are all or nothing": if a query could return documents the client can't read, the whole request fails, because it's checked against the potential result set. So a collectionGroup query that spans tenants is rejected unless it carries the same constraint the rule enforces.

The consequence is that the tenant ID has to live in the query as well as the rule, which means in the path or an indexed field, which means the decision is made at schema-design time and enforced by every read you ever write. The cost of getting it wrong arrives later: the day you add a cross-tenant admin screen, reach for collectionGroup because nothing else works, and write a rule to permit it that is broader than the one it replaced.

Do You Need RevenueCat for a Flutter Subscription App?

RevenueCat earns its place when you sell on both the App Store and Google Play, because cross-store receipt validation and subscription state is a backend product you would otherwise build yourself.

Its pricing page lists nothing to pay up to $2,500 in monthly tracked revenue, then 1% of tracked revenue. Check any RevenueCat number you read elsewhere against that page, since comparison posts age quickly.

The platform column comes from the in_app_purchase and purchases_flutter package listings. It's the row that decides your architecture: neither package lists Linux or Windows, and a Flutter product on those targets has surfaces they don't cover. BookBed bills through Stripe, with cross-tab checkout resolved by a BroadcastChannel listener and a Firestore listener as the fallback, and webhook writes keep account type in step with subscription status, per the BookBed case study. The Flutter, Firebase and RevenueCat stack page and the RevenueCat paywall post cover the mobile-only path where one system is enough.

One number before you build any of it. RevenueCat's State of Subscription Apps 2026, covering more than 115,000 apps and over $16 billion in revenue, puts the global median download-to-paid conversion within 35 days at 2.0%, and finds that only 4.6% of newly launched apps reach $10,000 a month within two years. Build the billing layer that fits the median outcome first, and earn the complicated one.

What Does the App Store Fee Fight Mean for Billing?

It means your web checkout may be worth keeping flexible, because the fee on US link-outs to it is still being decided. Apple's guidelines currently say US-storefront apps need no entitlement to include external purchase links.

The court sequence matters if you're pricing a subscription now. The district court barred Apple from charging commission on linked purchases after finding it had violated an injunction. On December 11, 2025, the Ninth Circuit upheld the core injunction but vacated the blanket commission ban and sent the rate back to the district court, to cover necessary costs plus some compensation for intellectual property. In June 2026 the Supreme Court agreed to hear Apple's challenge to the contempt ruling. I couldn't confirm what rate, if any, applies today.

My recommendation: if your web checkout exists anyway because you ship to desktop and browser, a US link-out is cheap to add and can sit behind a config flag. If mobile is your only surface, don't build a web billing stack on the assumption that today's terms survive the ruling.

What Flutter Firebase Architecture Should You Wire Up First?

Start with tenant boundaries and server-owned writes, then billing, then links. That order matches how expensive each mistake is to reverse.

1. Create the Firebase project and write Security Rules before the first screen: tenant ID in the path, custom claim on the token, and emulator tests proving a second tenant is denied.
2. Model documents as tenants/{tenantId}/... even with exactly one tenant. Especially then.
3. Route every privileged write through a Cloud Function: subscription status, tenant claims, invitations. The client proposes; the function decides.
4. Add RevenueCat for mobile-only, Stripe for web or desktop, both if you have both. Reconciliation between them is a standing job, so name an owner.
5. Configure apple-app-site-association and assetlinks.json on day one, before anyone has a link to share.
6. Turn on Crashlytics before the first TestFlight build.

Why Do Deep Links Need Setup on Day One?

Firebase Dynamic Links shut down on August 25, 2025. The Dynamic Links FAQ says users clicking existing links get an HTTP 404 and that domain and link metadata was marked for deletion on that date, with no grace period.

App Links and Universal Links cover the installed-app case through platform configuration alone. When the app isn't installed you need deferred deep linking, which now means a third-party service. Installed-app deep linking can't wait a week; deferred linking can wait a quarter.

The tooling around all of this is deliberately boring, and my Flutter dev tools list is short. If you're building a template instead of a platform, the FlutterFlow marketplace templates run on a different economics entirely. And if you're unsure whether this is a SaaS product or a one-off app, settle that first, because the tenancy model follows from the answer.

The BookBed case study describes a booking calendar repository of 989 lines carrying deliberate duplication marked "do not refactor without unit tests," because the duplication came from bugs solved one at a time. That is what a Flutter and Firebase SaaS looks like once it has been alive long enough to have scars.

Open your Firestore data model and answer one question: if you onboarded a second tenant tomorrow, how many documents would have to move? Any answer above zero is your next sprint. And what does your app's download-to-paid conversion look like against that 2.0% median?