Founders ask me a familiar question halfway through every Flutter build: “Is Firebase enough, or do we need a proper backend?” My answer is rarely a blanket yes or no. Here’s how I decide when to layer in Dart services versus sticking with Firebase/Supabase.
1. Start With Velocity, Not Architecture
If experiments are stalling because security rules are gnarly or Firestore queries are tangled, it’s time to insert a service layer. For HopNetwork we first moved the hairy business logic into Cloud Functions, then graduated to Dart Frog when routing and testing needed to grow up.
2. Separate Real-Time From Batch Work
- Live collaboration (chat, multiplayer, presence) stays on Firebase Realtime DB or Supabase Edge so we don’t reinvent pub/sub.
- Workflow automation (reports, partner integrations, billing) sits on Dart services running in Cloud Run where we own retries, scheduling, and secrets.
3. Match Tools to the Team You Actually Have
Most early-stage teams have Flutter engineers but no backend hire. Dart Frog and Shelf let us keep the language consistent, share models, and avoid context switching. When dedicated platform engineers join, we can peel off critical paths to Go/Rust/Laravel microservices without breaking the contract pre-built in Dart.
4. Bake in Guardrails From Day One
I treat the first deploy like a rehearsal for scale:
- Env configuration lives in Doppler (or 1Password) with staging/production splits.
- Structured logging flows to Coralogix so on-call me can trace incidents at 2 a.m.
- The repo contains a rollback-ready README snippet and one-click deploy scripts—no tribal knowledge.
A Quick AfCircle Example
We left social graph reads/writes in Firebase for speed, but moved feed ranking into a Dart service. It ingests engagement signals, crunches scores, and writes summaries back to Firestore. The mobile app stays fast, and growth experiments have a sandbox that won’t crater production.
The Principle I Live By
Pick the simplest backend that gets you to the next milestone. Add structure only when velocity, cost, or reliability says you must. With clean interfaces and good docs, you can evolve the infrastructure without slamming the brakes on product.