Archipelago vs Alternatives
Archipelago isn't the only tool in the Flutter ecosystem. Here's an honest look at the landscape, what each tool is great at, and where Archipelago adds value.
Feature Matrix
| Feature | Archipelago | very_good_cli | mason_cli | GitHub Templates | melos | DIY |
|---|---|---|---|---|---|---|
| Project scaffolding | ✅ 66 bricks | ✅ Limited | ✅ Community bricks | ✅ Clone once | ❌ | ❌ |
| Variable substitution | ✅ Mason templating | ⚠️ Limited | ✅ Built-in | ❌ Manual rename | ❌ | ❌ |
| Monorepo architecture | ✅ Full structure | ⚠️ Basic | ❌ | ⚠️ Fixed | ⚠️ Management only | ❌ |
| Feature module generation | ✅ With state mgmt choice | ❌ | ❌ | ❌ | ❌ | ❌ |
| API/Impl split pattern | ✅ Built-in | ❌ | ❌ | ⚠️ If included | ❌ | Manual |
| Dependency injection | ✅ Dual-GetIt (global + local) | ⚠️ Basic | ❌ | ⚠️ If included | ❌ | Manual |
| State management | ✅ BLoC/Cubit/Riverpod/Provider | ✅ BLoC only | ❌ | ⚠️ Fixed choice | ❌ | Manual |
| CI/CD generation | ✅ GitHub Actions + Fastlane | ⚠️ GitHub only | ❌ | ⚠️ If included | ❌ | Manual |
| Monorepo tooling | ✅ Affected, coverage, size guard | ❌ | ❌ | ❌ | ✅ Scripts + versioning | Manual |
| Build-time stripping | ✅ build_prepare (debug/release swap) | ❌ | ❌ | ❌ | ❌ | Manual |
| Theme system | ✅ Visual theme builder + bricks | ❌ | ❌ | ❌ | ❌ | Manual |
| AI agent configs | ✅ CLAUDE.md, AGENTS.md, Cursor, Copilot | ❌ | ❌ | ❌ | ❌ | Manual |
| Analytics/monitoring | ✅ Pluggable SDK pattern | ❌ | ❌ | ❌ | ❌ | Manual |
| L10N | ✅ Feature-scoped i18n | ✅ Basic | ❌ | ⚠️ If included | ❌ | Manual |
| Asset generation | ✅ Type-safe | ✅ Basic | ❌ | ❌ | ❌ | Manual |
| Updates | ✅ Independent brick versioning | ✅ CLI updates | ✅ Brick updates | ❌ Re-clone + diff | ✅ | ❌ |
| Battle-tested | ✅ GoJek/Stockbit/Reku patterns | ✅ VGV clients | N/A | Varies | N/A | Varies |
very_good_cli
very_good_cli is a Flutter project generator built and maintained by Very Good Ventures. It's a polished, well-documented tool from a team with a strong track record in the Flutter ecosystem.
What it's great at:
- Generating well-structured single-package or multi-package Flutter projects quickly
- Enforcing consistent code style through its opinionated setup
- BLoC state management integration, since VGV are the maintainers of the bloc library
- A familiar, approachable setup for teams already in the VGV orbit
Where Archipelago goes further:
very_good_cli generates a solid starting point. Archipelago generates a production-ready monorepo with the patterns you'd build yourself over months of iteration — dual DI containers, self-registering feature SDKs, build-time dependency swapping, Fastlane lanes, affected-package CI detection, and more.
If you've outgrown a single-package app and need genuine feature isolation with independent build caches, Archipelago provides that structure from day one rather than requiring you to add it later.
When to use very_good_cli:
- You want a battle-tested single-package or simple multi-package project with minimal setup
- Your team is already deeply invested in the VGV/BLoC ecosystem and conventions
- You prefer less structural opinion on monorepo architecture
mason_cli
mason_cli is the brick templating engine that Archipelago is built on top of. It's a capable, general-purpose code generation tool for the Dart/Flutter ecosystem.
What it's great at:
- Running individual code generation templates (bricks) for specific tasks
- The community BrickHub hosts a wide range of community-contributed bricks
- Flexibility — you can build and share your own bricks for anything
- Composable: you can layer mason into any project regardless of structure
Where Archipelago adds value:
mason_cli gives you individual bricks. Archipelago gives you an opinionated, integrated system where all 66 bricks are designed to work together. The generated code follows consistent patterns across every package — the DI registration, the feature SDK shape, the test structure, the CI configuration. Using mason directly requires assembling and maintaining that coherence yourself.
Archipelago also handles versioned distribution via Cloudflare R2 with tier-based access, so you're not hand-managing which bricks are in scope.
When to use mason_cli directly:
- You already have an established project structure and want to add specific templates
- You're building your own brick library for your team's conventions
- You want maximum flexibility and don't need an integrated system
melos
melos is a monorepo management tool for Dart/Flutter workspaces, built by Invertase. It's excellent at what it does.
What it's great at:
- Running scripts across all packages in a monorepo (bootstrap, test, analyze, format)
- Conventional commits-based versioning and changelog generation
- Publishing packages to pub.dev from a monorepo
- A well-maintained, widely adopted tool in the Dart ecosystem
Where Archipelago adds value:
melos manages an existing monorepo — it doesn't generate one. Archipelago generates the monorepo with architecture already in place, then provides its own monorepo toolkit (affected detection, dependency graph enforcement, build preparation, coverage aggregation) that lives directly in your project without a runtime CLI dependency.
The two tools aren't mutually exclusive. If you use Archipelago to generate a monorepo and want melos for versioning and publishing, that's a reasonable combination.
When to use melos:
- You have an existing Dart/Flutter monorepo and need cross-package script management
- You're publishing multiple packages to pub.dev and want automated versioning
- You want conventional commits-based changelogs across your workspace
GitHub Template Repositories
GitHub template repos (e.g. "Use this template" button) are common in the Flutter ecosystem. They provide a working starter project that you clone and modify.
What they're great at:
- Instant starting point — click a button and you have a repo
- Easy to browse the code before you commit
- Works with any language or framework, not just Flutter
Where Archipelago is fundamentally different:
GitHub templates are static snapshots. You clone once, then you're on your own. Every project gets the same code with the same names. You manually rename my_app to your actual app name across dozens of files, folders, imports, and class names.
Archipelago uses Mason brick templating. When you run archipelago create, every file is generated with your actual project name, prefix, and configuration already applied. A variable like becomes Dompetku everywhere — package names, class prefixes, import paths, folder names, DI registrations, barrel exports. No find-and-replace. No missed renames.
| Aspect | GitHub Template | Archipelago (Mason) |
|---|---|---|
| Naming | Manual find-and-replace across all files | Variables ( |
| Configuration | One fixed setup | Configurable: state management, network library, analytics vendors, etc. |
| Composability | Monolithic — take all or nothing | 60+ individual bricks, compose what you need |
| Updates | Re-clone and manually diff | Independent brick versioning, update individual bricks |
| Customization | Fork and drift | Generated code is yours, bricks stay upstream |
| CI/CD | Fixed for one provider | Configurable (GitHub Actions / GitLab CI) |
| Feature modules | N/A | archipelago generate feature adds new modules on demand |
When to use a GitHub template:
- You want to browse the actual code before deciding
- Your project structure is simple enough that renaming is trivial
- You don't plan to add new feature modules after initial setup
DIY from Scratch
Rolling your own architecture means full control and no external dependency. Senior teams with strong architectural opinions sometimes prefer this.
What it's great at:
- Complete freedom to design exactly what you want
- No dependency on external tooling or brick versioning
- Deep understanding of every decision, since your team made it
The honest cost:
The patterns Archipelago provides — feature isolation, API/Impl splits, dual DI, two-phase init, Fastlane + CI/CD — are not novel ideas. They're settled patterns from production apps with millions of users. Building them from scratch takes weeks. You will make the same tradeoffs, likely arrive at similar conclusions, and spend engineering time on infrastructure instead of product.
When DIY makes sense:
- Your team has very specific, non-standard architectural requirements
- You have senior Flutter engineers who have done this before and enjoy it
- You're building a tool or framework yourself and need maximum control
Summary
Each tool has a legitimate place:
- very_good_cli — Best for clean, opinionated single/multi-package projects without heavy monorepo needs
- mason_cli — Best as a composable code generation layer in any project
- GitHub templates — Best for quick starts where you want to browse code first and don't mind manual renaming
- melos — Best for cross-package scripting and pub.dev versioning in existing monorepos
- Archipelago — Best when you need a full, integrated monorepo system with production-grade architecture patterns from the start
The key difference between Archipelago and GitHub templates: templates give you one static snapshot you manually adapt. Archipelago generates code tailored to your project — your app name, your prefix, your state management choice, your analytics vendors — with 60+ composable bricks that stay independently versioned. No find-and-replace. No drift from upstream.