I'll say something that tends to get pushback: a huge number of Flutter apps get a backend way too early, before anyone has validated whether the app is even worth building.
I get why it happens. "Real" apps have a backend, right? Auth, a database, an API — it feels like the professional way to start. But here's what I've noticed building offline-first apps: most early-stage apps don't actually need real-time sync, multi-device state, or server-side logic on day one. They need to work, fast, for one user, on one device.
A local database (Hive, Isar, SQLite — pick your favorite) can carry an app much further than people assume. You can validate the entire product experience — onboarding, core flow, retention — without touching a server. When (if) you actually need sync across devices or a social/collaborative feature, that's when a backend earns its complexity, not before.
The cost of skipping this isn't just time. It's also: auth flows to maintain, a server to keep running, API versioning headaches, and a much bigger surface area for things to break — all before you know if the app has legs.
I'm not saying never build a backend. I'm saying most Flutter devs (myself included, earlier on) reach for one reflexively, the same way people reach for Redux before checking if setState would've been fine.
Curious if this lands as controversial as I think it will, or if most people here already build this way and I'm just late to the realization.
