How I Use Firebase in Production Without the Bloat

Firebase is the default backend for a lot of solo Android developers, and for good reason — it removes the need to run servers for a long time. But it's also a buffet, and loading your plate with every service is how apps get bloated and bills get surprising. After using it across many production apps, I've settled on a small subset that earns its place and a longer list I skip.

Crashlytics Is Non-Negotiable

If I add only one Firebase service, it's Crashlytics. You cannot fix crashes you don't know about, and users overwhelmingly uninstall rather than report. Crashlytics turns a silent uninstall into an actionable stack trace with device and OS context. It's lightweight, and the visibility it gives into what's actually breaking in the field is worth more than almost anything else on the list. The first thing I check after a release is the Crashlytics dashboard, and it's caught regressions I'd never have reproduced locally.

Analytics, Used With Restraint

Firebase Analytics is useful, but it's easy to over-instrument and end up with hundreds of events nobody looks at. I log a handful of events that map to real questions: did the user complete the core action, did they hit the paywall, did they convert. That's it. The discipline is logging events tied to a decision I'll actually make, not logging everything "in case." Restraint here also keeps me honest about privacy — every event is data I'm responsible for and have to declare in the Play Store data safety section.

Remote Config for Kill Switches

The single most valuable thing Remote Config gives a solo developer is a kill switch. When a feature misbehaves in production, being able to disable it without shipping an update and waiting for review has saved me real grief. I keep a small set of flags — feature toggles and a couple of safety switches — rather than configuring the entire app remotely. Over-using Remote Config turns your app's behavior into something you can't reason about from the code alone, so I keep it to the things I genuinely need to change without a release.

Auth and Firestore Only When Needed

Firebase Auth and Firestore are powerful, but they're also where apps quietly take on real complexity and cost. Many of my apps are local-first and need neither — data lives in Room on the device, and there's no account at all. I add Auth and Firestore only when a feature truly requires accounts or cross-device sync, never by default. A local-first app is simpler, more private, works offline, and has no backend bill. When sync is a genuine user need I'll reach for them, but I make the app justify the backend rather than assuming it.

Watch the Bill and the Size

Two things creep if you're not watching: the app's binary size and the monthly bill. Each Firebase SDK adds to your APK, so I only include the ones I use and let R8 strip the rest. On cost, the free tiers are generous but not infinite, and a runaway query pattern or chatty analytics can move you into paid territory faster than expected. I check usage periodically rather than discovering it on an invoice. The whole point of using Firebase as a solo developer is to stay lean and avoid running infrastructure — defeating that by bloating the app with unused services is the trap to avoid.

The principle underneath all of these choices is to add a service only when you can name the question it answers or the problem it solves. Crashlytics answers "what's breaking in the field." Remote Config answers "how do I turn this off without a release." When I can't articulate the concrete need a service meets, that's the signal I'm adding it out of habit or fear of missing out, not because the app requires it. Firebase makes it frictionless to bolt on more, and that frictionlessness is exactly the danger — each addition is free to enable and not free to maintain, declare, and ship. Lean is a decision you have to keep making, not a default you get for free.

Key Takeaways

• Add Crashlytics first; field crash visibility is the highest-value Firebase service for a solo developer.
• Log a small set of analytics events tied to real decisions, not everything "in case" — it's cleaner and more privacy-respecting.
• Use Remote Config mainly for kill switches and a few flags, not to configure the whole app remotely.
• Stay local-first with Room where you can; add Auth and Firestore only when accounts or sync are genuinely required.
• Watch APK size and the monthly bill — include only the SDKs you use and check usage before it surprises you.