Archipelago
All posts Architecture

Flutter Starter Kit Checklist for Production-Ready Apps

A 10-point checklist to judge any Flutter starter kit or boilerplate before you build on it, from flavors and CI to release builds.

Banua Coder4 min read

Search for a Flutter starter kit and almost every result says "production-ready". The words cost nothing to write. What they should mean is a list you can test.

I have built Flutter apps in fintech, at more than 20 million daily active users. The apps that hurt later were rarely the ones with a bad idea. They were the ones whose starting point skipped something boring: a staging flavor, a rule for imports, a release build that still held debug tools. Fixing these at week 40 costs far more than at week 1.

This is the checklist I use to judge a starter kit, including ours. Run it before you commit to one. Each check takes minutes.

The checklist

1. Flavors, not a flag. Can you build development, staging and production apps with different bundle IDs, names and config? Ask: if I install both, do they sit side by side on one phone? A bool isProd in code is not a flavor. See Flutter flavors.

2. Environment files outside Git. Are API URLs and keys read per flavor from files that are ignored by Git? Search the repo for a real key. If you find one, stop.

3. A rule for imports. Does anything stop features/orders from importing features/auth internals? A folder layout is a wish. A check that fails in CI is a rule. This matters more as the team grows.

4. Dependency injection with a scope. One global container works until a feature resolves another feature's private class. Look for a container per feature. See get_it for a modular app.

5. A way to add the next feature. Day one is easy. Look at what the kit does for feature number ten. If the answer is "copy a folder and rename it by hand", you will drift. A good kit has a command for this.

6. CI that runs on the first commit. Analyze, format and test, on every pull request. Bonus: tests only for the packages that changed. See CI for changed packages.

7. A path to the stores. Signing, build numbers and upload to TestFlight and Google Play should be a lane, not a wiki page. See Fastlane and GitHub Actions.

8. Debug tools that do not ship. Network inspectors, flag overrides and test hooks are useful in development. Then check the release build: are they gone, or only hidden? See removing debug tools from release builds.

9. Tests that ran. Does the kit ship tests, and do they pass on a clean clone? A kit with no tests tells you what the author thinks about tests.

10. A maintainer's pulse. Check the last commit, open issues and the Flutter version it targets. A kit pinned to a Flutter version from two years ago is a fork you now own.

Score the common options

I would not give a total score, because needs differ. Here is how the main choices usually fare. Check each claim yourself, since all of them change.

  • flutter create. An empty app. Everything above is your job.
  • Very Good CLI. Strong on 1, 6 and 9: flavors, GitHub Actions, and tests at 100% line coverage. Free, no sign-in. It makes a single app, so rules 3 to 5 are for you to build.
  • GitHub template repos. They vary a lot, so run the ten checks on each one. Look at CI, store lanes and import rules first, and check the date of the last commit.
  • Mason bricks. Good for single pieces. The consistency between bricks is your work.
  • Archipelago. Our kit. It aims at 3 to 8: a workspace with a container per feature, a dependency graph check in CI, archipelago generate <brick> for the next feature, GitHub Actions or GitLab CI, Fastlane lanes, and build_prepare to swap debug packages out of release builds. It does not cover 9 and 10 for you. Read the tests in your generated project, and judge the pulse yourself.

When a starter kit is the wrong choice

Be honest about this. A kit adds structure, and structure has a cost.

  • A prototype that you will throw away in a month does not need a workspace. Use flutter create.
  • A one-developer app with five screens can live in one package.
  • If your team already has a house style and a template, keep it. Use a kit only to learn from.
  • If you need a finished app in a known category, such as a delivery app, buy that app. A kit is a base, not a product.

Try the checks on ours

Archipelago has a free plan: 3 project scaffolds per month and 50 free bricks out of 76. Generate a project and run the ten checks on it. Start with the monorepo template guide to see the layout, or the brick catalogue and pricing.

dart pub global activate archipelago_cli
archipelago auth login --interactive
archipelago create --output ./my_app

Start free.