What a Firebase Audit Looks Like

Most Firebase bills don't spike because of a traffic surge. They spike because of a data model that made sense for 100 users and quietly becomes expensive at 10,000. By the time the Google invoice lands, the problem has been compounding for months.

A Firebase audit is one week of structured review: Firestore data model, security rules, Cloud Functions, auth setup, and billing. $997. One week, one deliverable. Most Firebase consultant engagements are open-ended — this one isn't, by design.

Firebase Isn't the Best Platform. It's the One That Lets One Person Ship.

Firebase isn't theoretically superior to its competitors. Postgres is a better database. AWS is more flexible. Supabase has a more sensible API for a lot of operations. Plenty of teams have good reasons to be on something else.

I'm on Firebase anyway. It's the only platform I've used where a single developer can ship a complete web app — auth, hosting, real-time database, file storage, serverless backend, push notifications — without standing up infrastructure for any of it. No DevOps role to fill. No Kubernetes. The platform makes a deliberate trade: less control in exchange for less surface area to manage. For a one-person studio, that trade pays off every week.

The downside is that Firebase is easy until it isn't. The defaults the docs teach — denormalized documents, listeners on entire collections, Cloud Functions triggered on every write, security rules from the quickstart — work fine for the first few hundred users. They start failing in specific, expensive ways once the product gets traction. Reads scale linearly with users; cost scales superlinearly because of the patterns the platform encourages.

This audit exists because I've already paid that tuition. Every Firebase project I've shipped has taught me a specific way the platform punishes naive use: a denormalized document that blew the read budget when one collection grew faster than expected, listeners on a parent collection that re-fetched on every child write, a Cloud Function chain where one trigger spawned three more, security rules that worked at launch and quietly failed when a new role was added. These aren't theoretical failure modes. They're scars I have, plus the fixes that worked.

You can pay the same tuition I did — six months of debugging cost spikes, six weeks refactoring data models, weekend incidents where rules let too much through. Or you can pay $997 for a week of someone walking your codebase with a checklist built from those exact failures. You're borrowing scars I already earned.

If your bottleneck is "should we be on Firebase at all?" — the audit answers that too. Sometimes the right call is to migrate to Postgres or Supabase. I'll tell you if that's true.

The Problem Is Usually Structural

Firestore performance issues come from data models built around how the app looks, not how it queries. When a product is moving fast, the instinct is to match the data shape to the UI. A user profile document stores everything — arrays that grow without bound, nested objects, fields that only make sense in one screen. Works until the queries catch up.

Reads are the main cost driver. A listener returning 500 documents on every page load, a Cloud Function triggering on every write to process three fields — these aren't bugs, they're design decisions that compound. I've seen a single restructure cut read counts by 80%. Moving computed values out of Cloud Functions has eliminated thousands of daily invocations on more than one project.

The audit maps every critical query path: collection structure, composite indexes, listener efficiency, Cloud Functions triggers. The data model and query logic are tightly coupled — fixing one without reviewing the other misses half the picture. That's true whether you're dealing with Firestore transaction edge cases or cross-field listener patterns.

Security Rules Are Server-Side Access Control

If your Firestore security rules are wrong, it doesn't matter what the client code does — the data is exposed.

The most common pattern: rules copied from the docs during setup, updated inconsistently as the app grew. A collection added six months ago has allow read, write: if true; because it was faster to unblock a build than to write proper rules.

Every collection gets reviewed — rule coverage, auth flow integrity, write validation, and how Admin SDK usage in Cloud Functions interacts with client-side rules. The question is whether a malicious client can read or write data they shouldn't. In most projects I audit, the answer is yes for at least one collection. This is the same class of problem as when polish over security costs real.

What the Week Covers

Day one covers billing: Cloud Functions invocation counts, Firestore read/write/delete breakdowns, storage access patterns. Days two and three cover the data model and queries — collection structure, indexes, read paths for the most-used features. Days four and five cover security rules and auth.

The output is a written report: what I found, what it costs, what to fix first. Most projects have two or three changes that account for most of the impact.

Who Books This

The clearest signal is a bill that moved in a direction you didn't expect. The second is an email from Google flagging insecure rules — automated, worth taking seriously. The third is a traffic event where unexpected usage made the cost and performance implications visible at the same time.

If you're considering migrating off Firebase because of cost or complexity, the audit is a useful first step. Sometimes the data model just needs to change. Sometimes Firebase isn't the right fit, and the audit makes that case clearly.

If your Firebase bill is moving in the wrong direction, submit a project brief.