App development on Firebase™

Quick to start,
careful as it grows

We build apps on Firebase for web and mobile, with sign-in, Firebase Security Rules tested on every change and data shaped for each screen, so every request meets a rule you can read.

Thanks, we’ll be in touch soon.

{{ heroStatus }}

You’re in good company

A few of the companies we’ve worked with.

When the app talks straight to the database

On the Firebase platform, an app’s screens can read and write its data and files directly, with no server of your own in between. That’s much of what makes it quick to build on.

It also means the rules are the back end’s front door. Rules written while testing, or never tightened since, can let in more than anyone meant.

Each read is billed, too, so a screen that reads more than it shows costs more than it needs to. And the platform retires features with notice, so each project needs to know what it uses.

So the work that matters is the rules, the shape of the data, and keeping up. How much that takes varies with each app and the way it grew.

What we build

Every change to the rules, the data and the code is tested on the Firebase Local Emulator Suite, and a person reviews it before it reaches your users.

  • New apps

    Web and mobile apps with sign-in, data and files from the first commit, their rules and tests written alongside them.

  • Sign-in

    Sign-in methods set up in Firebase Authentication, and each person reaching only what’s theirs, on every screen and in the data behind it.

  • Rules, tested

    Firebase Security Rules written with the data model, tested on the emulators for every change, and deployed with the app.

  • Data shaped for each screen

    Collections, the groups of records an app reads, planned around the screens that read them, with the indexes their queries need, so each screen reads what it shows.

  • Offline, then in step

    Apps that keep working without signal and catch up when it returns, with the offline cache in Cloud Firestore: on by default on phones, and turned on for a web app where it fits.

  • Server code where it belongs

    Work the app shouldn’t do itself, such as payments, emails and anything that needs a secret, in Cloud Functions for Firebase or a back end of your own, its secrets kept on the server.

  • AI features, kept to your app

    AI features through Firebase AI Logic, with Firebase App Check, which helps make sure only your own app can call them.

  • Moves, and retired features

    Data and sign-in moved onto the Firebase platform, and features it is retiring moved to what replaces them, each on a branch.

  • Checks on every change

    Rules, functions and indexes tested on the emulators in CI, and deployed from there once they pass.

Every request meets the rules first

Firebase Security Rules sit between the app and its data and files. The platform checks every request, each read or write the app makes, against them on its own servers, never in the app, so the app is never the part that enforces them.

A rule can check who’s asking, what they’re asking for and what they send: which fields of a record, one item of the app’s data, a change may touch, or, in Cloud Storage for Firebase, an upload’s size and type and the folder it’s going to.

Server code works differently. It uses keys that are kept secret on the server, as the Firebase security checklist asks, so it runs only there, with checks of its own written into it.

So we write the rules with the data model, test them on the emulators for every change, and deploy them with the app.

Below is one rule from an app of our own, in plain words: the photo folder of one signed-in member.

Try any file. It’s checked here, in your browser, for its type and size only: nothing is uploaded or kept.

A member’s photos

The rule for this folder

  • Signed inPassesStops here
  • Their own folderPassesStops here
  • An imagePassesStops here
  • Within the size this app allowsPassesStops here

This member is signed in and in their own folder, so the first two always pass.

or drop one on this card

The file

{{ rlKind }}

The answer

Stored in their folder.

Refused: only images are stored here.

Refused: larger than this app allows.

{{ rlSay }}

Every change comes with a way forward

The Firebase Release Notes list each new SDK release and each change to the platform’s services, and a retirement there comes with its date and its way forward.

Products are renamed: Firebase Data Connect is now Firebase SQL Connect, with all its features and the same APIs, so existing integrations keep working.

Products are retired with notice. Firebase Extensions is set to be retired on March 31, 2027: extensions already deployed keep running, but after that date they can’t be updated, reconfigured or uninstalled, and function kits in Cloud Functions for Firebase are the way forward. Firebase ML is set to shut down on June 15, 2027, and Firebase Test Lab on September 30, 2027.

The SDKs take new major versions, each with its own release notes.

So we keep a list of what each project uses against those notes, and move each piece on a branch, tested on the emulators, before its date.

Start with the rules and the bill

The review covers the Firebase products in use and the SDK versions on each platform; the Security Rules for Cloud Firestore, Firebase Realtime Database and Cloud Storage for Firebase, and whether they’re tested; which apps use App Check, and whether it’s enforced; sign-in methods and account settings; API keys and their restrictions; server code: Cloud Functions, the Firebase Admin SDK, service accounts and secrets; the data model, its indexes and what each main screen reads; offline settings on each platform; budgets, alerts and the billing plan; separate projects for development and production, and who can reach each; features being retired: Firebase Extensions, Firebase ML, Firebase Test Lab and Firebase Dynamic Links; the copies kept of the data, and exports; Firebase Crashlytics, Firebase Performance Monitoring and Firebase Cloud Messaging, where they’re used; and deploys from CI for rules, indexes and functions.

The first step is one of these, each tried on a branch: one collection’s rules tightened, with tests on the emulator; App Check turned on for one app and watched before it’s enforced; budget alerts set, and one busy screen’s reads matched to what it shows; one extension moved to a function kit or to code of your own; or separate projects for development and production.

What you receive is a written review and a proposal for that first step.

Questions worth asking

  1. Is it the right platform for our app?

    Where an app needs sign-in, data that changes as people use it and phones that keep working without signal, often yes. Where most of its work is reporting across all of its data at once, a relational design may suit it better, and we’ll say so.

  2. Do we still need a server?

    Often less of one. Work that needs a secret, or mustn’t be left to the app, runs in Cloud Functions for Firebase or a back end of your own.

    Node.js Development

  3. How do you keep our data private?

    With rules written with the data and tested on every change, sign-in, App Check, and access to each project kept to the people who need it.

    Application Security

  4. What will the app cost to run?

    That depends on what it reads, writes and stores. Each read is billed, and a listener on a whole collection reads more than a screen needs, so we look at what each screen reads and set budget alerts, so you hear when spending passes what you planned.

  5. Can it work offline?

    Yes, with the offline cache in Cloud Firestore. Phones have it on by default; a web app turns it on where it fits, and asks first whether the device is trusted when the data is sensitive. Changes made offline catch up when the signal returns, and where two changes meet the same record, the last one saved wins, so we plan for that.

  6. Which of its databases fits our data?

    Cloud Firestore stores and syncs data in a NoSQL database with rich data models and queries; Firebase Realtime Database stores and syncs data in realtime; Firebase SQL Connect is a managed relational database. We suggest the one that fits your data.

  7. Can we move off it later?

    Yes, with planning. Data in Cloud Firestore can be exported, and so can the accounts in Firebase Authentication, so a move is planned, not trapped.

  8. What about the features being retired?

    Firebase Extensions is set to be retired on March 31, 2027: extensions already deployed keep running, but can’t be updated, reconfigured or uninstalled after that, and function kits are the way forward. Firebase ML is set to shut down on June 15, 2027, and Firebase Test Lab on September 30, 2027. We move each piece on a branch, tested, before its date.

  9. Can we add AI features?

    Yes, through Firebase AI Logic, with App Check enforced, as the platform now sets it up when AI Logic is started in its console.

    AI Services

  10. Can you take over our existing project?

    Yes. First we read your project on Firebase: its rules and their tests, sign-in, the data model and what each screen reads, its functions and how it’s deployed. Then one person on our side owns a first piece of work we agree with you, alongside any developers you already have.

    Support & Maintenance

  11. What does it cost?

    That depends on your app and the first step you choose. Before any work starts, you get a written proposal with the scope, the price or rate, and how you pay.

    Pricing

  12. Can AI assistants help with our code?

    Yes. Whatever an assistant drafts is tested on the emulators, and a person reviews it before it merges.

    AI-Assisted Engineering

  13. Can we hire developers for our own team?

    Yes. Within 48 hours of your request we introduce developers who work on apps on Firebase, each working in your time zone, and you meet them before you decide who joins.

    Developers for your team

Firebase, Google Cloud and the Firebase product names on this page are trademarks of Google LLC. Webair isn’t affiliated with or endorsed by Google.

Let’s build it better

Tell us about your app, its data and the rules around it, and we’ll suggest a first step in a short call.

Thanks, we’ll be in touch soon.

{{ ctaStatus }}