The stack I use in 2026: Flutter, Next.js, Supabase
Why I picked these three, where they struggle, and what holds them together, my indie stack at the start of 2026.
Every few years I redraw my mental stack, not for fun, but to stay grounded. What follows is where I am right now, at the start of 2026.
The three core technologies
Flutter for the mobile client. After a couple of years on React Native, I came back to Flutter for two reasons above all: consistent cross-platform rendering and a developer experience that holds up (reliable hot reload, mature devtools). FitMesh is the proof: a single codebase running on Android and Wear OS.
Next.js on the web. App Router, React Server Components, security defaults you don't have to fight. Has it become too complex? Maybe. But for a solo indie dev, the alternative is wiring together five separate libraries yourself. I'll take the opinionated framework.
Supabase as the backend. Real Postgres, integrated auth, realtime when you need it. It's the one vendor I actively design not to lock me in, so I structure the schema in a way that lets me export the data out without depending on their advanced features.
What I dropped, and why
- Firebase: I used it for years, but the pricing curve gets brutal at scale and Firestore isn't a real relational database. The moment you need joins, you feel it.
- Prisma: nice tool, but for small projects Supabase plus its auto-generated types is leaner.
- tRPC: when you have an external client (a mobile app), it doesn't fit. I stay on plain REST.
What holds it all together
A single shared types file, generated from Supabase, imported in both the web client and the Flutter app (via a small script that converts the TS types into Dart models). Old trick, still does its job.
What this stack produces in practice
Three projects in production, three different contexts.
Fosforonero.com runs on Next.js App Router. The black hole simulator is raw WebGL inside a Server Component: the heavy computation stays on the client, everything else — SEO, routing, i18n — is handled by the framework with no friction. No extra API layer: Server Actions cover the forms.
FitMesh mobile is Flutter. One codebase targeting Android phone and Wear OS: same business logic, UI adapted for the small screen. The data layer talks directly to Supabase over REST — no proprietary SDK in the middle, just http and the generated types.
FitMesh backend is Postgres on Supabase. Row-level security enabled on every user-facing table, Edge Functions for incoming webhooks. Nothing exotic: the real value is having a proper relational database from day one, with no forced migrations later when the schema grows.
The consistency across the three projects is the actual payoff. A type contract bug shows up in all three places before it reaches production.
The right stack isn't the objectively best one. It's the one you can maintain alone for ten years.
I'll revisit this post in a year. Let's see what changes.