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.
Cosa produce questo stack in pratica
Tre progetti in produzione, tre contesti diversi.
Fosforonero.com gira su Next.js App Router. Il simulatore del buco nero è WebGL puro dentro un Server Component: la parte pesante resta sul client, il resto — SEO, routing, i18n — lo gestisce il framework senza attriti. Nessun API layer aggiuntivo: le Server Actions bastano per i form.
FitMesh mobile è Flutter. Una codebase che copre Android phone e Wear OS: stessa logica di business, UI adattata per schermo piccolo. Il layer dati parla direttamente con Supabase via REST; nessun SDK proprietario in mezzo, solo http e i tipi generati.
FitMesh backend è Postgres su Supabase. Row-level security abilitata su tutte le tabelle degli utenti, funzioni Edge per i webhook in entrata. Niente di esotico: il valore è nell'avere un DB relazionale vero sin dal primo giorno, senza migrazioni forzate dopo.
La coerenza tra i tre progetti è il vero vantaggio. Un bug nel contratto dei tipi lo vedo in tutti e tre i posti prima che arrivi in produzione.
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à.