Scaffolding

One command from nothing to a running Flutter app with a real signed-in user — properly architected, and already talking to your Koolbase project.

koolbase create

koolbase create my_app

Runs flutter create, then replaces lib/ with an opinionated architecture and authentication screens wired to your project. You are asked which Koolbase project to use — or you can create one from the picker, so nothing here requires a trip to the dashboard.

cd my_app
flutter run

The app opens on a sign-in screen. Register, and you are signed in against your own Koolbase project — a real user, in your real backend, in about two minutes.

The code is yours the moment it lands. Edit it, restructure it, or throw the architecture away entirely. Nothing tracks it and nothing upgrades it — this is a starting point, not a framework you are now inside.

What gets generated

Feature-first, with Riverpod and go_router. One opinion, chosen so the result is what a senior Flutter developer would have written rather than a counter app with a backend bolted on:

lib/
├── app/
│   ├── app.dart              MaterialApp.router, theme
│   ├── router.dart           go_router config, route registry
│   ├── bootstrap.dart        Koolbase.initialize, ProviderScope
│   └── koolbase_config.dart  your project id and public key
├── core/
│   ├── koolbase/             SDK providers (auth state, accessors)
│   ├── theme/
│   └── widgets/              shared presentation
└── features/
    └── auth/
        ├── data/repositories/    the ONLY place the SDK is called
        ├── application/          Riverpod providers and notifiers
        ├── presentation/         screens and widgets
        └── auth_routes.dart      routes this feature contributes

Two details worth knowing, because they are what make the structure hold up:

•Repositories own every SDK call. Providers and widgets never touch Koolbase.db directly, so a feature is testable and renaming a collection is a one-file change.

•Each feature declares its own routes. app/router.dart imports and spreads them, so adding a feature is one import — never a rewrite of your router.

Authentication is always generated: sign in, register, and password reset behind KoolbaseAuthGate, which restores a persisted session before the first frame so returning users never see a login flash.

One command to run afterwards. The native splash is configured to match your theme, so launch is one continuous surface rather than a white flash. Generating it writes into your Android and iOS projects — which the CLI deliberately does not touch — so run it yourself once: dart run flutter_native_splash:create. Add your own image to the config and re-run it whenever you change it.

Flavors

koolbase create my_app --flavors

Generates one entrypoint per environment, each passing its own configuration:

flutter run                              # development
flutter run -t lib/main_staging.dart     # staging
flutter run -t lib/main_production.dart  # production

Entrypoints rather than --dart-define because which backend a build talks to should be visible in the file you ran. If your project is missing an environment, you are asked before any is created — environments count against your plan.

Dart-side only. Android product flavors and iOS schemes are yours to add if you need separate bundle identifiers or icons per environment — the CLI does not edit your gradle or Xcode project.

Templates

Templates add a complete capability — screens and the code behind them — to a project. They are free, and they always will be.

koolbase create my_app --template chat   # with a new app
koolbase add chat                        # into an app you already have

koolbase add reads your package name from pubspec.yaml and your Koolbase project from the generated config, so it needs no arguments inside an app create made. Elsewhere, pass --project.

Existing files are never overwritten silently: a collision lists exactly what would be replaced and stops. --force proceeds.

Pin a version when you need the same source every time — a published version is never replaced, so a pinned build is reproducible indefinitely:

koolbase add [email protected]

Every template is verified before it is installed. Bundles are checked against their published digest and their signature, and cached locally so a second install needs no network. A template that fails either check is refused rather than written into your project.

Requirements

Flutteron your PATH

Koolbase accountkoolbase login

Dashboardnot required

Commands

AI Assistant