Firebase
Google's BaaS — auth, Firestore, and hosting with no server to manage, and tradeoffs that compound fast.
Firebase handles auth, real-time data, file storage, and hosting through a single SDK. It removes a lot of infrastructure overhead, which is genuinely useful early on. The decision point is whether your access patterns fit Firestore's document model — because once they don't, there's no query flexibility to fall back on.
The failure mode I see most often is treating Firestore like a relational database. People denormalize poorly, end up with fan-out writes that cost more than expected, and then discover that the query they need — a filtered join across two collections — simply isn't possible. Access-pattern-first design isn't optional with Firestore; it's the only way the data model stays maintainable and affordable at scale. I structure collections around how the data gets read, not how it logically relates, which means embedding vs. referencing decisions are made early and explicitly. Security rules are the other consistent problem area. They look simple until you realize that a single rules misconfiguration can expose every document in a collection to any authenticated user — and Firebase's auth requirement doesn't protect you from that. I've found auth bypass patterns in rules that passed a basic read-test because the test only checked the happy path. The vendor lock-in reality: Firestore's SDK, security rules language, and pricing model are not portable. When a project outgrows Firebase — usually around the point where complex queries, full-text search, or relational integrity become requirements — the migration isn't a configuration change. I've done three Firebase-to-GCP migrations, and the approach that works is feature-by-feature, not a cutover. You move one query surface at a time to Cloud SQL or Cloud Run, keep Firebase Auth in place as the identity layer until last, and validate behavior in parallel before retiring the Firebase path.
Data Model Design
I start from the read queries the app actually needs — not from the entity schema — and work backward to collection structure. That means making embedding vs. referencing calls with read cost in mind, identifying where fan-out writes will occur and whether they're affordable, and flagging access patterns that Firestore can't serve efficiently before they're built in.
Security Rules Audit
I look specifically for rules that appear restrictive but aren't: auth checks that don't validate document ownership, wildcard matches that expose sibling collections, and Storage rules that grant read access to any signed-in user regardless of whether they own the file. The test suite for rules matters as much as the rules themselves — most bypasses survive code review because the test only covers the intended path.
Firebase to Cloud Migration
The approach I use is feature-by-feature migration rather than cutover. I identify the Firestore queries that are causing the most pain — usually complex filters, full-text search needs, or relational lookups — and migrate those surfaces to Cloud SQL or Cloud Run first, while leaving Firebase Auth as the identity layer. Each step is validated in production with the old and new paths running in parallel before the Firebase path is retired.
Real-Time Collaboration Apps
Firestore's onSnapshot listeners propagate document writes to all subscribed clients without any polling or WebSocket management on my end. For document editors, shared boards, or live dashboards where the read model maps cleanly to documents, this is a meaningful reduction in infrastructure complexity.
Mobile App Backends
Flutter and React Native apps where the data model is document-oriented and the query surface is bounded. Firebase Auth handles credential management and token refresh across platforms, FCM covers push notifications, and a single Firestore SDK replaces what would otherwise require a custom API layer.
MVP & Prototype Delivery
Firebase eliminates the infrastructure decisions that slow down early-stage work — there's no server to provision, no auth system to build, no deployment pipeline to configure for a backend. That's genuinely useful when the goal is validating behavior with real users, not engineering for scale.
Let's talk Firebase.
No pitch. Just a technical conversation about the problem you're working on.