We use parts of Firebase in nearly every app, and keep your records out of it.
Firebase arrives as a bundle, and that is the source of most of the trouble people have with it. Some pieces of it are the plain right answer and we reach for them without thinking. Others quietly become the place your business data lives, which is a decision nobody meant to take.
So this page is split down the middle. What we use it for, and what we use a database for instead.
Firebase is a set of Google services an app can talk to directly without you running a server for them. Sign-in, a hosted database, file storage, push notifications, crash reports and usage analytics. You pay by how much you use, and there is a free level that covers a small app comfortably.
Where it earns its place.
The parts we use without hesitating
These do a job that would otherwise take weeks. None of it would make you distinctive.
- Cloud Messaging, for push notifications on Android and iOS
- Crashlytics, so a crash on a customer phone reaches us with the details
- Analytics, to see which screens anybody actually opens
Push notifications, in practice
Everybody needs this one. It is also the one that fails silently, and most of the work is not the sending.
- Tokens stored against the person and refreshed when the phone changes them
- The Apple key and permission prompt, without which iOS delivers nothing
- Deciding what happens when the phone was off for two days
A notification nobody reads is worse than none. We push back on the alert that fires for every ordinary event, because that is how a customer turns them off for good.
Sign-in
Firebase Authentication handles phone, Google and Apple sign-in, and is worth using when the alternative is writing your own.
- Phone sign-in with a one-time password, which is what Indian customers expect
- Google and Apple sign-in, where Apple is required if Google is offered on iOS
- Your own permissions still decided by your server, not by the sign-in provider
The one-time password messages are charged per message. That cost is small per user and surprising in bulk, so it is worth putting in the estimate early.
Where the records belong
Firestore is a fine place for a chat thread, a live location or a draft. It is a poor home for the ledger.
- Invoices, stock, payments and ledgers in a relational database
- Reports that read across years, which Firestore was never built to answer
- Rules enforced once in your API, not twice in two different systems
- Charges that grow with every read, including the screen that reloads a list
The common shape we build is your own API and PostgreSQL holding the records, with Firebase doing messaging, crash reporting and sometimes sign-in.
Handing the project over
- Project
- Keys
- Messaging
- Crash reports
- Analytics
- Handover
- The Firebase project opened under your own Google account
- Notifications working end to end on both platforms, tested on real phones
- The console access handed to you, with a note on what each part costs
When this is the right choice.
- A mobile app that needs push notifications, which is nearly all of them
- Wanting to know why an app crashed on a phone you will never hold
- Phone or Google sign-in, where writing your own brings risk and no advantage
- A prototype or a pilot that has to be in somebody’s hands quickly
- Live features such as chat, presence or a moving location on a map
When it is not.
- The system of record for invoices, stock or payments, which belongs where you can report on it
- A reporting-heavy application, because the questions you will ask later are the ones Firestore does not answer
- A screen that reads the same list over and over, since every read is charged and a careless screen is expensive
- A business that must keep its data on its own servers for a policy or contractual reason
- Replacing your own permission rules, because a second set of rules in the console will drift from the first
Questions we are asked about it.
Is Firebase free?
There is a free level that a small app will sit inside for a long time, and after that you pay for what you use. The charges that surprise people are reads on a busy screen and one-time password messages.
Should we build the whole app on Firebase?
For a prototype or a very simple app, it is a reasonable shortcut. For a business system with reporting, permissions and money in it, we would keep the records in your own database and use Firebase for messaging and crash reports.
Can Firebase work alongside our own backend?
Yes, and that is how most of our apps are built. Your API and database hold the records and decide the rules. Firebase delivers the notification, reports the crash, and sometimes verifies the phone number at sign-in.
Our notifications do not arrive on iPhones. Why?
Usually the Apple key, the notification permission never being asked for, or the app being built with the wrong profile. It is a short list and we work through it on a real device. Android delivering fine while iOS stays quiet is the usual symptom.
Can we move off Firebase later?
Messaging and crash reporting can be swapped with a few days of work. Sign-in takes longer because accounts have to be moved and people re-verified. Data in Firestore is the expensive one, and that is why your records stay in a database of your own.
Can you add Firebase to an app somebody else built?
Usually yes, if we can get the source and the signing keys. Adding messaging and crash reporting is small, contained work, and the reports often pay for it in the first week.
Services that use it.
What it sits with.
Not sure Firebase is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private