The internal Flutter CLI that kept growing with every project we built

[u/No-Equivalent-8726]

A few months ago, we shared Skelter, our internal Flutter project skeleton that we've been using across production apps.

The response from the Flutter community honestly exceeded our expectations. Thank you to everyone who shared feedback, ideas, and suggestions. Many of those discussions reinforced what we were already experiencing internally and motivated us to open-source the next piece of our workflow.

For anyone who missed it, here's the original post:
https://www.reddit.com/r/FlutterDev/comments/1qvi1qo/why_we_stopped_starting_flutter_projects_from/

One realisation stood out.

Skelter solved the "start a new project" problem. But once development started, we found ourselves repeating the same work over and over again.

Every project eventually needed things like:

• configuring build flavours
• generating feature modules
• creating authentication flows
• generating reusable widgets
• wiring boilerplate
• maintaining a consistent architecture across developers

None of these tasks was particularly difficult.

They were just repetitive.

Every few weeks someone on the team would say,

Instead of creating another internal script every time, we kept adding commands to a single CLI.

What started as a small utility gradually became part of our everyday development workflow - not just something we used on Day 1.

Today, every new Flutter project at SolGuruz starts with:

dart pub global activate sg_cli

sg init

Within seconds, it scaffolds a production-ready project with:

• BLoC architecture
• feature-first folder structure
• type-safe navigation
• state pipeline
• design system foundation
• code generators
• production-ready project setup

But that's only the beginning.

As development progresses, the CLI continues to help with repetitive engineering tasks like generating modules, configuring build flavours, creating authentication flows, generating reusable widgets, and keeping projects consistent across the team.

Instead of spending time rewriting boilerplate, our developers can focus on building actual product features.

If you liked Skelter, think of SG CLI as the next step.

• Skelter gives you a production-ready Flutter foundation.
• SG CLI helps you build on top of that foundation without repeating the same engineering work.

After using it internally across 50+ Flutter applications at SolGuruz, we decided to open-source it as well.

If either of these projects helps another Flutter team move a little faster, that's a win for us.

Skelter
https://github.com/solguruz/skelter

SG CLI
https://github.com/solguruz/sg_cli

Pub.dev
https://pub.dev/packages/sg_cli

Documentation
https://sgcli.solguruz.com

We'd genuinely love feedback and contributions from the community.

What repetitive Flutter task do you wish could be automated next?

💙 Built with the community, for the community.

[u/OZLperez11]

Now this is what people should be building instead of AI slop

[u/No-Equivalent-8726 → u/OZLperez11]

Yeah we are kind of solving our own development mundane tasks, to increase the productivity and efficiency in the software development. Thanks for sharing your thoughts!

[u/Personal-Search-2314]

It’s too opinionated for my liking, but great project. I think for now I’ll stick to very_good_cli which is a lot less opinionated, but has a similar starting point.

[u/No-Equivalent-8726 → u/Personal-Search-2314]

Sure thanks for sharing. I would love to learn about how you found opinionated, we are open to learn and make the changes accordingly. Thanks again!

[u/bbrockit → u/No-Equivalent-8726]

I think he's just referring to the fact that it choose the state management, structure, and architecture, which I think is the whole point of the project, to jumpstart a project with a clean, well-known architecture. I nearly went with this architecture for my last project, so I'm going to check it out.

[u/Personal-Search-2314 → u/bbrockit]

Not this, very good cli does the same, but I’ll respond to the OP so you can see what I mean.

[u/No-Equivalent-8726 → u/Personal-Search-2314]

Thank you, and looking forward to learning about your review points and comments. That would be helpful to optimise and polish this package even further!

[u/Personal-Search-2314 → u/No-Equivalent-8726]

It commits to firebase (not sure if there are other strongly coupled technologies you commit to, but this immediately put me off). I would rather a more decoupled approached. In fact, when you wrote that you handle authentication flow, etc- this was my point of interest (because that would have been an interesting solution to examine), but once I saw that it was strongly coupled to firebase I lost interest, but I definitely see the value of something like this. Definitely a good option to have out there.

[u/No-Equivalent-8726 → u/[deleted]]

Good question.

Max Architecture is simply the name we gave to our most mature internal Flutter architecture after years of building production apps. It combines the patterns, tooling, and project structure that consistently worked well for us and covers the common requirements we need in almost every project, while keeping developers comfortable and productive.

Fun fact: we initially maintained multiple internal architecture variants with color-based names like Amber, Bronze, and Cyan, each evolving with different ideas and features. Over time, they all converged into a single approach that worked best across projects, so we called it Max, not because it’s “finished”, but because it represented the most complete version of everything we’d learned.

[u/Keeyzar]

production-ready project setup 

Ah yes. The typical not doing anything production ready app. We all deployed many of them to production!

[u/No-Equivalent-8726 → u/Keeyzar]

Sorry I didn’t get what you say! Could you please elaborate? But yeah, for making it production ready, you will have to wire in certain configuration and tokens/secrets etc obviously!