Il mio stack per lanciare una web app da solo

Questo è lo stack con cui ho costruito Startupage e con cui è fatto il sito che stai leggendo. Tutti i miei siti web sono fatti così.

Otto strumenti: sei che uso su qualunque progetto e due che servono perché è web. Per la parte mobile lo stack cambia in cima e resta identico sotto, e l'ho scritta in il mio stack per una app mobile.

Il criterio con cui 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".

I due pezzi che rendono la web app una web app

Next.js: il framework per tutto ciò che è web. App Router, rendering statico dove possibile. Il motivo per cui lo tengo non è il framework in sé, è che rendering, routing, gestione delle immagini e API stanno in un progetto solo: da solo, ogni pezzo separato da cucire a mano è un pezzo che poi devo mantenere.

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. Da solo non ho nessuno che rilegge il codice, e vedere la cosa vera prima di pubblicarla è il sostituto più vicino a una revisione.

I sei che restano uguali comunque

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.

Resend: mail transazionali e newsletter. Una cosa sola che fa una cosa sola. Le mail di sistema sono la parte che nessuno guarda finché non arrivano nello spam, e tenerle su un servizio che fa solo quello vuol dire non doverci pensare.

PostHog: prodotto e analytics. Come lo uso lo trovi più in basso, perché è più interessante del fatto che lo usi.

Featurebase: help center e raccolta dei feedback. Da solo non hai un supporto clienti, quindi serve un posto dove le richieste si accumulano, si votano e restano leggibili, invece di sparire in una casella di posta.

Namecheap: domini. Niente di romantico, ma tenerli tutti in un posto solo evita la rincorsa al rinnovo scaduto.

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

Cosa non uso, di proposito

• Non guardo tutto quello che PostHog sa fare. All'inizio serve un numero: quante persone tornano la settimana dopo. Gli imbuti e le mappe di calore sono un modo elegante per non guardarlo. Diventano utili dopo, quando c'è abbastanza traffico perché dicano qualcosa.
• 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. Ventitré mesi passati a costruire un prodotto troppo grande per le nostre forze mi hanno insegnato che quel momento va anticipato, non rimandato.