How do I check my rules right now?

Ask the REST endpoint rather than the console. Request one of your collections with no authentication token, then with an ordinary user's, and read what comes back field by field. The console evaluates rules as you; a visitor is not you.

My bill jumped and traffic did not. Why?

Almost always reads rather than users. A list view without a limit, or a listener left open on a collection, charges per document every time a screen mounts, so one screen can be thousands of reads a visit.

Should I move to Postgres?

Not by default. Firebase runs serious workloads and migrating early trades a working product for a rebuild. It becomes the right call when your reporting needs joins and aggregates that documents cannot give you, and we will show you the numbers either way.

Can you work in our Firebase project directly?

Yes. Add us with the access you are comfortable granting. Rules changes are deployed from the repository rather than clicked into the console, so every change is reviewable and reversible.

Platform playbook

Make your Firebase app production-ready

Firebase gets authentication, storage and a database working in an afternoon. The same afternoon is where both of its production problems start: rules nobody revisited, and a bill that grows with reads rather than with customers.

Book a Free Call Start with a free check

Firebase

Most common critical finding

Security rules still in test mode, leaving every document in the project readable by any visitor.

Production Check: Free, 3–5 days
Typical engagement: 2–3 weeks
Hardening from: $2,000, fixed scope

What we find

Where Firebase apps break in production

What actually goes wrong, and why you would not have spotted it yourself. These are the findings we file most often, not a generic checklist.

Finding 01
Any visitor can read every customer's records
Generated rules commonly ship wide open, because that is what makes the first build work. Firebase is the authorization layer here in the same way row-level security is on Postgres: if the rules are permissive, the database is a public API.
Security rules still in test mode
Finding 02
A quiet week costs more than a busy one did
Firestore charges for documents read, not for queries run. One list view without a limit, or a listener left open on a collection, turns a single visit into thousands of reads.
Billing per document read
Finding 03
The report your customer asks for cannot be written
Anything that would be one line of SQL becomes a denormalised copy kept in sync by hand or by a function, and every copy is a new way for two numbers to disagree.
No joins and no aggregates
Finding 04
Getting your data out is a project, not an export
There is no single dump that brings the relationships with it. Leaving means writing code per collection and rebuilding the model on the other side, which is why the decision keeps getting deferred.
Export runs per collection

What we do about it

The Firebase fix list

None of this is a rewrite. Firebase runs real businesses. What changes is the rules layer, the shape of the queries, and the handful of things that should never have been documents.

How the hardening works

Rewrite the rules per collection, with tests that assert one account cannot reach another's documents
Put a limit and an index on every list query, and close listeners that outlive the screen
Set a budget alert and a hard cap before the invoice teaches the lesson
Model the reports you actually need, and decide what belongs in Postgres instead
Separate development and production projects so an experiment cannot touch customer data
Build and verify an export path, so leaving stays a decision rather than a rebuild

How it runs

A typical Firebase engagement

Durations from real projects of comparable size. The check is free and everything after it is quoted as fixed scope, so you know the price before we start.

1
Production Check
3–5 days
We call your Firestore and Storage endpoints as a logged-out visitor and as an ordinary user, then compare what comes back against what any screen was meant to show.
2
Rules from the data model up
Week 1
Rules rewritten per collection and per field, with the rules tests kept in your repository so a later change that widens one fails the build instead of reaching customers.
3
Queries, indexes and the bill
Week 1–2
A limit and an index on every list, listeners closed when the screen closes, and a budget alert with a hard cap set before the invoice teaches the lesson.
4
Exports and restores
Week 2–3
A scripted export per collection, run once and restored once, so the relationships come with it and leaving stays a decision rather than a rebuild.

No lock-in

What you keep

Everything we produce belongs to you. If you stop working with us tomorrow, nothing stops running and nothing becomes unmaintainable.

Your accounts and your code
The repository, the cloud accounts, the database and the domain stay in your name.
The report, whatever you decide next
Findings, severity ratings, reproduction steps and effort estimates, written for an engineer.
Infrastructure written down
The environment is defined as code in your repository and comes with a runbook: how to deploy, how to roll back, how to restore, and what to check first.
Your Firebase project, still yours
We work in your project and deploy rules with you watching. The rules tests and the export script live in your repository, so both outlast the engagement.

Questions

Firebase questions we get asked

If yours is not here, ask it on the call. The first one is free and there is no obligation afterwards.

Ask the REST endpoint rather than the console. Request one of your collections with no authentication token, then with an ordinary user's, and read what comes back field by field. The console evaluates rules as you; a visitor is not you.
Almost always reads rather than users. A list view without a limit, or a listener left open on a collection, charges per document every time a screen mounts, so one screen can be thousands of reads a visit.
Not by default. Firebase runs serious workloads and migrating early trades a working product for a rebuild. It becomes the right call when your reporting needs joins and aggregates that documents cannot give you, and we will show you the numbers either way.
Yes. Add us with the access you are comfortable granting. Rules changes are deployed from the repository rather than clicked into the console, so every change is reviewable and reversible.