AppScaffold.
Start building
HomeFlutter Project Generator
Your stack. Your starting point.

Flutter Project Generator

Choose your architecture, pick your tools, and get a clean starter project.
Everything is generated in your browser. Nothing is uploaded.

Read generated source · Compare presets · First-run walkthrough

FREE · NO SIGNUP · INSTANT ZIP
Start with a preset

01The basics

Give your next project a name and a home.

Lowercase letters, numbers, and underscores.
For example, com.example
stable or a custom version, e.g. 3.38.0
Target platforms

02Architecture & state

Choose the boundaries that fit your application.

Recommended for complex domains. Domain contracts stay independent of UI and data implementations.

03Networking & storage

Connect your services. Keep your data layer organized.

Networking options

04Make it your own

Useful foundations without unnecessary dependencies.

Additional features
Starter screens
Inspect the code before choosing your stack

What changes with another preset?

Compare the files your current form will download with another preset. Both sides use your project name, package and description. The preset uses its own remaining settings; this comparison does not change your form.

1 added · 3 removed · 5 changed · 14 unchanged files, relative to your current configuration.

Configuration differences (2)
state
Current: BLoC
Clean + Riverpod: Riverpod
di
Current: GetIt
Clean + Riverpod: Riverpod DI

changed · README.md

Current configuration

# my_flutter_app

A thoughtfully structured Flutter application.

## Configuration
- Platform: flutter
- Architecture: Clean Architecture
- Package / organization: com.example
- State / async: BLoC
- Networking: Dio
- Navigation: GoRouter
- Dependency injection: GetIt
- Storage: None
- Features: Theme setup, Dark mode, Result/Failure wrapper
- Screens: Home, Settings

## Getting started
1. Install Flutter stable and verify with `flutter doctor` (Dart constraint: >=3.8.0 <4.0.0).
2. From this directory, create SDK-owned platform runners: `flutter create --org com.example --project-name my_flutter_app --platforms android,ios .`. If prompted, keep the supplied lib/, test/, and pubspec.yaml files. Back them up before running the command. The ZIP deliberately contains source/configuration, not SDK-generated native runners.
3. Run `flutter pub get`.
5. Run `flutter run`. To configure an API: `flutter run --dart-define=API_URL=https://your-api.example/`.
6. Test with `flutter test` and inspect with `flutter analyze`.

## Architecture and extension points
The application composition root owns concrete repositories. Presentation accepts domain abstractions. The in-memory counter repository is a working demo; replace it with a network or storage implementation through the composition root. Put business rules in domain/usecases, implementation details in data, and UI in presentation. Domain must not import UI or data.

Add features alongside existing feature folders, then register routes. Services are initialized in the dependency container; no requests are sent on startup. API endpoints are placeholders. Logging should stay in debug builds and must not contain credentials. Authentication screens are mock entry points, not a real sign-in system. Connect the AuthRepository and add validation before collecting user credentials.

## Integration notes
- Review dependency versions before adopting this starter. The website centralizes them in src/config/versions.ts.
- Package plugins may require extra platform permissions. Consult each selected package before release.
- Add real API tests, accessibility tests, and release signing in your project. No release credentials are generated.
- Starter code is not a security audit or a guarantee of production readiness.

## Dependencies
- flutter_bloc: ^9.1.1
- dio: ^5.8.0+1
- get_it: ^8.0.3
- go_router: ^16.0.0

## Folder structure
```text
├── lib
│   ├── core
│   │   ├── dependency_injection
│   │   │   └── container.dart
│   │   ├── network
│   │   │   ├── api_client.dart
│   │   │   └── network_failure.dart
│   │   ├── routes
│   │   │   └── app_router.dart
│   │   ├── theme
│   │   │   └── app_theme.dart
│   │   └── utils
│   │       └── result.dart
│   ├── data
│   │   └── repositories
│   │       └── memory_counter_repository.dart
│   ├── domain
│   │   └── repositories
│   │       └── counter_repository.dart
│   ├── features
│   │   ├── home
│   │   │   ├── domain
│   │   │   │   └── usecases
│   │   │   │       └── increment_counter.dart
│   │   │   ├── presentation
│   │   │   │   └── pages
│   │   │   │       └── home_page.dart
│   │   │   └── state
│   │   │       ├── counter_bloc.dart
│   │   │       ├── counter_event.dart
│   │   │       └── counter_state.dart
│   │   └── settings
│   │       └── presentation
│   │           └── pages
│   │               └── settings_page.dart
│   ├── app.dart
│   └── main.dart
├── test
│   └── counter_repository_test.dart
├── .gitignore
├── analysis_options.yaml
├── pubspec.yaml
└── scaffold.json
```

Generated entirely in your browser. No configuration or source was uploaded.

Clean + Riverpod

# my_flutter_app

A thoughtfully structured Flutter application.

## Configuration
- Platform: flutter
- Architecture: Clean Architecture
- Package / organization: com.example
- State / async: Riverpod
- Networking: Dio
- Navigation: GoRouter
- Dependency injection: Riverpod DI
- Storage: None
- Features: Theme setup, Dark mode, Result/Failure wrapper
- Screens: Home, Settings

## Getting started
1. Install Flutter stable and verify with `flutter doctor` (Dart constraint: >=3.8.0 <4.0.0).
2. From this directory, create SDK-owned platform runners: `flutter create --org com.example --project-name my_flutter_app --platforms android,ios .`. If prompted, keep the supplied lib/, test/, and pubspec.yaml files. Back them up before running the command. The ZIP deliberately contains source/configuration, not SDK-generated native runners.
3. Run `flutter pub get`.
5. Run `flutter run`. To configure an API: `flutter run --dart-define=API_URL=https://your-api.example/`.
6. Test with `flutter test` and inspect with `flutter analyze`.

## Architecture and extension points
The application composition root owns concrete repositories. Presentation accepts domain abstractions. The in-memory counter repository is a working demo; replace it with a network or storage implementation through the composition root. Put business rules in domain/usecases, implementation details in data, and UI in presentation. Domain must not import UI or data.

Add features alongside existing feature folders, then register routes. Services are initialized in the dependency container; no requests are sent on startup. API endpoints are placeholders. Logging should stay in debug builds and must not contain credentials. Authentication screens are mock entry points, not a real sign-in system. Connect the AuthRepository and add validation before collecting user credentials.

## Integration notes
- Review dependency versions before adopting this starter. The website centralizes them in src/config/versions.ts.
- Package plugins may require extra platform permissions. Consult each selected package before release.
- Add real API tests, accessibility tests, and release signing in your project. No release credentials are generated.
- Starter code is not a security audit or a guarantee of production readiness.

## Dependencies
- flutter_riverpod: ^3.0.0
- dio: ^5.8.0+1
- go_router: ^16.0.0

## Folder structure
```text
├── lib
│   ├── core
│   │   ├── dependency_injection
│   │   │   └── container.dart
│   │   ├── network
│   │   │   ├── api_client.dart
│   │   │   └── network_failure.dart
│   │   ├── routes
│   │   │   └── app_router.dart
│   │   ├── theme
│   │   │   └── app_theme.dart
│   │   └── utils
│   │       └── result.dart
│   ├── data
│   │   └── repositories
│   │       └── memory_counter_repository.dart
│   ├── domain
│   │   └── repositories
│   │       └── counter_repository.dart
│   ├── features
│   │   ├── home
│   │   │   ├── domain
│   │   │   │   └── usecases
│   │   │   │       └── increment_counter.dart
│   │   │   ├── presentation
│   │   │   │   └── pages
│   │   │   │       └── home_page.dart
│   │   │   └── state
│   │   │       └── counter_provider.dart
│   │   └── settings
│   │       └── presentation
│   │           └── pages
│   │               └── settings_page.dart
│   ├── app.dart
│   └── main.dart
├── test
│   └── counter_repository_test.dart
├── .gitignore
├── analysis_options.yaml
├── pubspec.yaml
└── scaffold.json
```

Generated entirely in your browser. No configuration or source was uploaded.

These are complete file contents from the same templates as the ZIP, not a line-by-line patch or a migration tool. Compare dependency manifests, state owners and setup instructions together. A smaller file count is not a quality score, and this preview does not compile either project.

Review the output before your first commit

Compare Clean + BLoC with Clean + Riverpod above. Inspect pubspec.yaml for dependency changes, then compare counter_bloc.dart with counter_provider.dart and trace the repository access in each. The comparison holds your name and package constant but also changes dependency injection to match the preset. It is not an isolated benchmark of the state libraries. Review the generated README before running platform setup.

Your Flutter starter includes an application entry point, navigation, working state examples, selected service integrations, and an architecture-aware README. The composition root connects concrete services to repository contracts, so you can add your own backend without coupling it to the screens.

Choose the right level of structure

Start simple for a prototype, organize by feature as the app grows, or use Clean Architecture when business rules need independent tests. BLoC, Riverpod, GetX, Cubit, and Provider give you different ways to own screen state.

After you download

Read the included README, install the listed SDK tooling, and run the starter tests. API URLs and authentication repositories are placeholders for your own services. Code-generation integrations have explicit local build commands.

Read the architecture guide →

From download to first run

This walkthrough uses the Clean + BLoC preset. Select that preset to reproduce it. Other configurations can require additional steps; the README in your download is specific to your choices.

1. Check the configuration and prerequisites

Use project name my_flutter_app, organization com.example, Clean Architecture, BLoC, Dio, GetIt, GoRouter, and no database. Install a Flutter SDK whose Dart version satisfies >=3.8.0 <4.0.0.

These are the configured template requirements, not a claim of compatibility with every SDK release. The validation record lists the SDKs and combinations previously checked.

2. Inspect the archive before running commands

Generate the ZIP, extract it, and open a terminal inside the folder containing README.md. Preview the source tree in the generator before downloading. The default configuration currently produces 22 files, including the following entry points:

3. Set up and run the starter

Keep a backup of the downloaded lib/, test/, and pubspec.yaml before creating native runners. Keep or restore those supplied files if platform generation changes them. Run these commands from the extracted project root.

flutter doctor
flutter create --org com.example --project-name my_flutter_app --platforms android,ios .
flutter pub get
flutter analyze
flutter test
flutter run

flutter run lets you choose an available target. The home screen should show Counter: 0; pressing Increment once should show Counter: 1. No backend is needed for this example.

4. Understand what the included test proves

test/counter_repository_test.dart is generated with this preset:

import 'package:flutter_test/flutter_test.dart';
import 'package:my_flutter_app/data/repositories/memory_counter_repository.dart';
void main() { test('repository retains counter value', () async { final repository = MemoryCounterRepository(); expect(await repository.load(), 0); await repository.save(3); expect(await repository.load(), 3); }); }

The repository test checks the small in-memory contract. It does not prove that authentication, remote APIs, persistence, or release signing work. Add tests around your own behavior before replacing the demo repository.

5. Connect one real feature

Replace the memory repository through the application’s dependency container. Keep the screen dependent on its state owner, add an initial load and a recoverable failure state, then test a successful operation and an unavailable data source. API clients have placeholder endpoints; selecting an authentication screen does not create a real sign-in service.

Common setup problems

No supported devices or platform directory missing

The ZIP contains source, not native runners. Create the selected platforms using the README command, then start an emulator or connect a supported device. iOS development requires macOS and Xcode.

Missing .g.dart or .gr.dart file

If you selected Drift or AutoRoute, run dart run build_runner build after flutter pub get. The default BLoC preset below does not need this step.

Dependency solver failure

Compare your installed Dart version with pubspec.yaml and the selected package constraints. Preserve the first solver error and report the configuration; forcing unrelated upgrades can hide the cause.

Counter resets after restarting

The demo repository is in memory. Add persistent storage and initial loading if the value must survive a restart. Selecting a database alone does not wire the counter into it.

Choosing supported options

The form checks combinations before generation. The SQLite template targets Android, iOS, and macOS; the native Drift template excludes Web. AutoRoute and Drift add a code-generation step. Secure storage needs platform-specific setup, and Dart environment options do not create native flavors or iOS schemes.

If a combination fails, report the configuration and first error. For more context, read the source walkthrough or consult Flutter’s project creation documentation.