Stack Configuration — what FlutterInit generates for this guide
Architecture
MVVM
State Management
Provider
Backend
When to choose this stack
Choose this stack when you're learning Flutter, shipping with a small team, or want less ceremony than Clean Architecture. Provider's ChangeNotifier model is easy to teach, MVVM's data/ui split is enough structure for most apps under ~20 screens, and Firebase Auth email-password gets you signed-in users without standing up a backend.
Ready to build?
Generate this project in seconds
FlutterInit scaffolds the entire structure described in this guide — wired up, typed, and ready for flutter run.
Provider + MVVM + Firebase is the beginner-friendly Flutter stack: ChangeNotifier ViewModels, a flat data / ui split, and Firebase email-password auth. You get structure without Clean Architecture's three-layer tax. FlutterInit wires the folders, provider package, go_router redirects, and Firebase Auth for you.
What This Stack Generates
Select Provider + MVVM + Firebase and you get:
MVVM layout — lib/src/data for models/repos, lib/src/ui for screens and providers
Provider — AuthProvider / SessionProvider as ChangeNotifiers
go_router — auth-aware redirects between login and home
No use-case classes. No domain entities folder. The repository interface lives next to its Firebase-backed impl under data/.
Project Structure
Understanding Each Layer
Data — Models and Repositories
MVVM here is two folders, not three Clean layers. data/ owns the user model, the repository contract, and the Firebase-backed implementation.
The impl talks to AuthService, which wraps Firebase Auth — screens never import firebase_auth directly.
Firebase Auth — Email and Password
AuthService is the thin SDK edge. Email-password is the default pattern FlutterInit wires:
You still drop in google-services.json (Android) and GoogleService-Info.plist (iOS) per SETUP.md. Firebase initializes once in AppConfig.init().
UI — Provider as the ViewModel
In this stack, the "ViewModel" is a ChangeNotifier registered with the provider package. Login calls go through AuthProvider; session listening lives in SessionProvider.
In the screen: context.watch<AuthProvider>() in build, context.read<AuthProvider>() in button callbacks. That's the whole mental model.
Navigation with go_router
Auth redirects watch the session stream. Unauthenticated users land on login; authenticated users skip auth screens and go home. Same pattern as the other FlutterInit stacks — only the state glue changes.
When to Choose This vs Alternatives
Pick Provider + MVVM + Firebase when:
You're a beginner or onboarding juniors — ChangeNotifier is the easiest Flutter state story to teach
The app is small-to-medium and you don't need feature-sliced Clean folders yet
You want Firebase Auth without inventing your own backend
Skip it when:
You need strict domain isolation for a large team — use Clean Architecture instead
Open the dashboard, pick MVVM + Provider + Firebase + go_router, and download a project with this exact shape — folders, auth flow, and pubspec.yaml already wired.