I peeped over Alex's screen one day and saw some designs that piqued my interest - a sleek-looking desktop app, similar in appearance to Bark's leads dashboard. I had always wanted to build a Flutter app, and despite Flutter & Dart not being part of Bark's tech stack, this opportunity seemed perfect. I was familiar with the endpoints and underlying data. Alex had gifted me a beautiful, well-researched, and thought-out design. I had the capacity. I had run out of excuses - I HAD to build this app, albeit only as a technical exercise.


I loved working with Flutter, but we'll get on to that later. You never deliver the same project twice in the same way, and this was no exception, so I'll start off with what I learned:

Using Riverpod Added Yet Another Learning Curve

For complex state management in React, I much prefer to use XState. XState and other complex state management tools are usually born from developers identifying shortcomings with built-in solutions and solving them in other, more developer and performance-friendly ways. Knowing this, I looked around for a state management package for Flutter and found Riverpod (an anagram of Provider).
Like other extremely powerful packages, Riverpod required a large learning curve. It is a go-to for state management, but at the stage of learning that I was, I should have just used the built-in state management Flutter provides.
That said, at the end of the project, I was very happy with my decision to go with Riverpod. The package provides lots of functionality, allows for more granular state control and most importantly for me, is highly scalable.

I Should Have Tried To Sneak In More Material Design

I always feel for designers. They put together these beautiful designs only for the developers to say, "It's too hard", "we can't do it" and other "reasons". The folks at Google even put together a playlist of this designer-developer dynamic. I didn't want to disappoint Alex and desired to deliver the app as close to the original design as possible, but there was a small challenge - the original design wasn't immediately MUI compatible.
In my post "Flutter Is Easier With A MUI 3 Inspired Design", I touched on how some widgets are hard to customise. Making the executive decision to build the app with more MUI widgets would have allowed the project to be finished a lot sooner, but I'm grateful I persevered as I learned so much about building good, reusable widgets. I only mention it as it's something to consider should you wish to build your next, or first, app with Flutter.

Don't Forget That Layout Does Not Work Like HTML

Having spent years building UIs that are effectively just HTML, it was sometimes hard to forget that way of dealing with UI. The docs warn you about this early on, and keeping this in mind will make for a much more pleasant Flutter experience.

Try Not To Leave The Project For Too Long

All-in-all, putting everything together, from initially reading the docs and watching tutorials to having something functional didn't take that long at all. However, I was working on other projects, so this time was spread out over several months which was a mistake - an hour here, two hours there and so on. I wish I had spent the time continuously working on the app as it meant that each time I opened VS Code, I had to remember where I left off. It also would have been a lot quicker to build what I did build and would have left me with more time to implement some of the other screens.

I Love Flutter!

Self-inflicted issues aside, I love Flutter. I don't understand why we don't use it as much in the West, especially considering large Eastern conglomerates (such as Alibaba, Tencent and Nubank) do, proving Flutter's viability as a cross-platform solution.


I loved how quickly it was to build this app. Even as a solo developer on a project, you'll be able to put something beautiful together rather quickly.
As I was building for Mac OS whilst on a Mac, the development app was super fast, despite having all of the trinkets required to run it in debug mode. Neither did my Apple Silicon Macbook Pros ever feel like they were struggling during development. I didn't, however, do much testing on other device types, but it seemed like my computer performed well while running the app on an emulated Android device.


It's not only development that is fast. Flutter apps compile down to native binaries without, for example, a JS bridge (cough cough), meaning that they outperform React Native apps. As I mention in this post though, the team over at React agree that this bridge is a performance bottleneck, and work is underway to rethink this architecture.

Developer Experience

I don't like VS Code. I generally find IntelliJ IDEs easier and faster to use (although they did completely mess up their devcontainers plugin). VS Code for Flutter development however is really, really good - it just works! You can feel that a lot of care was taken into making the developer experience as good as it can be. I've heard from trusted sources that Copilot works incredibly well with the two as well.


All in all, I completely love Flutter. I can understand the frustration of learning a new language (which is why I originally took so long to take the jump in the first place), framework and changing to thinking about UI in a declarative manner. Despite this, I would still urge you to power through and give Dart & Flutter a try and fall in love with it too!