Come costruirei un MVP - e come scelgo davvero la stack

Se domani mi chiedessero di costruire un MVP, non aprirei una tabella di 40 framework. Non disegnerei una mappa di microservizi. Non «metterei a prova di futuro» un prodotto che non ha mai incontrato un utente pagante. Scriverei una frase: per chi è, quale lavoro fa, e cosa misureremo in quattro settimane. La stack arriva dopo quella frase - non prima.

La maggior parte degli MVP falliti non sono troppo piccoli. Sono falsamente grandi: una «piattaforma» a metà con auth, cruscotti, notifiche e tre ambienti - e nessuno ha ancora finito l’unico lavoro che proverebbe l’idea. La tech è spesso l’alibi. Questo articolo è come consegnerei davvero.

1. Cos’è un MVP - e cosa rifiuto di chiamare così

Un MVP non è «la versione 1 con meno schermi». È l’esperimento più economico che può uccidere o rafforzare l’ipotesi più rischiosa. Se l’ipotesi è «la gente pagherà per prenotare questo servizio online», l’MVP è un flusso di prenotazione più il pagamento più un umano dall’altra parte - non un CRM, non un programma fedeltà, non un’app native.

• Viable vuol dire: un utente vero può finire un lavoro vero. Un prototipo Figma cliccabile è ricerca, non un MVP.
• Minimum vuol dire: tutto ciò che non serve a quel lavoro è un ticket dopo - anche se sembra «facile da aggiungere».
• Product vuol dire: la settimana prossima potete ripeterlo senza eroismo. Un Google Form più un foglio può essere un MVP. Riscrivere l’architettura di Netflix, no.

2. Cinque domande prima che esista un repository

I dibattiti di stack sono a buon mercato. Le domande prodotto senza risposta sono care. Non scelgo Postgres contro Mongo finché non so rispondere a voce alta - con il fondatore, non con un articolo.

• Chi sono i primi dieci utenti, per nome se possibile - non «chiunque abbia un telefono».
• Qual è l’unico lavoro per cui «assumono» il prodotto questo mese? Uno. Non una piattaforma.
• Da dove arriva il denaro o il segnale - addebito carta, contratto firmato, slot prenotato, lead qualificato?
• Quale vincolo è reale: quattro settimane, uno sviluppatore, un dominio regolato, un CRM esistente, un pubblico Telegram?
• Cosa ci farebbe fermare? Se non possiamo nominare un criterio di stop, stiamo costruendo un hobby, non un esperimento.

3. Cinque filtri per scegliere la tecnologia

Non scelgo gli strumenti perché sono di tendenza. Li scelgo perché sopravvivono al contatto con uno sviluppatore solo, un budget piccolo e il primo utente arrabbiato. Ogni tech passa questi filtri.

• Tempo fino al primo utente vero. Se la stack aggiunge una settimana prima del primo clic, è la stack sbagliata per un MVP. Gli strumenti noiosi che consegno già in produzione vincono su uno di moda che imparerei sotto deadline.
• Operabile da una persona. Devo poter fare deploy, leggere i log, ripristinare un backup e ruotare una chiave senza un team di piattaforma. Kubernetes fallisce questo test per quasi tutti i prodotti precoci.
• Assumibile e sostituibile. TypeScript, Postgres e React non sono eccitanti. Sono i linguaggi che altre persone brave parlano già. Un MVP che solo io posso estendere è un ostaggio, non un asset.
• Dove stanno i dati. La fonte di verità va in un database vero con migration dal giorno uno se ci sono utenti e soldi. I fogli vanno bene per l’esperimento accanto al prodotto - non nel checkout.
• Uscita di emergenza. Userò un auth gestito, un Postgres hosted, un provider di pagamento. Non firmerò un lock-in di cinque anni il cui export fa male. Un fornitore va bene. Una trappola, no.

4. La stack web di default con cui inizierei nel 2026

Per un MVP B2B o di servizio tipico - prenotazione, cattura lead, piccolo portale cliente, calcolatore che diventa un preventivo - inizierei qui. Non perché è di moda. Perché posso consegnare, fare SEO, e ancora assumere qualcun altro in sei mesi.

• Next.js + TypeScript + Tailwind: un’app per le pagine marketing (SEO, rendering server) e la UI prodotto. Meno repo, un deploy, tipi condivisi. App Router va bene se il team lo conosce già; non riscriverò un’app Pages che funziona «per purezza».
• Postgres (spesso via Supabase, Neon o un piccolo VPS): dati relazionali, transazioni, e SQL che posso leggere alle 2 di notte. Prendo un document store solo se la forma è davvero documentale - non perché «NoSQL è più veloce».
• Auth: un provider gestito (Clerk, Auth.js + un IdP noto, o Supabase Auth), salvo se il prodotto è l’auth. Sessioni fatte in casa nella settimana uno è come si leakano token e si blocca la funzione vera.
• Pagamenti: Stripe (o l’equivalente locale che i primi utenti usano davvero). Niente motore di fatturazione fatto in casa. Le fatture possono aspettare; un addebito che funziona, no.
• Hosting: Vercel per l’app Next.js se il traffico è «web» e il team vuole i preview; Hetzner/VPS + Docker Compose se serve un worker lungo, un costo prevedibile o la residenza dei dati. Quel compromesso l’ho scritto altrove. Regola MVP: un ambiente che capite, backup di notte, HTTPS, un dominio.
• Email e file: Resend o un’API transazionale simile; storage compatibile S3. Non «costruiremo un modulo allegati».

5. Quando abbandono il default

Un default è una scommessa di partenza, non una religione. Lo cambio quando il vincolo è il prodotto.

• Il pubblico vive già in Telegram: un bot o una Mini App può essere tutto l’MVP. Un sito che non apriranno non è «più professionale». È una seconda stanza vuota.
• Il lavoro è sul campo con un segnale cattivo: guardo local-first o una PWA, non una riscrittura native nella settimana uno. Native è una decisione di distribuzione, non un badge.
• Il cuore è il linguaggio (supporto, preventivi, estrazione documenti): aggiungo un’API LLM dietro uno schema stretto e un passo di revisione umana. Non avvolgo un widget di chat per chiamarlo prodotto.
• Il founder è l’operatore e il contenuto è il prodotto: un sito veloce più un CMS che useranno davvero può vincere su un admin su misura. WordPress è ancora permesso se il lavoro è pubblicare, non costruire un’applicazione.
• Marketplace a due facce: consegno comunque un lato prima. Offerta o domanda - quello più duro da ottenere. Una «piattaforma» con sedie vuote da entrambi i lati è una landing con tabelle di troppo.

6. Ciò che rifiuto di aggiungere prima dei primi utenti

Il modo più veloce per mancare l’esperimento è costruire l’azienda intorno all’esperimento. Questa lista resta accanto al backlog.

• Microservizi, message bus e Kubernetes. Un processo, un database, un deploy. Si spezza quando compare un collo di bottiglia vero o un confine di team vero - non quando un diagramma sembra senior.
• Un design system con 80 token e zero schermate. Consegnare le tre schermate che raccolgono i soldi. Estrarre i componenti quando il terzo copia-incolla fa male.
• Ruoli, permessi, audit log e SSO - salvo se un acquirente B2B pagante ha bloccato l’accordo lì. Allora sono l’MVP, non una quest secondaria.
• Una seconda app mobile. Il web responsive o una Mini App copre i primi cento utenti nella maggior parte dei business di servizio che vedo.
• Copertura di test perfetta del codice-colla. Voglio test su soldi, auth e il lavoro centrale. Non una settimana di mock per un form di landing.

7. Come sarebbero davvero le prime quattro settimane

Tratto il calendario come una decisione di prodotto. Se non possiamo descrivere le settimane, non abbiamo un piano - abbiamo un desiderio.

• Settimana 0 (due giorni, non due settimane): il one-pager. Utente, lavoro, criterio di stop, non-obiettivi. Schizzare le tre schermate. Accordarsi su «fatto»: uno sconosciuto può finire il lavoro senza il nostro Zoom.
• Settimana 1: fetta verticale. Dominio, deploy, database, layout vuoto, un happy path in produzione (anche brutto). Se non possiamo fare deploy al giorno tre, la stack sta già mentendo.
• Settimana 2: il lavoro. Prenotazione, preventivo, upload, pagamento - ciò che abbiamo nominato in settimana 0. Le operazioni manuali dietro l’UI sono permesse: un ping Telegram al titolare è una funzione se chiude il ciclo.
• Settimana 3: i bordi brutti. Stati vuoti, errori, mobile, email, analytics di base (dove mollano). Non un data warehouse. Un funnel che si può leggere.
• Settimana 4: metterlo davanti alle dieci persone nominate. Guardare. Non aggiungere funzioni durante le call. Annotare ciò che hanno fatto, non ciò che dicevano di volere.

8. Dopo il lancio: tenere, estrarre o riscrivere

Un buon MVP ha il diritto di essere un po’ imbarazzante. Non ha il diritto di essere una trappola. La stack sopra è noiosa apposta: ci si può crescere dentro. Raramente serve uscirne il primo anno.

• Tenere: il linguaggio, il database, i nomi di dominio nel codice. Economico da conviverci, caro da buttare.
• Estrarre: un worker, un secondo servizio, una coda vera - quando un lavoro è lento, pericoloso o appartiene a un altro team. Non prima.
• Riscrivere solo la parte che ha imparato la lezione sbagliata. Checkout sbagliato - riscrivere il checkout. Tutta l’app è un labirinto vibe-coded: prima è un problema di persone. Qualcuno deve poterlo spiegare alle 2 di notte.

Conclusione: scegliete la stack che sopravvive al primo no

Costruirei un MVP senza glamour: un lavoro, un database, un deploy, strumenti che posso operare da sola, e una data in cui si decide di continuare o fermarsi. La «migliore» tech è quella che non ci distrae da quella decisione. Next.js, TypeScript, Postgres, un auth gestito e un provider di pagamento non sono una personalità. Sono un modo per spendere le settimane scarse sul prodotto, non sulla piattaforma.

Se avete un’idea, una scadenza e la paura di scegliere la «stack sbagliata» - scrivete dalla sezione contatti. Possiamo inquadrare l’unico lavoro, nominare i non-obiettivi, e consegnare una fetta da mostrare a persone vere senza costruire prima una falsa piattaforma.