Firebase Development for Flutter Apps
Firebase removes the need for a server team. It doesn't remove the need to think about data structure — and that's where Firebase projects go wrong.
The short version
- Firestore charges per document read, so the schema is designed from your screens backwards.
- Security rules get written and tested, not left in test mode with an expiry date.
- Push notifications configured for all three states: foreground, background, terminated.
- Already live and unsure where you stand? A rules and schema audit is a sensible first step.
What Firebase development covers
Authentication flows
Email and password, phone number with OTP, and social sign-in, plus the parts people forget: password reset, email verification, account deletion and session handling.
Firestore data modelling
Collection and document structure designed around your real query patterns, with denormalisation where it saves reads and subcollections where it keeps documents small.
Security rules
Rules that actually enforce ownership and role boundaries, written and tested rather than left in test mode with an expiry date nobody is watching.
Firebase Storage
Profile photos, documents and media uploads with client-side compression, progress reporting, and storage rules matched to your Firestore permissions.
Cloud Messaging and notifications
FCM configured for Android and iOS, including foreground, background and terminated-state handling, deep links into the right screen, and topic subscriptions.
Offline support and cost control
Firestore offline persistence so the app works on a bad connection, plus query and index tuning to keep document reads and your monthly bill under control.
Why the data model is the whole job
Firestore bills per document read, not per query. That one fact drives nearly every structural decision worth making.
A feed screen that loads a hundred posts and then loads each author separately is a hundred and one reads every time someone opens the app. It will look perfectly fine in testing with three users.
So I start from the screens and work backwards: which views load together, what has to be live versus cached, which fields can be duplicated onto the parent to avoid a second lookup, and what genuinely needs a subcollection because it grows without limit.
Getting the schema right early is cheap. Getting it wrong means a migration later, on live user data, while the app is running.
Security rules are not optional
A project left in test mode is a database anyone can read and write using the config that ships inside your app.
It's the most common serious problem I find
And nearly always an oversight rather than a decision.
Rules mirror your real permission model
Users read and write their own documents, roles gate admin collections, uploads are size and type limited, and writes are validated for shape.
What rules can't express moves to a Cloud Function
Rather than being trusted to the client.
Projects where I have done this before.
Full case studies, including the problems I hit and how I solved them.
The tools I build this with.
Auth
- Firebase Auth
- Email & password
- Phone OTP
- Social sign-in
Data
- Cloud Firestore
- Composite indexes
- Offline persistence
- Batched writes
Files & messaging
- Firebase Storage
- Cloud Messaging
- Topic subscriptions
- Deep links
Hardening
- Security rules
- Role-based access
- Firebase Hosting
- Crashlytics
Three ways to work together.
Firebase work is often scoped as a phase inside a larger app build, but audits, rules reviews and schema migrations also work well as standalone hourly engagements.
Fixed price
One agreed price for an agreed scope, split into milestones. You know the total before work starts, and I absorb the risk of my own estimate being wrong.
Best for: Well-defined builds where the feature list is already settled
Hourly
Billed for time actually worked, with a log of what was done. No minimum commitment, and you can stop at the end of any week.
Best for: Fixes, audits, custom code and open-ended work
Dedicated developer
A reserved block of my capacity each month, working to your priorities as they change. Scope can shift between sprints without renegotiating a contract.
Best for: Ongoing product work and longer engagements
From first call to launch and beyond.
Backend work front-loads the discovery and design stages, because schema and rules decisions are the ones that are expensive to reverse once real data exists.
- Step 01
Discovery
A call to understand the product, the users, the constraints and the deadline, followed by a written scope you can push back on.
- Step 02
Design
Screen flow, data model and architecture agreed before code. If you have Figma designs I work from them; if not, we settle structure first.
- Step 03
Development
Built in milestones you can see, pushed to your repository as it happens, with a working build to try at the end of each stage.
- Step 04
Testing
Real devices across both platforms, slow networks, edge cases and the states people forget: empty, loading, offline and error.
- Step 05
Launch
Signed release builds, store listings, review feedback handled, and deployment of any web or Firebase side of the project.
- Step 06
Support
A bug-fix period after release, then ongoing availability for feature work, SDK upgrades and store compliance changes.
Frequently asked questions
Is Firebase enough, or do I need a custom backend?
For the large majority of mobile apps Firebase is enough, and it saves you both the build cost and the ongoing maintenance of a server. Where it starts to strain is heavy relational reporting, complex multi-step transactions across many collections, and aggregations over large datasets. If your product is heading that way I will say so, and Firebase can still handle authentication and messaging alongside a custom backend doing the heavy work.
How much will Firebase cost to run each month?
Firebase pricing is usage-based, so it depends on document reads, writes, storage and bandwidth rather than on user count directly. Two apps with the same number of users can differ by an order of magnitude purely because of how their data is structured. I design schemas with read cost in mind and can estimate a range once I know your expected usage patterns. I would not quote you a monthly figure before that, because it would be a guess.
Can you migrate my existing data to a better schema?
Yes. Migrations are done with scripts against the live project, usually in stages with the app supporting both shapes during the transition so nothing breaks for users mid-way. It is careful work rather than difficult work. The main requirement is a proper backup and a rehearsal against a copy of the data before anything touches production.
Will you set up push notifications?
Yes, with Firebase Cloud Messaging on both platforms. That includes the platform configuration, which is the fiddly part: APNs certificates for iOS, notification channels for Android, and the three separate delivery cases of app in foreground, app in background and app terminated. I also wire notification taps to open the correct screen rather than just the home screen.
Can you review the security of my existing Firebase project?
Yes, and it is worth doing if you have never had it checked. A review covers your Firestore and Storage rules, whether authentication state is genuinely enforced server-side, whether any collection is world-readable, and whether sensitive fields sit in documents the client can read. You get a written list of findings ordered by severity, and you can either fix them yourself or have me do it.
Do you use Cloud Functions?
Where they earn their place. Good uses are logic that must not be trusted to the client, scheduled jobs, aggregation counters and reacting to document writes. Bad uses are things the client could do directly, since every function adds cold-start latency and another thing to deploy and monitor. I default to keeping the architecture as simple as the requirement allows.
Does Firebase work with FlutterFlow?
Yes, and they are designed to be used together. FlutterFlow generates Firestore queries and authentication flows directly from your schema, which is exactly why the schema should be designed before the screens. I do this pairing regularly, and you can read more on my FlutterFlow development services page.
Need a Firebase backend that will hold up?
Whether you are starting fresh or worried about a project already live, tell me what your app does and I will tell you what the backend needs.