MVVM + Provider + Appwrite — When Simplicity Beats Scale

MVVM + Provider + Appwrite is the simple path. FlutterInit puts models/repos under lib/src/data and screens under lib/src/ui, wires Provider (or Riverpod) auth notifiers, and points AuthService at Appwrite’s Account API. You ship faster; you accept less layer theater.

What This Stack Generates

• lib/src/data/models + lib/src/data/repositories
• lib/src/ui/auth (screens + providers/ for Provider)
• lib/src/ui/home, lib/src/ui/onboarding
• Appwrite client + Account in AppConfig (APPWRITE_ENDPOINT, APPWRITE_PROJECT_ID)
• go_router + AI context files

Project Structure

Provider as the “ViewModel”

Generated auth uses a ChangeNotifier-style provider that calls the repository and navigates on success. Screens listen with context.watch / Consumer. No event classes unless you want them later.

Appwrite specifics

Appwrite auth doesn’t expose the same stream model as Firebase/Supabase. FlutterInit’s Appwrite AuthService uses Account email sessions and a manual StreamController for auth state. That detail matters when you write session listeners — don’t assume authStateChanges is SDK-native.

When simplicity loses

Move toward Clean + Bloc + Appwrite or Feature-First + Bloc + Supabase when multiple teams touch the same features and you need stricter boundaries.

Practical MVVM walkthrough: MVVM in Flutter. Backend comparison: Appwrite vs Firebase vs Supabase.

Generate this stack on /create.