Firebase Audit
Find the problems before the incident or the invoice does.
Most Firebase problems are invisible until they are expensive: a security rule that passes the happy-path test but leaks a collection, a query pattern that reads a thousand documents to render a list of ten, a Function that spends more time cold-starting than working. The audit exists to find these before an incident or an invoice does.
What we review
Security rules. We read every rule, not a sample. We look for the classic failure modes: read granted where only get was intended, rules that trust client-supplied fields, missing request.auth checks on nested paths, and rules that validate shape but not ownership. Where rules are untested, we say so — and show what a test harness for them looks like.
Firestore data model and queries. We map your collections against the queries the app actually runs: which reads fan out, which listeners re-fire more than they should, where composite indexes are missing or unused, and where the model forces client-side joins that belong in the schema.
Cloud Functions. Cold-start profile, memory sizing, retry semantics, idempotency of triggered functions, and whether background work is on the right trigger at all. Gen 1 functions get a migration assessment.
Billing. A line-by-line breakdown of the invoice mapped to the behaviors that generate it — document reads, egress, Function invocations, storage — so cost stops being a single opaque number.
What you receive
A prioritized findings report: each finding with its risk or cost impact, the fix, and a rough effort estimate. Findings are ordered so your team can start at the top and stop when the return flattens. We walk the report with your engineers, not just your management.
Where it leads
Some teams take the report and run with it themselves — that is a fine outcome. Others ask us to stay for the fixes; that work is scoped as a follow-on build & hardening or cost & performance engagement, billed hourly like everything we do.