Il mio stack per lanciare un prodotto da solo

Lo stack che uso per costruire e lanciare un prodotto da solo è: Next.js, Supabase, Vercel, Cursor, Claude, Resend, Figma, Notion, GitHub. Nove strumenti, sempre gli stessi, su ogni progetto.

Il criterio con cui l'ho scelto non è "il migliore per il lavoro". È: quanti strumenti riesco a conoscere così bene da non doverci pensare. Lavorando da solo, ogni tecnologia nuova è tempo che tolgo alla parte che decide se il prodotto funziona.

Perché ripetere lo stesso stack conta più che sceglierne uno ottimale

Perché il vantaggio non sta nello strumento, sta nel non ricominciare da capo. Al terzo progetto sullo stesso stack, l'infrastruttura smette di essere un problema: autenticazione, deploy, mail transazionali e schema del database sono decisioni già prese, e il tempo va tutto sul prodotto.

Un altro stack andrebbe bene uguale. Quello che non andrebbe bene è cambiarlo a ogni progetto per inseguire lo strumento migliore del mese. La differenza di prestazioni tra due framework moderni è irrilevante rispetto alla differenza tra "so già come si fa" e "lo scopro adesso".

Cosa fa ognuno dei nove

Next.js: il framework per tutto ciò che è web. App Router, rendering statico dove possibile. Lo uso anche per il sito che stai leggendo.

Supabase: database Postgres, autenticazione e storage in un pezzo solo. È la ragione principale per cui riesco a partire senza scrivere backend: le regole di accesso stanno a livello di database, non sparse nel codice.

Vercel: deploy e hosting. Il valore non è la velocità di deploy: è che ogni branch ha un'anteprima con URL, così vedo una modifica in condizioni reali prima di mandarla in produzione.

Cursor e Claude: la parte AI dello stack. Li uso per capire codice che non ho scritto e per i cambi ripetitivi. Dove smettono di aiutare l'ho scritto in costruire più veloce non è decidere meglio.

Resend: mail transazionali e newsletter. Una cosa sola che fa una cosa sola.

Figma: design. Non faccio mockup ad alta fedeltà di tutto: uso Figma per le due o tre schermate che decidono il prodotto, il resto lo disegno direttamente in codice perché è più veloce.

Notion: dove sta scritto tutto quello che non è codice. Ipotesi, decisioni prese e perché, numeri settimanali. È la cosa che ha reso Bitzuma vendibile in cinque mesi: il processo scritto fuori dalla mia testa.

GitHub: codice e cronologia. Anche sui progetti dove sono l'unico a scrivere, perché la cronologia è memoria.

Cosa non uso, di proposito

• Nessun servizio di analytics complesso all'inizio. Serve un numero: quante persone tornano la settimana dopo. Tutto il resto è un modo elegante per non guardarlo.
• Nessun sistema di gestione dei task. Da solo, una lista in Notion basta. Una board con colonne e stati è overhead che imita un team che non esiste.
• Nessuna libreria di componenti pesante. Componenti locali che posso leggere per intero. Da solo, il debito nascosto in una dipendenza costa più della riga in più.
• Nessun test end-to-end nella prima versione. Testo la logica che non posso verificare a occhio. Costruire una suite completa per un prodotto che potrebbe chiudere in tre mesi è tempo speso per proteggere qualcosa che ancora non esiste.

L'ultimo punto vale finché il prodotto è un'ipotesi. Nel momento in cui qualcuno paga, cambia: da lì i test servono, perché rompere una cosa che funziona ha un costo reale.

In che ordine costruisco

1. Una pagina che spiega il prodotto, prima del prodotto. Se non riesco a scriverla in modo che si capisca senza premesse, il problema non è chiaro nemmeno a me.
2. Il percorso più corto che risolve il problema una volta. Niente account, niente impostazioni, niente pagamenti. Solo la cosa che deve funzionare.
3. Autenticazione e database, appena il percorso deve essere ripetuto dalla stessa persona. Non prima.
4. Un numero da guardare. Quante persone tornano. Prima di aggiungere qualsiasi feature.
5. Pagamenti. Presto, non tardi. Il momento in cui qualcuno paga è l'unico test di valore non ambiguo che esiste.
6. Tutto il resto, solo se il numero al punto quattro si muove.

L'ordine è pensato per una cosa sola: arrivare il prima possibile al momento in cui posso scoprire di avere torto. Ventiquattro mesi passati a costruire feature invece che a verificare la premessa mi hanno insegnato che quel momento va anticipato, non rimandato.

Domande frequenti

Quanto ci metti a mettere online la prima versione di un prodotto?

Con questo stack, la parte tecnica fino a un prodotto usabile online è questione di giorni, non di settimane. La parte lunga non è mai stata costruire: è capire cosa vale la pena costruire.

Perché Supabase e non un backend scritto a mano?

Perché autenticazione e regole di accesso sono la parte dove è più facile fare danni e dove non c'è nessun vantaggio competitivo nel rifarle da zero. Con le regole a livello di database, l'accesso ai dati è controllato in un punto solo.

Serve saper programmare per usare questo stack?

Sì. L'AI riduce il tempo di scrittura, non la necessità di capire cosa stai leggendo. Senza quella capacità non riesci a distinguere una risposta giusta da una plausibile.

Cambieresti qualcosa se lavorassi in team?

Aggiungerei test dall'inizio e una convenzione scritta su come si fanno le cose. Da solo quelle regole stanno nella mia testa; con più persone la testa non è un posto condiviso.