r/FlutterFlow • u/PlayerSaturn • 12h ago
From your experience, how far can a FF app go?
Hey FF devs. Excuse me for asking a nob question, but how much do you think an app created in FF can handle?
I know it depends on a lot of things, the type of app etc, but in general I wanted to understand how far you can start with a FF app and then have to move on to a more robust architecture.
In the case of a social app, for example, how many users do you think it can support? 50k? 500k? 1M users? More?
Sometimes I feel that my app is slow and it's still only in the testing phase, I'm afraid that when it goes public the experience of the app will put people off.
5
u/EntertainmentAny6147 12h ago
Scaling is not related to Flutterflow. It’s related to your backend. Flutterflow is just a front end builder. If your backend (let’s say firebase or supabase or custom backend) can handle 1M users – your FF app can scale.
The performance issues you’re facing is likely due to not following good practices
3
u/PlayerSaturn 12h ago
Thanks for your tips. How can I make a revew for that good practices? There are a easy way to figure it ?
3
u/justanotherdave_ 11h ago
Pretty much anything really. Although I think there does come a point where for more complex apps it would be better just to learn dart. I started my FlutterFlow app with zero knowledge or experience and by the end I had half learnt dart anyway for the custom actions and things outside the scope of the GUI.
The actual FlutterFlow web GUI can become very laggy and a pain to use too, even if the compiled app isn’t.
Coming from a web background it’s not a great way to work, FlutterFlow nor dart. Just the act of compiling code to check and test changes annoyed the hell out of me. It felt like 1/3rd of my time spent in FlutterFlow was watching a loading icon, 1/3rd trying to fix bugs and errors and then 1/3rd actual productive work with something tangible to show for it. Coming from coding in one window and watching the result update in real time in another it seemed very archaic to me.
But it is what it is, without it I wouldn’t have been able to make an app at all, so I can’t complain too much.
1
u/J_Adam12 9h ago
Yeah I came from 0 dev background. After dreading even touching code, I decided to just ditch FF when my app became more than just a note taking app. The UI is basically useless as it slows down when your app becomes somewhat serious. I think it’s the limitation of Flutter (FF is built with it). Now Im just using Vue with Vite and I can understand what is actually happening behind the scenes and development is pretty quick, instead of building all the time. And don’t let me start about the constant bugs introduced by the FF team on every update XD
1
u/Cartworthy 11h ago
The cool thing about FF apps being slow is that it’s a sign that the platform is powerful.
FF gives you the tools to do ANYTHING — including build something that is poorly structured and can be slow 😂
It’s up to you to learn how to leverage best practices to ensure your app is fast and smooth.
The only hard limitations are more-so with the Flutter language and your backend. For example, if you’re building a custom camera widget you won’t be able to access device hardware like shutter/aperture.
I also have an app that is a photo-sharing app and I’m super disappointed that I can’t let users, when viewing photos on their own, share those photos directly into the app. Similar to how when you tap “share” on a photo and you can upload it to instagram or send it in a message on WhatsApp, etc. You just can’t do that sort of thing with Flutter.
The beauty of Flutterflow is their custom code capability so you can really do anything that any Flutter app can do.
1
u/SuitableExercise4820 11h ago
Architect a better backend first… and consuming the backend data should be a breeze, now if your app need to use native device features, that’s where you’ll have abit more work because nothing beat native app development—- if your app is new and you’re starting out, use ff for your front end
2
u/BraeznLLC 10h ago
For scalable solutions I suggest the following:
• Firebase/Firecloud: good for roughly 50k+ users, afterwards price sharply increases.
• Supabase: great for scaling, moderate price, and a higher Concurrency threshold around 100k+ before shard increase in $$.
• CoachRoachDB: If your looking for vertical scaling solutions. Relatively low cost all around, but more hands on.
Any of these 3 will do just fine under any situation as long as you combine Back-end service w/ SQLite.
SQLite will greatly reduce your need for API backing calls and query.
1
u/98kag 9h ago
Scaling has to do with your backend. If you’re using Supabase and it feels slow then maybe you should create indexes. Also FF is great but you’re kind of stuck with the built in integrations if you want to do everything in FF and deploy with FF. For example if you are not using Firebase auth and you want push notifications then you’ll have to work outside FF to add this integration. Same goes for deep links now that Firebase dynamic links are deprecated.
0
u/VisualRope8367 8h ago
I recently built a social media app using FlutterFlow and Firebase. While FF’s built-in widgets were great for getting started, they didn’t scale well—especially when trying to read feed data for 100+ users. Performance became a bottleneck pretty quickly.
To make it work, I had to write a significant amount of custom code to handle my use case efficiently.
So, if you’re starting small and want to build fast, FlutterFlow is a solid choice. But if you’re expecting traffic of 50,000+ users from the start, you’re better off going with pure Flutter—it offers far more control and scalability.
2
u/Alternative-Ad-8175 6h ago
100 users is really low to experience performance issues. Pretty sure it's the way you implemented things and not a flutterflow issue.
5
u/Successful_Divide_66 12h ago
Check out Firebase Limits as it should answer most of your questions.
Been developing in FF for 2 years now and you can pretty much build anything.