Making a Flutter app with Claude Code

Like I mention in another blog post I just started my own business Antler Barrow (it doesn’t yet have its own website) through which I’m going to start publishing mobile apps. I’d like to take a moment to show my process of developing a Flutter mobile app along with Claude Code.

Why Claude Code?

First and foremost: I’m a very CLI-oriented person. I started out using IDE’s early in my career, but grew frustrated with them because I had trouble memorizing the meaning of different icons and keybinds that were specific to that IDE, and not really very portable from one language/IDE/extension to the next. Furthermore, I got a lot of fatigue and wasted a lot of time trying to find all the plugins and extensions I needed to make things work the way I expected them to, and all of my colleagues also had different prefences, which made it difficult to collaborate.

At the time I was also working on gaining comfort and familiarity with working at the CLI, and one thing I noticed is there were some tools that you could rely on being present in every single Linux system, and they pretty much all worked identically. vi being among them, I decided to start learning how to use it, and when I learned aboud screen and tmux (tmux ultimately won for me) there was no reason for me to go back to an IDE since all the tooling was there on the CLI, all the documentation for the tooling was there and easy to access, and (unless someone made an alias that replaced the basic functionality but used the original name) the tools worked the same regardless of the system I was using.

As a result of that, VS Code never felt like a good fit, and therefore Cursor never felt like a good fit either. Copilot’s vim plugin is good for code completion, but it’s capabilities are quite limited and it’s often incorrect. Claude Code, however, has a more Socratic kind of development process where I can work alongside it to architect a design and an approach, and, typically, it will faithfully execute that plan. I’ve tried to do similar things with Gemini CLI, but it’s just not quite as good at it as Claude Code is. I tend to save Gemini CLI for the very simple and straightforward tasks since I pay for Claude, but not for Gemini.

The Approach

I always start off a session by having Claude update the CLAUDE.md file by calling /init. This does a couple of things:

1. makes sure that the CLAUDE.md file actually represents the current state of the project.
2. hydrates the Claude session with slightly deeper information about the project structure and adopted patterns than only what’s in CLAUDE.md.

I heavily use Claude Code’s Plan Mode. I usually start with the simplest, least complete statement of what I’m trying to accomplish. I don’t really have a reason for this other than I just have a spark of inspiration and just want to capitalize on it. I’m at the point in my mobile app building career where my apps aren’t terribly sophisticated, and the dependencies are rather low, so this is fine. I anticipate that later on I’ll need to spend more time on designing a solution, but for now I can get away with just keeping things simple. The great thing about Plan Mode with a simple statement is that Claude can throw mud at the wall about a way to achieve the goal, and then you can engage with Claude in an iterative design process. This is something I do myself when working with people on iteratively designing something: start from the “no bad ideas” perspective and get everything documented, then start winnowing them down to the ones that have legs.

In the most current versions of Claude Code it even a nice interface for Claude to propose a menu of options for specific questions that you can select from, and if Claude doeesn’t manage to go down the correct path you can easily redirect it onto a better path. This is an effective way to help Claude understand how you’d like to go about achieving your objective, since even when the questions are answered and complete you can help Claude elaborate on those ideas.

At this point Claude Code is presenting an implementation plan, and if it’s ready, you can go ahead and implement it. When I first started working with Claude Code I made it ask for everything at every step. I had to approve every edit along the way, every tool usage, everything. As I gained confidence in the code that Claude wrote, I started just letting it go write everything, then I review it and either make or suggest changes, and go back to Claude for help dealing with the fallout impacts of my change decisions at this stage. Claude still has to ask permission to take actions other than reading and writing code, so any other tool usage or CLI calls are gated by my decisions. That’s more a matter of security though, and I may change that in the future if I decide to run Claude Code development on other machines that are set up to not be my personal day-to-day workhorse machines instead, which is something I’m considering.

So this process of posing a problem, working towards a shared understanding of the solution approach, letting Claude Code implement, reviewing & fixing Claude’s implementation, and starting another iteration until I can commit satisfactory changes is generally how things go for me. This lets me stay in-tune with the code and the systems design through the planning and review phases, but I can offload the nitty-gritty of banging out the code to Claude. If the code or the result doesn’t follow the intent or the vision, I can either scrap it entirely, or tune it up myself, and tell Claude to preserve my changes and refactor to follow the intent or vision I created.

Wrapping Up

So that’s generally how I go about working with Claude Code. I’m going to be setting up more socials this week, and I’m open to trying different ways of delivering this information (YouTube videos or Twitch streams, for instance), so if that’s something you’d be interested in, let me know on the socials!

Published on 2025-11-05