Firebase app development

What Firebase does, and when it is the right choice

Firebase is Google’s set of ready-made back-end services for mobile and web apps: authentication, the Firestore database, file storage, serverless functions, push notifications (Cloud Messaging), usage analytics, crash reporting and remote configuration (Remote Config). All of it works without setting up or running servers, so it gets a new app to its first release quickly.

Where Firebase fits well

You want to ship the first release without setting up and running servers
You have screens that must update instantly, such as a chat or an unread-message counter
Once the app is in the stores, you want to watch it through crash reports and usage data
You want to switch some screens or offers on and off without shipping an app update

Where we would not suggest Firebase on its own

Your records have many relationships and you need reports from them (students, classes, exams, payments): here we suggest PostgreSQL
The data must stay on your own server: Firebase is a service run by Google
You need costs to be predictable as a fixed server price rather than a count of reads and writes

Which parts of Firebase we use, and where

Firebase is not one thing; in each product we install only the modules it needs. SoruVerse uses Firebase’s web SDK with Expo, while Rigel and LydiaVault use the React Native Firebase library.

Module	What it does	Where we use it
Authentication	Email and password, phone verification, Google and Apple sign-in	SoruVerse, Rigel, Hippotenus (web)
Cloud Firestore	A document database; screens see changes instantly	SoruVerse
Cloud Functions	Server code: triggers that run when data changes, and functions the app calls	SoruVerse
Cloud Messaging	Push notifications	Rigel, LydiaVault
Analytics and Crashlytics	Usage events and crash reports	Rigel, LydiaVault
Remote Config	Changing settings and flows without shipping an update	Rigel, LydiaVault

How we set it up in our products

In SoruVerse the chat list and the unread-message counter listen to Firestore, so the screen updates by itself when a new message arrives. A Cloud Function that runs when shared content is approved credits reward points to its author, and only on the change from unapproved to approved. Course files sit on Cloudflare R2: when the app wants to open one, it asks a callable function for a short-lived signed link, and the function turns away anyone who is not signed in.

Rigel and LydiaVault read a settings bundle from Remote Config at launch. LydiaVault uses it to set the minimum supported version per platform and whether the onboarding paywall and sign-in screen are shown; Rigel uses it to choose which version of the onboarding flow opens and whether the paywall shows a close button. These decisions change without waiting for store review. In both products the back end sends notifications with the Firebase Admin SDK.

React Native Firebase

Access to Firebase’s native iOS and Android SDKs from React Native. We use it in Rigel and LydiaVault.

Firebase Admin SDK

Verifying ID tokens and sending notifications on the server. We use it in the server code of Rigel, LydiaVault, Hippotenus and SoruVerse.

Cloudflare R2

Object storage for large files, served through signed links. We use it with Cloud Functions in SoruVerse.

RevenueCat

For subscriptions, with Remote Config deciding how the paywall appears in onboarding. We use it in Rigel and LydiaVault.

When to move off Firebase, or not go all in

You don’t have to use Firebase for everything. In Hippotenus, Firebase only provides Google and Apple sign-in: the API verifies the ID token Firebase issues and opens its own session, and user records and all other data stay in our own PostgreSQL database. In Rigel, too, authentication, notifications and analytics are on Firebase while the business logic lives in a separate serverless back end. Signs that a Firebase app is ready for this kind of split:

You join several collections in application code to produce one report
The bill, driven by reads and writes, has become hard to predict
Security rules have become unreadable because of the business rules they carry
The data needs to stay in a particular country or on your own server

The move usually happens in pieces rather than all at once: authentication, notifications and crash reporting stay on Firebase while data and business rules move to your own API.

How a Firebase project runs

01
Free scoping call
30 min
We talk about who the app is for, what data it will keep, and whether Firebase or your own server suits it better.
02
Written scope and quote
We write down the Firebase modules to use, the data structure, who can access which data, and the acceptance criteria.
03
Weekly releases
Every week you try the new build on your own device; your feedback sets the next week’s priorities.
04
Testing and release
A senior QA tests the build before release, and the access rules are part of that testing.
05
The 30 days after launch
30 days
We fix the bugs that surface in this period free of charge; after that you can continue with monthly maintenance.

Timelines and budget ranges are published on our mobile app development, MVP and pricing pages; everything on this page follows the same figures.

Questions about Firebase

Is Firebase free?

There is a free tier to start with; as usage grows you are billed for reads, writes, storage and function runs, and some services such as Cloud Functions need the pay-as-you-go plan. We go through the expected cost for your usage during discovery.

Is my data safe on Firebase?

Who can reach which data is set with Firestore security rules or by verifying the ID token on the server. In Rigel and Hippotenus, when a user signs in through Firebase, the back end opens no session without verifying the ID token Firebase issued; in SoruVerse file links are given only to signed-in users.

Can I move from Firebase to my own server later?

Yes, and usually in pieces rather than all at once. As in Hippotenus, authentication can stay on Firebase while the data lives in your own database; we plan which part moves when, together.

What do I keep when the project ends?

A perpetual licence to use the software and user documentation. If you want the source code transferred to you, that is possible for an extra fee, stated separately in the quote.

Firebase app development

What we have built with it

SoruVerse

Rigel

LydiaVault

Hippotenus