Why I chose FlutterFlow when I was starting out

On April 29, 2023, FlutterFlow featured me as its “Founder Highlight of the Month.”

The post included a short write-up about Shopmatey and linked to a video of me talking about the product.

It was cool.

A few months later, on October 12, 2023, I got a box of FlutterFlow swag and posted it on X. I am not above being excited by a box of stickers and a shirt.

But the feature itself is not really the interesting part to me now.

The part I keep thinking about is why I was using FlutterFlow in the first place.

FlutterFlow described Shopmatey as an all-in-one social commerce platform for creators. That is fair. I remember it more simply: I was trying to make a mobile product around social commerce and find out whether anyone cared.

I was trying to build an app, not choose a side

When I was starting out, I kept moving between different ways of building mobile apps.

On Apple, there was native Swift. For Android, I was looking at Kotlin and, earlier, Java.

The problem was not that native development was bad. It was that I was one person trying to maintain what was effectively two versions of the same product while I was still figuring out what the product even was.

I was still working out:

• whether people wanted the idea;
• which parts of the experience felt good;
• which ideas were worth keeping;
• what Shopmatey should become.

That is already a lot of uncertainty.

Adding two separate mobile implementations on top of it created a lot of friction. Whenever I wanted to try something, I was also thinking about how to make it work in two different ecosystems, with two different release loops, before I had much evidence that the thing was worth the effort.

I was not trying to win an argument about mobile frameworks. I was trying to get an app into people’s hands.

That distinction mattered.

Cross-platform changed the question

FlutterFlow made the question smaller.

Instead of thinking:

First I need to become very good at the iOS version, then rebuild or maintain the Android version.

I could think more like:

Can I get this idea onto both platforms and see what happens?

That was a much more useful question for where I was.

Cross-platform was a big part of the reason I gravitated toward FlutterFlow. I wanted a single experimentation loop that could reach people on iOS and Android, not two parallel projects that both needed to be “ready” before I could learn anything.

An idea that takes three days to test is materially different from an idea that takes three weeks to test.

Not because three days is always good and three weeks is always bad. Sometimes the three-week version is the right thing. But when you are still searching for the product, the shorter loop gives you more chances to be wrong, learn something, and try again.

That was the thing I was optimizing for.

Ship something.

Put it in front of people.

See what they do.

Change it.

The visual part was not the point

No-code and low-code tools often get discussed as if the main question is whether someone wants to write code.

That was not really how I thought about it.

I was not trying to avoid understanding the product. I was trying to reduce the amount of ceremony between an idea and something I could actually put on a phone.

The visual environment lowered the initial surface area I had to understand. I could spend more of my attention on the product, the screens, the flow, and whether the idea made sense to another person.

That is useful when the biggest risk is building something nobody wants.

It is easy to spend weeks making the architecture feel respectable before asking the more uncomfortable question:

Does anyone care about this?

I did not have a perfectly formed product waiting to be implemented. I had a bunch of ideas about social commerce, some screens, and the feeling that the existing shopping experience was fragmented. I needed to find out whether any of it was interesting.

The FlutterFlow video is a pretty good snapshot of that stage. In it, I talk about tinkering with Shopify stores, noticing how fragmented e-commerce felt, and trying to turn that observation into Shopmatey. The video is only 56 seconds long, but the basic idea was simple: FlutterFlow helped me move from an idea to a live app on the App Store faster than I would have otherwise.

That does not mean the first version was perfect.

It just meant it existed.

Reach is a technical decision too

I think early technical decisions are also economic decisions.

Every platform, build system, framework, and abstraction costs some combination of:

• time;
• attention;
• iteration speed;
• cognitive overhead.

Those costs are easy to ignore when they are spread across a roadmap. They are harder to ignore when you are the person doing all of it.

If I only built for one platform, I might learn from one group of people. If I could put the product in front of people on both platforms, I had a better chance of finding out whether the idea resonated at all.

That is not a guarantee. More reach does not turn a bad product into a good one. It just changes the number of people who have a chance to tell you what is wrong.

For me, that mattered more than having the most ideologically pure stack.

I was not building a banking system. I was trying to discover what Shopmatey wanted to be.

The stack still mattered. The code still mattered. But the order mattered too.

First I needed enough product to learn from real people. Then I could spend more time deciding which parts deserved deeper technical ownership.

The right abstraction can change

The decision that helps you discover a product does not necessarily have to be the exact decision you keep forever.

As the product became more complex, the trade-offs changed. Local caching, offline sync, and custom platform behaviour became more important. Exporting generated code repeatedly and merging changes became less attractive than owning more of the Flutter code directly.

So I started moving in that direction.

That did not mean FlutterFlow was a mistake. It meant the bottleneck had moved.

At the beginning, the bottleneck was getting something onto both platforms and in front of people. Later, the bottleneck was control: control over the code, the architecture, and the parts of the application that had become more specific to the product.

Those are different problems.

I think this is where a lot of technical discussions become unnecessarily moral. People talk as if choosing a tool is a permanent statement about what kind of builder you are.

It is usually more ordinary than that.

You choose the thing that helps with the problem in front of you. Then the problem changes. Then you choose again.

What I would tell someone starting now

I would not tell everyone to use FlutterFlow. I would not tell everyone to use native Swift or Kotlin either.

I would ask what is currently preventing you from testing the product.

If platform-specific capabilities are the core of the product, native may be worth the extra control from the beginning.

If maintaining two platforms is the bigger constraint, cross-platform may be the more sensible starting point.

If the distance between an idea and a working app is the thing slowing you down, a low-code or no-code tool may be a rational choice, as long as you are honest about the limits you are accepting.

The answer is not about picking the most impressive stack. It is about choosing what lets you reach the next real answer.

For me, FlutterFlow shortened that distance at a moment when I needed to reach more people, iterate quickly, and figure out whether Shopmatey deserved more of my time.

Later, I wanted more control over the code. That was also reasonable.

Both things can be true.

The FlutterFlow feature was nice. The swag was nice too. But the more useful lesson I took from that period was that an early technical choice does not have to become an identity.

Sometimes it is just scaffolding.