Firebase.
Google’s app platform for sign-in, live data and push notifications, with no servers to run.
Talk to us about Firebase
Key features
What Firebase does well.
Offline-first Firestore
The client SDKs cache data on the device, so the app keeps working without signal and syncs when it reconnects.
Security rules
Access to Firestore and Cloud Storage is decided by rules on Google’s servers, checked on every read and write.
Local Emulator Suite
Auth, Firestore, Functions and Storage run on a laptop, so rules and functions can be tested without touching production.
SQL Connect
Formerly Data Connect, it links apps to a managed Cloud SQL for PostgreSQL database with generated, typed SDKs.
What we build with it
Sign-in, live data and notifications on day one.
Firebase gives a web or mobile app authentication, a real-time document database, file storage, push notifications and serverless functions, all run by Google. We reach for it when a team needs users on a product quickly. Most of the care goes into security rules and data structure, since both get harder to change once real users arrive.
Live features
Chat, status updates and shared lists that change on every device at once through Firestore listeners.
Push notifications
Cloud Messaging for iOS, Android and the web, sent from Cloud Functions when data changes.
A first release that can grow
Rules and data structure set up so the product can scale on Firebase, or move off it later.
When it’s the right choice
Firebase suits mobile-first products and apps where each user mostly works with their own data, especially when nobody on the team wants to run servers.
When we’d pick something else
Firestore makes reports across many related records awkward. When those matter, we look at Postgres instead, either through Firebase SQL Connect or with Supabase.
Our Firebase services
How we can help.
New Firebase apps
Web and mobile apps on Firebase, with data structure, security rules and budget alerts set up before launch.
Security rules audit
Testing existing rules against real access patterns to find data that is readable or writable by the wrong users.
Cost review
Tracing where reads, writes and function calls come from, then reshaping queries and listeners that cost too much.
Migration off Firebase
Moving users and data to Postgres, Supabase or your own back end in stages, with the app working throughout.
How we work
Starting a Firebase project.
Review what exists
Code, data, hosting and the people who maintain it, before any Firebase decision is made.
Agree the approach
A written scope: what changes, what stays, the risks and how we will know it worked.
Build in reviewable slices
Working increments your team can test, rather than one large delivery at the end.
Hand over or stay on
Documentation and access for your team, or a defined support scope if you want us to keep going.
Where AI fits
AI in back-end work.
Model calls from your services
Node.js, Go and Python all have official SDKs from the major model providers, so AI steps sit inside your existing services.
AI workflow automation ↗Evaluation pipelines
Python’s data tooling makes it the usual choice for scoring a model against real examples before and after release.
AI evaluation & testing ↗
Where it stops: Retries, timeouts and fallbacks matter more for model calls than for most APIs, and every result that changes a record is validated first.
Where it fits
Related expertise.
- Prototyping & validation Test the key task with the people who do it, using a prototype, before committing engineering time.
- Mobile app development iOS and Android apps that work offline, handle device permissions well and ship through the app stores.
- APIs & integrations Connect your product to the systems your team relies on, with clear contracts and handled failures.
Common questions
Firebase questions.
Will Firebase get expensive as we grow?
It can. Firestore charges for each document read and write, so we shape queries to read only what a screen shows, set budget alerts and estimate costs from expected usage before launch.
Can we move off Firebase later?
Yes, with some planning. User accounts and Firestore data can both be exported. Keeping business rules in your own functions, not in the app, makes a later move much smaller.
Further reading
- Firebase, Supabase or a custom back end: how to choose How to choose between Firebase, Supabase and a custom back end by data shape, access rules, cost, exit paths and skills.
- Awaab’s Law and the software landlords use for repairs What Awaab’s Law asks of the systems social landlords use to log, investigate and repair hazards, and the records they need to keep.
- Offline-first mobile apps for people who work without signal How to plan a mobile app that keeps working without signal, and what to settle before the first line of sync code.