Firebase for mobile apps: a solo dev's experience

In 2023, I launched my first mobile app solo - TaleMe - betting fully on the Flutter + Firebase duo. Two years later, the conclusion is clear: Firebase allowed me to ship a V1 at lightning speed, but with the hindsight of 2025, I also see where the issues lie.

In this article, I share my honest solo dev feedback: what Firebase does really well for building a mobile app, where I started to be disappointed, and how I would approach things differently today.

Context: why I chose Firebase in 2023

Web developer by training (front and back), I found myself in 2023 wanting to create TaleMe, a mobile app around AI to tell stories to children. Alone on the dev side, and with no prior mobile experience, my goal for V1 was simple: ship fast and well. I needed the app's "core" features, a secure user authentication system, and a paywall for subscriptions (to validate the business model). No way I was going to spend months reinventing the wheel.

Why Firebase? In 2023, it was a no-brainer for me. Firebase ticked all the boxes: realtime cloud database, ready-to-use auth, file storage, server functions… all "serverless" (zero servers to deploy or maintain) and natively integrated with Flutter via official plugins. On top of that, the generous free tier allowed starting without immediate costs - ideal for an MVP. For monetization, I also quickly opted for a third-party service (RevenueCat) to implement in-app purchases without hassle. In short, with Flutter for the front and Firebase for the back, all the building blocks were there to get started at full speed.

Spoiler: I was right to insist on speed: I was able to code and publish a first version in barely 4 weeks (store approval included) despite my zero mobile experience at the start. Mission accomplished for V1! But what about the long term? Let's get to the heart of the matter: what Firebase brought me… and at what cost?

What Firebase does very well for a mobile app

⏩ Unbeatable time-to-market

The first asset of Firebase is that it accelerates development. By combining Firebase with Flutter, I was able to bootstrap my app in record time. Google doesn't oversell it: "Integrating Firebase with your Flutter apps lets you get to market and deliver value to your users […] in less time with less effort.". Concretely, I almost didn't have to write a "classic" backend. Database, authentication, media hosting, everything is available on demand as services to enable. In 2023, solo, it was clearly the fastest way to go from idea to a running app. Without Firebase (and Flutter) it would have taken much longer.

🤝 Flutter integration and great DX (developer experience)

Firebase also shines for its excellent integration with Flutter and its polished DX (developer experience). The official FlutterFire plugins cover practically all Firebase products, with often well-crafted docs and an active community. I had no trouble adding Firebase to my Flutter project: a FlutterFire CLI run, a few configs, and I had access to the whole suite of services.

Result: I could focus on the app's business code, not wiring infrastructure. Staying in the Dart/Flutter ecosystem on the client side makes development smooth.

Admittedly, for the backend (Cloud Functions), I had to write in TypeScript (I'll come back to that), but on the Flutter app side, the developer experience is very pleasant. You feel that Firebase was designed so that a solo dev or a small team can be productive without fighting the tool.

🧰 Very handy integrated product suite

Another advantage of Firebase: it's an all-in-one ecosystem. By adding Firebase, I unlocked a whole set of very useful ancillary services for a mobile app, with no extra integration effort:

• Crashlytics (crash reporting) - Included out of the box. I got production error reports from the start, crucial to fix bugs quickly. No need to plug in Sentry or anything else, it was already in the Firebase console.
• Analytics (Google Analytics for Firebase) - To understand user behavior. In a few clicks I had dashboards on retention, screens viewed, etc. Super useful to guide product iterations.
• Cloud Messaging (FCM) - Send push notifications for free, cross-platform. Again, a few lines of config on the app side, a Cloud Function on the server side, and I could notify my users (for example about new features).
• Remote Config / A/B Testing - The ability to flip feature flags remotely or test different variants of a feature. Even if I used it only on a small scale, knowing it's available "out of the box" is reassuring to evolve the app without constant repushes.
• Performance Monitoring, App Distribution, etc. - Firebase offers many bonus tools (perf, beta testing, etc.) integrated natively. Not all used at the start of TaleMe, but it's a real comfort to know you can enable them when needed, without scouring 36 third-party services.

In short, Firebase acted as a mobile dev "Swiss Army knife" for me. For a solo dev who has to handle everything, having all these tools at hand and integrated together (e.g., crashes and analytics in the same place, notifications tied to Firebase auth, etc.) saved me a ton of time. Time-to-market +1, clearly.

Where things start to get stuck...

Of course, it's not all rosy. As TaleMe moved from a simple POC to a product in production with real users, I discovered certain limits and pitfalls of my "all Firebase" choice. Here are the main friction points I encountered:

📦 A POC that becomes prod (aka the technical debt of "all Firebase")

At first, I structured my app pretty simply, prototype style. All the logic revolved around Firestore (my NoSQL DB) and a few Cloud Functions. Honestly, at the time I didn't think much about architecture: Firebase somewhat encourages "plug and play". Except that over time, this approach caught up with me.

What worked perfectly in MVP mode became more complex as I added features. The business logic (AI story generation, content management, etc.) ended up split between Flutter client code and Cloud Functions server-side. It's the "everything in Firebase" syndrome: you start fast, but you can quickly end up with a mix of Firestore security rules, serverless triggers, and client code that's not very modular.

To give a concrete example: initially, file uploads (images/videos generated by AI) were done directly from the client to Firebase Storage. Simple… but insufficient when I wanted to verify the user, process media server-side (transcription, thumbnail…), and call the OpenAI API securely. I had to implement upload via an HTTP Cloud Function that receives the file and performs these processes before storing everything. Technically it works very well (I even wrote a tutorial on this topic), but it illustrates how a small front POC ends up needing a substantial backend. I found myself accumulating Cloud Functions to work around the limits of "all client" (and juggling between the app's Dart code and the functions' TypeScript).

🔄 Cloud Functions: two ecosystems to maintain

Let's talk about Firebase Cloud Functions. It's a great feature (trigger backend code without managing a server, a dream!), but I discovered a drawback for a Flutter dev: all functions must be written in JavaScript/TypeScript (or Python, in beta) - not in Dart. In short, it's impossible to share code between my Flutter app and my Firebase backend; I had to maintain two codebases in two different languages. When you're working alone, this constant context switching has a cost in speed and reliability.

In my case I knew JS and TS, but having to rewrite certain data structures or validation rules in TS on the server side, while they existed in Dart on the client, was frustrating. Not to mention the different testing tools, the less comfortable debugging (Cloud Functions logs vs debugging directly on the Flutter emulator, not the same story).

In short: adding Cloud Functions everywhere was necessary, but over time I felt a growing technical debt and complexity to evolve the backend.

A POC can become a "small factory" if you're not careful.

🗄️ NoSQL model & vendor lock-in

Firebase = Firestore (NoSQL) and I didn't fully measure the impacts at first. I was seduced by NoSQL flexibility: no fixed schema, store JSON documents and decide later.

Very cool while prototyping.

But as the app matured, I felt the limitations of a NoSQL database for more structured data. For example, I had to run increasingly complex queries (joining collections, filtering by multiple fields, etc.) and Firestore isn't very fond of that. You end up duplicating data to compensate for the lack of real joins, multiplying small client-side queries and handling consistency yourself.

As the Supabase doc sums up: “Firestore's schemaless design makes it easy to prototype. As data relationships grow more complex, you must handle joins in the client or denormalize your data.”. So true! In hindsight, some TaleMe data would probably have lived better in a classic SQL database...

Speaking of Supabase, it's impossible not to mention Firebase vendor lock-in. When you start, you don't think much about it ("we'll see if it scales").

But in 2025, with a growing user base, I realize how all my data and logic are dependent on Google Firebase. Migrating elsewhere (say to a custom server or another BaaS) would be a colossal project. It's not just a feeling: exporting Firestore data to an SQL database is far from simple (even if there are migration tools to Supabase or AWS).

The dependency on the Firebase ecosystem is real: proprietary APIs (Firestore, FCM, etc.), specific security rules... The more time passes, the harder it becomes to "get out", so you stay, sometimes enduring technical compromises.

I'm seriously thinking about this today (hence this article).

💸 Hidden costs: the bill in terms of performance and budget

Last point, and not the least: Firebase is not free forever, and its billing can become a mental headache. In the beginning, everything ran within the free tier.

But success (even modest) means usage increases, and then you start watching your Firestore reads/writes, Cloud Function invocations, storage, bandwidth, etc.

Firebase's pay-as-you-go billing is not always predictable, and unpleasant surprises are possible if you don't optimize.

For example, a poorly crafted query that multiplies document reads can blow up the counter. Or a Cloud Function called too often can exceed free quotas. Experience reports are abundant: “Firebase's pricing can become expensive as your application scales, leading some developers to seek more cost-effective alternatives…”.

In my case, I haven't (yet) blown the budget, but the mental load of always thinking "cost optimization" is real. I spent time fine-tuning cache rules, batching writes, monitoring usage dashboards to avoid a cold shower at the end of the month. Time not spent developing features.

On the performance side, I also had to deal with Firestore limits (no full-text queries, indexes to configure or some queries will fail or be slow). And the infamous cold starts of Cloud Functions added latency on some pages.

Nothing insurmountable, but an accumulation of small "frictions" that makes me, in 2025, much more aware of the real costs of Firebase, both financial and cognitive.

What changes in 2025

Two years have passed since the initial launch, and naturally my perspective has evolved. In 2025:

• Skill growth: I'm not the same dev as in 2023. After tinkering with Flutter/Firebase and evolving TaleMe, I've learned a lot about mobile, mobile app architecture, etc. I gained expertise and confidence on topics that seemed complex in 2023.
• AI as co-pilot: The dev landscape has also changed. We're in the middle of the AI Copilot revolution - which makes life easier for solo devs. Need to generate a piece of backend code in Express, write a migration script, find a SQL query? AI agents can do a lot of the heavy lifting. What felt overkill to code from scratch in 2023 is less so in 2025 because we're better equipped.
• New priorities: testability, portability, robustness: With hindsight, I place more importance on certain architectural aspects. For example, testability - in 2023 I tested my Cloud Functions little (hard to mock Firestore), now I dream of a backend where I can easily write unit and integration tests. Same for portability and robustness: I saw the limits of lock-in and overly proprietary solutions, so I aim for more open technical choices (standard SQL DB, possibility to deploy on another cloud, etc.). In short, I seek to build more sustainable and maintainable foundations, even if it means sacrificing some initial speed. It's the eternal dev trade-off: what saves time initially can make you lose more later.

In summary, my view has changed: Firebase remains a great tool, but I now see it as one building block among others, to be used deliberately in a thought-out architecture rather than as a "magic" package that does everything without consequences.

From there, what are my recommendations in 2025 for a solo mobile dev choosing a stack?

My current recommendations (solo dev in 2025)

If I had to advise an independent developer starting a mobile app today, here's how I would approach the backend stack:

Option 1: Firebase + dedicated backend combo (best of both worlds)

This is probably the architecture I'd adopt for any somewhat ambitious new project. The idea: use Firebase for what it does best, and delegate the rest to a "home" backend (or a dedicated microservice). In practice, for example, keep Firebase Auth (so convenient and robust), Cloud Messaging (for push) and maybe Crashlytics/Analytics.

But for advanced business logic, sensitive processing (calls to third-party APIs like OpenAI, complex computations, etc.) and fine-grained data management, I would deploy a small separate REST/GraphQL API backend.

This can be a Node/Express server, NestJS, Python FastAPI, whatever - the important thing is the freedom to code the logic cleanly without the constraints of Cloud Functions.

This backend could use a classic SQL database or any storage suited to the needs.

Firebase and this backend would communicate via HTTPS calls or similar. Yes, it requires a bit more work than full Firebase... but it avoids twisting Firebase into shapes for things it's not optimal at.

You keep the time-to-market on generic bricks thanks to Firebase, while having full control over the core business. Solo in 2025, this is totally doable thanks to modern tools (you can prototype an API in a few days now, with AI assistance especially).

Option 2: Supabase (or other SQL-based BaaS) for a more open backend

Another relevant choice in 2025: turn to a BaaS alternative to Firebase, based on SQL. The main candidate is Supabase, which reproduces the Firebase experience (auth, storage, functions serverless, realtime…) but on a PostgreSQL open-source base. Supabase basically offers "the same services - auth, storage, realtime, functions - but with the predictability of SQL and the freedom of self-hosting".

Put differently, you get a classic relational schema (so powerful queries, joins, ACID transactions, etc.), you can host the solution yourself if you want (no proprietary lock-in), and you keep comparable features (realtime abstraction, auto-generated API, etc.).

For a solo dev starting out, Supabase can be an excellent compromise: you find the simplicity of a BaaS without some Firebase limits. Of course, you need to be more comfortable with SQL than with NoSQL, and the Supabase ecosystem is a bit less mature (younger, smaller than Firebase). But honestly, the learning curve of SQL/Postgres is worth it as soon as you have somewhat structured data.

There are other similar BaaS (Appwrite, PocketBase, Parse... even cloud solutions from the big players like AWS Amplify), but Supabase stands out today as a Firebase replacement among devs. In 2025, I'd seriously test it if I were starting TaleMe from scratch - if only to avoid lock-in and benefit from a relational database from the start.

Option 3: Stay on Firebase, but decouple properly

And if despite everything you want to fully leverage Firebase (after all, its integration with Flutter remains excellent, and for a small app you can live with its constraints), I would advise doing so while anticipating the future. That means: decouple your business code from Firebase itself as much as possible.

Concretely, even staying on Firestore and Cloud Functions, adopt architectural best practices: use repositories in the Flutter app to isolate Firebase calls (instead of scattering .doc().get() all over the UI code), structure Cloud Functions modularly (avoid a single huge 1000-line function that does everything), write unit tests with the Firebase Emulator Suite to validate security rules and functions, etc.

The goal is to make an eventual change possible (or less painful). For example, if your data access layer is well isolated, migrating from Firestore to Postgres will only require changing that layer, not the entire app.

Likewise, if your business logic is in well-encapsulated functions, you could reimplement them on another backend without rewriting everything. In short, "staying on Firebase doesn't mean locking yourself in". It's a classic trap to dive headfirst and sprinkle Firebase everywhere in your code. In 2025, with experience, I'd try to design a clean architecture from the start even on Firebase: a bit of design today for a lot of freedom tomorrow.

What I would do differently for TaleMe (if I had to do it again)

To be very concrete, if I could go back in time and advise my 2023 self on the TaleMe project, here's what I'd change (and keep) regarding Firebase:

What I would keep without hesitation:

• Firebase Authentication - It's a huge time-saver and ultra reliable. Handling signup, login (email, Google, Apple…), password recovery, etc., myself would have been a waste of time and a security risk. Firebase Auth does the job perfectly; I'd reuse it in 2025.
• Crashlytics & Analytics - Essential for any app in production. Integrated for free, these services allowed me to detect crashes (Crashlytics) and understand usage (Analytics) easily. I'd consider them must-haves regardless of the backend.
• Flutter + Firebase (client integration) - The FlutterFire SDK on the client is well maintained and lets you leverage Firebase's power with very little code. If I need realtime (e.g., sync live data between users) or to store simple data, Firestore remains very handy via Flutter. Same for Firebase Cloud Messaging (push notifications) which I wouldn't hesitate to reuse via FlutterFire.

What I would change or avoid:

• Avoid basing everything on Firestore for structured data: If I could redo it, I'd probably introduce a SQL database as soon as the app's data becomes relational (e.g., users, stories, chapters, etc. with relations). Even if it means maintaining two databases (Firestore for realtime on some small data and Postgres for the rest), or moving everything to a Supabase-type DB. The goal: not suffer long-term querying and structure limitations of Firestore.
• Don't put all logic in Cloud Functions: I'd opt for a separate backend (even light) to implement complex business logic. For example, AI story generation could have been developed in a small separate Node or Deno API, called from the app, rather than shoehorning it into a Firebase Cloud Function. That would have given me more control (independent deployment, unit testing possible, etc.) and avoided mixing NodeJS and Dart in the same project.
• Anticipate architecture from V1: In 2023, I kind of skipped that ("YOLO, ship and we'll see later"). In 2025, I'd force myself to define a few architecture guidelines from the start: clear modules, separation of responsibilities between frontend and backend, testing plan, security and validation strategy, etc. No need to spend months, but a few days of thinking. In short: the problem wasn't Firebase itself, but using it without a real architecture behind it.

Conclusion

In retrospect, Firebase was not the "problem": it was actually the ideal solution to launch TaleMe quickly and validate the concept.

Its benefits (development speed, integrated services, automatic scalability) clearly allowed a solo dev to reach V1 goals.

However, what I learned is that not making an architectural choice is a choice in itself... and often the wrong one. By relying too much on Firebase's comfort, I accumulated technical debt and constraints that could have been avoided with a bit more foresight.

The good news is that in 2025 we have more options than ever to build mobile backends: we can mix Firebase services with custom code, opt for alternatives like Supabase to regain SQL control, and use AI to help us code more efficiently…

The important thing is to keep the application's sustainability in mind: Firebase is an excellent accelerator, provided you know how to brake in time and build solid foundations around it.

And you, what's your experience with Firebase (or its alternatives)? Have you also experienced the "100% Firebase" MVP syndrome that needs refactoring later, or did everything go smoothly? Share your feedback in the comments, I'm interested!