Lo stack che uso nel 2026: Flutter, Next.js, Supabase
Perché ho scelto questi tre, dove faticano, e cosa li tiene insieme — il mio stack indie a inizio 2026.
Ogni qualche anno ridisegno mentalmente lo stack — non per gusto, ma per stare ancorato. Quello che segue è dove sono adesso, all'inizio del 2026.
Le tre tecnologie principali
Flutter per il client mobile. Dopo un paio di anni con React Native, sono tornato a Flutter principalmente per due motivi: il rendering coerente cross-platform e l'esperienza di sviluppo (hot reload affidabile, devtool maturi). FitMesh ne è la dimostrazione: stessa codebase su Android e Wear OS.
Next.js lato web. App Router, Server Components, sicurezza by default. È diventato troppo complesso? Forse. Ma per un indie dev solo, l'alternativa è cucire insieme cinque librerie. Preferisco un framework opinionato.
Supabase come backend. Postgres vero, auth integrato, realtime se serve. È l'unico vendor su cui non vorrei essere lock-in — e per questo motivo organizzo lo schema in modo da poter esportare i dati senza dipendere dalle loro feature avanzate.
Cosa ho scartato e perché
- Firebase: l'ho usato per anni, ma il pricing diventa proibitivo e Firestore non è un DB relazionale vero. Una volta che hai bisogno di join, lo senti.
- Prisma: bello, ma per progetti piccoli Supabase + tipi auto-generati è più snello.
- tRPC: per progetti dove ho un client esterno (mobile) non ha senso. Resto su REST tradizionale.
Cosa mi tiene insieme tutto
Un singolo file di tipi condivisi, generato da Supabase, importato sia nel client web che nell'app Flutter (tramite uno script che converte i tipi TS in modelli Dart). Vecchio trucco, ma fa il suo lavoro.
Lo stack giusto non è quello migliore in assoluto. È quello che riesci a mantenere da solo per dieci anni.
Tornerò su questo articolo tra un anno. Vediamo cosa cambierà.