Introduzione

Qualche anno fa un cliente mi contattò con un'idea per un progetto web: una piattaforma per connettere artigiani locali con clienti nella loro zona. Mi descrisse il sistema di recensioni, l'algoritmo di matching, il pannello admin, l'app mobile. Aveva già il nome, il logo, e un documento Word di dodici pagine.

Quando gli chiesi quanti artigiani aveva già contattato per capire se avrebbero usato la piattaforma, mi rispose: "Ancora nessuno. Prima voglio finire di pianificare."

Non finì mai. Aveva pianificato tutto tranne la cosa più importante: verificare che esistesse qualcuno disposto a usarla.

L'ho rivisto questo schema troppe volte — sia nei clienti che in me stesso, nei progetti web personali. Per questo ho smesso di ottimizzare la fase di pianificazione e ho cominciato a ragionare in modo diverso.

Perché la maggior parte dei progetti web fallisce

La narrativa standard del "come costruire un progetto web" si concentra sulle fasi: ideazione, analisi, sviluppo, lancio, crescita. È un framework sensato sulla carta. Il problema è che implica che l'idea sia già validata, e che il lavoro successivo sia tradurla in codice nel modo più efficiente possibile.

Nella realtà, il 90% dei progetti che falliscono non fallisce perché il codice era sbagliato o perché il team era scarso. Fallisce perché l'assunzione di partenza era sbagliata: che le persone avessero quel problema, che fossero disposte a pagare per risolverlo, che la soluzione proposta fosse quella giusta.

Tutto il lavoro tecnico — stack, architettura, CI/CD, ottimizzazione — è completamente irrilevante se quell'assunzione non regge.

Quindi la prima cosa che faccio quando valuto un'idea, mia o di un cliente, è isolare l'assunzione centrale. Non "voglio costruire X" ma "sto scommettendo che Y è vero". E poi cerco il modo più rapido e a basso costo per capire se Y è effettivamente vero.

Il 90% dei progetti web non fallisce per problemi tecnici. Fallisce perché nessuno ha verificato l'assunzione di partenza prima di cominciare a costruire.

Validare prima di costruire

Validare non significa fare un'analisi di mercato con tabelle Excel. Significa trovare una persona reale che ti dica che ha quel problema, che ci spende già soldi o tempo, e che userebbe la tua soluzione.

Il metodo più diretto che conosco: metti online una landing page con una descrizione chiara di cosa fa il prodotto e un bottone "Registrati / Iscriviti alla lista d'attesa". Lancia qualche euro di pubblicità targetizzata. Misura quante persone si iscrivono.

Non hai costruito niente. Non hai scritto una riga di codice backend. Ma hai già un dato reale: c'è interesse, oppure no.

Se non c'è interesse, hai risparmiato mesi di lavoro. Se c'è, hai anche una lista di persone da contattare per capire cosa si aspettano — e quelle conversazioni valgono più di qualsiasi documento di specifica scritto a tavolino.

La validazione non è una fase del progetto. È la condizione per cui ha senso avviarlo.

La scelta dello stack: decidila in un pomeriggio

Una delle perdite di tempo più classiche nei progetti web è la scelta dello stack tecnologico. Ho visto thread su Reddit e Discord dove sviluppatori passano settimane a confrontare framework, debattere su quale ORM usare, valutare se fare tutto con un monolite o separare subito in microservizi.

La risposta quasi sempre giusta: usa quello che conosci meglio.

Non è pigrizia. È che lo stack sbagliato ma che conosci alla perfezione ti porta a un MVP funzionante in un mese. Lo stack teoricamente migliore che stai imparando mentre costruisci ti porta allo stesso risultato in sei mesi, con tutti i problemi extra di chi affronta errori che non sa ancora come debuggare.

Io lavoro principalmente con Laravel per il backend e Tailwind per il frontend. Non perché siano le tecnologie oggettivamente superiori — non lo so e non mi interessa stabilirlo — ma perché con queste posso passare dall'idea al prodotto funzionante nel minor tempo possibile. E il tempo, in un progetto nuovo, è la risorsa più scarsa.

Fa eccezione quando il progetto ha requisiti tecnici specifici che impongono una scelta diversa: alta concorrenza, real-time, elaborazione di dati a larga scala. In quel caso vale la pena rallentare. Ma la maggior parte dei progetti web non ha questi requisiti, almeno non nella fase iniziale.

Lo stack giusto non è quello più interessante da imparare. È quello che ti porta a un prodotto funzionante nel minor tempo possibile con il minor numero di errori sconosciuti.

L'MVP: cosa significa davvero

MVP è diventato uno di quei termini che tutti usano e nessuno applica correttamente. Nella pratica, quando le persone dicono "facciamo un MVP" intendono "facciamo una versione ridotta di tutto quello che avevamo pianificato". Che non è un MVP: è solo un progetto più piccolo.

Un MVP vero risponde a una domanda specifica. Non "funziona il prodotto?" ma "questa assunzione centrale è corretta?"

Se sto costruendo una piattaforma per artigiani, l'MVP non è la piattaforma con meno funzionalità. È il modo più economico per testare se gli artigiani accettano lavori tramite un canale digitale. Potrebbe essere una chat su WhatsApp. Potrebbe essere un Google Form. Potrebbe essere io che faccio manualmente quello che il software dovrebbe fare automaticamente.

Solo quando so che il comportamento che voglio generare esiste già — che le persone comprano, si iscrivono, tornano — ha senso investire nello sviluppare software che lo automatizzi.

Un MVP non è un prodotto scalabile. È un esperimento con l'obiettivo di falsificare un'assunzione nel minor tempo possibile.

Sviluppare un progetto web in modo incrementale

Una volta che l'MVP ha validato l'ipotesi di partenza, si può cominciare a costruire sul serio. Qui il rischio opposto è costruire troppo, troppo in fretta, accumulando complessità che poi diventa impossibile da mantenere.

Il modo in cui mi approccio allo sviluppo iterativo: ogni due settimane mi faccio una domanda. "Cosa posso rimuovere senza che nessun utente reale se ne accorga?" Se la risposta è "molto", è un segnale che ho costruito funzionalità che nessuno usa. Meglio saperlo adesso che dopo aver aggiunto altre dieci funzionalità sopra.

Per il project management non uso niente di complesso. Una lista in Notion con tre colonne: da fare, in corso, fatto. Una colonna extra per le idee che non ho ancora deciso se implementare. Tutto quello che non si traduce in un task specifico e assegnato rimane in quella colonna finché non diventa chiaro se ha senso farlo davvero.

Per i progetti in team o con clienti uso Linear, che ha il vantaggio di essere molto più veloce di Jira senza sacrificare le funzionalità essenziali.

Il momento del lancio

Il lancio di un prodotto web ha la reputazione di essere un evento importante: il giorno in cui tutto viene rivelato al mondo. Nella pratica, per la maggior parte dei progetti, il lancio dovrebbe essere il più silenzioso possibile.

Il motivo è semplice: il prodotto al momento del lancio è quasi certamente sbagliato su qualcosa di importante. Non perché il lavoro sia stato fatto male, ma perché le assunzioni vengono corrette solo con l'uso reale. Prima arrivano utenti reali, prima emergono questi problemi, e prima si può correggere la rotta.

La strategia che funziona meglio: lancia a un gruppo ristretto di utenti — quelli che hai raccolto nella fase di validazione, o una nicchia specifica del pubblico target. Raccogli feedback diretto. Aggiusta. Poi allarga.

Il grande lancio pubblico, se ha senso farlo, viene dopo che il prodotto ha già dimostrato di funzionare su scala ridotta.

Misurare le cose giuste

Una volta online, il rischio è sommergersi di metriche. Google Analytics, Search Console, heatmap, session recording, sondaggi — si può facilmente passare più tempo ad analizzare dati che a migliorare il prodotto.

Le metriche che contano nella fase iniziale sono poche e dipendono dall'obiettivo del progetto. Per un SaaS: tasso di conversione da registrazione a primo utilizzo, e tasso di retention a 30 giorni. Per un blog o un sito editoriale: visite di ritorno e tempo sulla pagina. Per un e-commerce: tasso di completamento dell'acquisto.

Tutto il resto è rumore, almeno finché il progetto non ha raggiunto una dimensione in cui ottimizzare quelle metriche secondarie fa una differenza apprezzabile.

Una cosa che trovo utile: una volta al mese, un'ora con Google Search Console e Analytics per rispondere a tre domande. Cosa sta funzionando meglio del previsto? Cosa peggio? Qual è la singola modifica che potrebbe avere il maggiore impatto nelle prossime quattro settimane? Solo quella.

L'errore più comune che vedo ancora

Dopo venti anni, l'errore che vedo più spesso — negli altri e in me stesso nei momenti di distrazione — è aspettare che il prodotto sia pronto prima di mostrarlo.

Non è mai pronto. Non lo sarà mai nel modo in cui lo immagini. E ogni settimana che passa senza utenti reali è una settimana in cui stai costruendo sulla base di assunzioni non verificate.

Il momento giusto per mostrare qualcosa è prima di quanto pensi. Di solito quando hai ancora un po' di vergogna a farlo — Reid Hoffman ha reso famosa questa idea con LinkedIn, e dopo tutti questi anni continua a essere vero.

Se non sei almeno un po' imbarazzato dal tuo MVP, probabilmente hai aspettato troppo.