---
title: "Firebase | Skills We Assign For | Azendo"
description: "Firebase as a mobile backend — what it removes, where costs and lock-in appear, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/firebase/"
---

[Skills](https://azendo.co/skills/) Mobile platforms and frameworks 

# Firebase.

Firebase is Google's mobile backend platform: authentication, real-time and document databases, storage, push messaging, crash reporting, analytics and remote configuration, consumed as managed services rather than operated.

## Where Firebase fits on a long engagement.

Firebase's value is how much it removes. Authentication, push, crash reporting and analytics are each a real piece of engineering, and getting all four working in a week is a genuine advantage for a product that needs to reach users before it needs to be architecturally pure.

Two costs arrive later. Pricing is usage-based in ways that are hard to model in advance — Firestore bills per document read, so a poorly shaped query is a bill rather than a slow page — and security rules are a real access-control language that is regularly written permissively and never revisited. Both are cheap to handle deliberately and expensive to discover.

## What an assigned team does with Firebase.

Security rules deserve the same review as any other authorisation code, because that is what they are. Rules that were permissive during development and never tightened are one of the more common serious findings on a mobile estate.

Reviewing them properly, and keeping them reviewed as the data model changes, is continuous work assigned alongside the application capacity rather than treated as a launch task. How that responsibility is framed is described in [how an assignment runs](https://azendo.co/how-it-works/).

## What we use Firebase for.

* Reaching users before building a backend Authentication, push and crash reporting in place without operating any of it.
* Query shapes that control cost Data modelled for the reads the app actually performs, because reads are the bill.
* Security rules as real access control Rules reviewed and tested rather than left permissive from the prototype.

## How Firebase capacity is assigned.

Firebase work sits inside mobile capacity. Where the backend outgrows it, migration planning is scoped under [devops managed services](https://azendo.co/services/cloud-and-devops/) alongside the application work.

## Roles we assign Firebase for

* [Flutter Developer Mobile development](https://azendo.co/services/mobile-development/flutter-developer/)

## Service lines it sits in

* [Mobile development](https://azendo.co/services/mobile-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in mobile platforms and frameworks

* [SwiftUI — skill we assign for](https://azendo.co/skills/swiftui/)
* [UIKit — skill we assign for](https://azendo.co/skills/uikit/)
* [Jetpack Compose — skill we assign for](https://azendo.co/skills/jetpack-compose/)
* [Coroutines — skill we assign for](https://azendo.co/skills/coroutines/)
* [Flutter — skill we assign for](https://azendo.co/skills/flutter/)
* [React Native — skill we assign for](https://azendo.co/skills/react-native/)
* [Expo — skill we assign for](https://azendo.co/skills/expo/)
* [Ionic — skill we assign for](https://azendo.co/skills/ionic/)

## Tell us what your roadmap needs Firebase for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)