Flutter + Firebase Production Checklist

Firebase gets you to MVP fast.
It also gets you to production incidents fast if auth, security rules, and offline behavior were treated as "we will fix later."

This checklist is what I run through before any Flutter + Firebase app goes live — auth, Firestore rules, offline resilience, performance under load, and release readiness. It reflects patterns from production work, including eCommerce apps that scaled to 1M+ users and 20k+ daily transactions.

1. Authentication

Core flows

• Email/password, social login (Google, Apple), and guest/anonymous paths defined and tested
• Auth state persists correctly across app restarts
• Token refresh handled without forcing unnecessary re-login
• Sign-out clears local cached data where privacy requires it
• Account deletion flow implemented (required by Apple for apps with account creation)

Security

• No API keys or secrets in client code beyond Firebase's public config
• Custom claims used for role-based access when needed (admin, driver, etc.)
• Auth errors mapped to user-friendly messages — not raw Firebase exception strings

Production test

Sign in on a real device with airplane mode toggled mid-session. Auth should fail gracefully, not hang or crash.

2. Firestore Security Rules

This is the most common production gap. Default test rules or overly permissive rules have caused real data breaches.

Rules checklist

• Deny by default — every collection has explicit allow conditions
• Users can only read/write their own documents (request.auth.uid == resource.data.userId)
• Role-based rules use custom claims, not client-side flags
• Validation rules enforce required fields, types, and size limits on writes
• Subcollection rules inherit the same security model as parent documents
• Rules tested with the Firebase Emulator Suite — not just "looks fine in the console"

Data modeling review

• Documents sized for read efficiency (avoid unbounded arrays that grow forever)
• Indexes created for every compound query used in the app
• Pagination implemented — no "fetch entire collection" queries
• Hot paths (checkout, feed, dashboard) reviewed for read/write cost at scale

3. Cloud Functions and Server-Side Logic

• Sensitive operations (payments, admin actions, webhooks) run in Cloud Functions — not client code
• Functions have timeout and retry policies appropriate to the operation
• Idempotency handled for payment and order-processing functions
• Environment-specific config (staging vs. production) separated cleanly
• Function logs monitored — not discovered only when users report failures

4. Offline and Sync Behavior

Firebase gives you offline persistence, but persistence alone is not a product strategy.

• Offline behavior defined per feature: read-only cache vs. write queue vs. blocked
• Firestore offline persistence enabled with clear UX for pending writes
• Conflict resolution strategy documented (last-write-wins is fine if you know that is what you chose)
• Critical flows (checkout, booking, messaging) tested on 3G throttling and airplane mode
• Local SQLite or Hive used where Firestore offline is not sufficient (large media, complex queries)

For a deeper dive on patterns, see Building Offline-First Flutter Apps.

5. Performance

Client-side (Flutter)

• Widget rebuilds profiled on heaviest screens (catalog, chat, maps)
• Images cached and sized appropriately — no full-resolution loads in list views
• Lazy loading and pagination on all list-heavy screens
• Startup time measured on mid-range Android devices, not just your dev iPhone
• Memory leaks checked on navigation-heavy flows

Firebase-side

• Firestore queries use indexes; no collection scans in production paths
• Realtime listeners scoped narrowly — unsubscribe when screens dispose
• Cloud Storage uploads use resumable uploads for large files
• Analytics and Crashlytics integrated from day one of beta testing

Load testing mindset

Before a sale spike or launch campaign, ask: what happens when 10x normal traffic hits the checkout flow? On the Plum Goodness eCommerce app, we rebuilt checkout and Firestore access patterns specifically because sale spikes exposed gaps that demo testing never showed.

6. Push Notifications

• FCM token registration on login and refresh on token rotation
• Notification permissions requested at the right moment — not on first app open
• Deep links from notifications route to the correct screen
• Background notification handling tested on both iOS and Android
• Unsubscribe / notification preferences respected

7. Error Handling and Observability

• Firebase Crashlytics capturing Flutter framework and async errors
• Non-fatal errors logged with enough context to debug (user action, screen, API path)
• Analytics events for critical funnel steps (signup, checkout, feature activation)
• Remote Config or feature flags for risky features — kill switch without a store release
• On-call or alert path defined for crash rate spikes post-release

8. Architecture Alignment

Firebase apps outgrow "everything in the widget" faster than teams expect.

• Repository pattern separates Firestore/API calls from UI and business logic
• Domain layer does not import Firebase packages directly
• DTOs map Firestore documents to domain entities — backend shape changes stay isolated
• State management consistent across features (Bloc, Riverpod, or Provider — pick one dominant pattern)

If your codebase is already messy, Best Architecture for Scalable Flutter Apps outlines a progressive migration path without a full rewrite.

9. Environment and Release Hygiene

• Separate Firebase projects for dev, staging, and production
• .env or flavor-based config — no manual project switching before release
• CI builds signed artifacts for both stores
• Firestore rules deployed via CI, not pasted manually in the console
• Database backup and export strategy documented

10. Store Release Readiness

Firebase-specific store concerns:

• Privacy nutrition labels (Apple) and Data safety section (Google) match actual Firebase data collection
• Firebase Analytics, Crashlytics, and Auth disclosed accurately
• App Tracking Transparency handled if using analytics that require it
• Terms of service and privacy policy URLs live and referenced in store listings

Full store checklist: App Store + Play Store Release Checklist for Flutter Apps.

Quick Reference: Pre-Launch Gate

Need a Production Review?

If you are preparing a Flutter + Firebase app for launch and want an experienced set of eyes on architecture, security rules, or release readiness, I help startups get production apps across the line — not just MVPs that work on one device.

Review case studies for Firebase production work at scale, or see Flutter app development services for how I typically engage.