Why I moved away from FlutterFlow when infrastructure started to matter

I liked FlutterFlow. I still do.

When I was building Shopmatey, I used FlutterFlow to get the app moving. The first version was built on Firebase too. That combination gave me a fast way to work through the product while I was still figuring out what the product actually was.

It was a good starting point.

At some point, though, I started setting up a mirror repo against Appwrite. That sounds like a backend switch. It was really the beginning of a different question:

How much of this system do I actually want to own?

FlutterFlow was good at the part I needed first

Shopmatey was an early product. I needed to test screens, change flows, and get something onto a phone without building two separate mobile applications from scratch.

FlutterFlow helped with that part. I could work across iOS and Android, move quickly, and spend my attention on whether the product made sense to another person.

I did not move away because I discovered that FlutterFlow was a bad tool. I moved away because the problem changed.

Early on, the biggest risk was taking too long to learn anything. Later, the bigger risk became letting too much of the product sit behind decisions I did not fully control.

Both concerns were real. They just showed up at different times.

The backend question kept getting louder

Firebase was where I started. It made sense for the first version because it removed a lot of setup between an idea and a working app.

But I kept coming back to the backend. I wanted a centralized place for the database, while still having real control over the infrastructure around it. Not theoretical control. The boring kind:

• knowing where the database runs;
• knowing how it is backed up;
• being able to inspect the services around it;
• understanding what I am paying for;
• having the option to run more of it on a VPS.

I was not trying to become a full-time infrastructure operator. I just did not want the only alternative to be handing every operational decision to a managed service and hoping the bill stayed reasonable.

That is why the Appwrite mirror repo interested me. I wanted to see what it felt like to keep the same product idea while changing the boundary around the backend.

It was not a grand migration plan. It was a way to make the question concrete.

Cost is part of architecture

The other part was cost.

Serverless pricing is attractive when you are starting out. You pay for usage, which can be a nice property when usage is close to zero. The uncomfortable part is that the bill is connected to every request and every new thing you add.

As an indie developer, that uncertainty is scary. Not because every request is expensive. Because a product can grow, a traffic pattern can change, or a small mistake can turn a variable cost into a problem that is much larger than the revenue supporting it.

In the worst case, I could be looking at a bill in the thousands before I had a business that could comfortably absorb it. Maybe that never happens. But I did not want to build my peace of mind around “maybe.”

A VPS is not automatically cheaper. It comes with maintenance, backups, security, monitoring, and a bunch of responsibilities that a managed provider normally handles for you. But the cost is easier for me to reason about. I can see the machine. I can see the services. I can decide when it is time to scale.

Predictable does not always mean cheap. It means I can make a decision before the invoice makes it for me.

That is a technical preference, but it is also an economic one.

The mirror repo was a question, not a rewrite

Creating the Appwrite mirror did not magically settle the architecture. It gave me somewhere to compare the options.

Firebase was familiar because it was where Shopmatey started. Appwrite made the idea of owning more of the backend boundary feel more tangible. I could think about the database and the infrastructure as things I was choosing, rather than just things I was consuming.

That distinction matters when you are working alone.

Every abstraction is useful until it makes the next important decision harder to see. The problem is not that an abstraction exists. The problem is when you can no longer explain what happens underneath it, how to move away from it, or what the cost looks like when the happy path stops being the common path.

I am not saying everyone should run a VPS. Plenty of teams should use a managed service and spend their energy elsewhere. I am saying the infrastructure boundary is worth treating as a product decision, especially when you are an indie developer paying the bill yourself.

Supabase belongs in the conversation too

If I were starting this decision today, I would look at Supabase alongside Firebase and Appwrite. The useful thing about it is not that it is the universally correct answer. There is no such answer.

I would look at Supabase because it gives you another database-first option, including a documented path for self-hosting on your own server or cloud infrastructure. I have not used Supabase for Shopmatey, so this is a suggestion for the comparison set, not a verdict from direct experience.

The question I would ask is simple:

Can I start quickly, understand the moving parts, and still have a reasonable path to owning more of the system later?

That question is more useful to me than asking which platform is winning this month.

The tool does not have to become your identity

As I moved further into the project, owning more of the Flutter code became more valuable. The application had more decisions that were specific to the product, and I wanted those decisions to be easier to see and change.

That did not make the original FlutterFlow choice wrong. FlutterFlow helped me get through the first problem: making a mobile product quickly and reaching people on both platforms.

Later, the problem was different. I wanted more direct control over the code, the backend boundary, and the cost of running the thing.

I think technical discussions get weird when people treat an early tool choice like a permanent declaration of taste. Most of the time, it is more ordinary than that.

You choose the thing that removes the biggest constraint. Then another constraint appears. Then you choose again.

What I would do with this lesson now

I would not tell an early builder to avoid FlutterFlow. I would not tell them to use Firebase, Appwrite, Supabase, or a VPS either.

I would ask what is actually slowing them down.

If the problem is getting a product onto both platforms and in front of people, FlutterFlow can be a very reasonable place to start.

If the problem is the database, infrastructure control, or an unpredictable usage bill, those concerns deserve a place in the decision before the product becomes difficult to move.

The first stack does not need to be the final stack. But it helps to know which parts you are choosing as scaffolding and which parts you are comfortable carrying for a long time.

I still like FlutterFlow. It helped me build Shopmatey when speed mattered most.

I moved away when the question became less about how quickly I could make the first version and more about whether I could afford, understand, and control what came after it.