Come validare un'idea SaaS in 48 ore con l'AI

In breve: Validare un'idea SaaS non significa costruire il prodotto. Significa scoprire se qualcuno è disposto a pagare per la soluzione che hai in mente, prima di investire settimane a svilupparla. Con gli strumenti AI disponibili oggi, in particolare Claude Code, puoi comprimere questo processo in 48 ore. Il primo giorno è dedicato alla ricerca di mercato, alle conversazioni con potenziali clienti e alla costruzione di una landing page che testa la domanda reale. Il secondo giorno, se i segnali sono positivi, costruisci un prototipo funzionante e lo metti davanti alle persone che hanno mostrato interesse. Se i segnali non ci sono, hai risparmiato mesi di lavoro su un'idea che non aveva mercato. In questa guida spiego il processo esatto che uso io, con i tre segnali concreti che cerco per decidere se andare avanti o passare all'idea successiva.

Tutti hanno idee per un SaaS. Ne sento tre o quattro a settimana, tra chi mi scrive, chi segue AI Mastery, chi mi ferma dopo un evento. Idee anche buone, spesso. Il problema è sempre lo stesso: la persona sparisce per due mesi, costruisce il prodotto da sola nel silenzio, poi lo lancia e scopre che nessuno lo vuole. Con l'AI, questo errore è diventato ancora più comune. Siccome costruire è diventato veloce, la gente costruisce di più e valida di meno. È il paradosso del vibecoding: lo strumento che dovrebbe farti risparmiare tempo te ne fa sprecare di più, perché rende troppo facile saltare la parte difficile.

Validare un'idea SaaS in 48 ore non vuol dire costruire un prodotto in 48 ore. Vuol dire arrivare, in due giorni, a una risposta chiara: questa idea ha mercato oppure no? La differenza è enorme, e tutto il processo che descrivo qui è costruito attorno a quella distinzione.

Giorno 1: ricerca e landing page

La mattina del primo giorno non tocco il codice. Apro un documento vuoto e rispondo a tre domande: chi ha il problema che voglio risolvere, come lo risolve oggi, e quanto gli costa risolverlo male. Se non riesco a rispondere a tutte e tre, l'idea non è matura. Non significa che sia sbagliata, significa che non la conosco abbastanza per costruirci sopra qualcosa.

Dopo aver scritto le risposte, vado a cercare le persone che hanno il problema. Non in astratto: persone reali. Mando cinque messaggi diretti su LinkedIn, su Twitter, nei gruppi Slack o Discord dove si ritrova il mio target. Non chiedo "ti piacerebbe un tool che fa X?", perché a quella domanda tutti rispondono sì, come spiega bene Rob Fitzpatrick in The Mom Test. Chiedo "come gestisci X oggi?" e ascolto. Se la persona si sfoga per cinque minuti sul suo processo attuale, ho trovato un nervo scoperto. Se risponde "beh, uso un foglio Excel e va bene così", probabilmente il dolore non è abbastanza forte.

Il pomeriggio è dedicato alla landing page. Non al prodotto. Alla pagina che spiega il prodotto che non esiste ancora.

Come costruisco la landing page

Uso Claude Code per generare una landing page completa in Next.js. Gli do un brief preciso: il problema, la soluzione, il target, il tono di voce. In due o tre ore ho una pagina con headline, sottotitolo, tre blocchi che spiegano il valore, social proof se ne ho, e soprattutto un form di iscrizione. Il form è il cuore di tutto. Non è un form contatti generico: è un "Avvisami quando è pronto" oppure un "Prenota l'accesso anticipato a X euro". La versione con il prezzo è sempre meglio, perché filtra chi è davvero interessato da chi clicca per curiosità.

Il prompt che do a Claude Code è qualcosa del tipo:

Crea una landing page Next.js per [nome prodotto]. Il target è [descrizione].
Il problema che risolve è [problema]. Headline: [headline].
Include un form di iscrizione con email e un bottone "Prenota accesso anticipato".
Design pulito, mobile-first, massimo 3 sezioni sopra il fold.

Non mi preoccupo che il design sia perfetto. Mi preoccupo che la proposta di valore sia chiara nei primi cinque secondi. Il design lo sistemo dopo, se l'idea dimostra di avere gambe.

La sera del primo giorno, la landing page è online. La condivido nei posti dove ho trovato le persone con il problema: stessi gruppi, stessi canali, stessi DM. Non faccio spam. Scrivo un messaggio onesto: "Sto lavorando a un tool che risolve X. Se ti interessa, qui c'è la pagina." Poi aspetto.

Giorno 2: prototipo e prime conversazioni

La mattina del secondo giorno guardo i numeri. Quante persone hanno visitato la pagina, quante hanno lasciato l'email, quante hanno cliccato sul bottone. Se su cento visite ho dieci iscrizioni, è un segnale forte. Se ne ho zero o una, devo capire perché: il messaggio era sbagliato, il canale era sbagliato, oppure il problema non è sentito come pensavo.

Se i segnali sono positivi, passo alla costruzione del prototipo. E qui è dove Claude Code fa davvero la differenza. In una mattina riesco a costruire il nucleo funzionante dell'applicazione: la feature principale, quella che risolve il problema di base. Non l'intero prodotto. Non il sistema di autenticazione, non la dashboard, non le notifiche via email. Solo la cosa che, se funziona, dimostra che l'idea ha senso.

Il pomeriggio è il momento più importante delle 48 ore. Prendo le persone che si sono iscritte e gli mostro il prototipo. Non con uno screenshot, non con un video: gli do accesso. Li faccio usare la cosa. Li guardo mentre la usano, se possibile in una chiamata. Gli chiedo cosa funziona, cosa non funziona, cosa manca. E soprattutto gli chiedo una domanda che fa paura: "Pagheresti per questo? Quanto?"

Il prototipo non è il prodotto

Questo è il punto dove la maggior parte delle persone si perde. Il prototipo dimostra che il concetto funziona. Il prodotto è un'altra cosa: è il prototipo più affidabilità, più onboarding, più supporto, più tutte quelle cose noiose che separano un esperimento da qualcosa per cui le persone pagano ogni mese. Il prodotto viene dopo, e viene solo se il prototipo ha superato il test del mercato.

Ho costruito prototipi che sembravano fantastici e che nessuno voleva usare. Ho costruito prototipi brutti, con l'interfaccia storta e un bug ogni tre click, che le persone mi chiedevano di poter usare subito. L'aspetto non conta quasi nulla in questa fase. Conta solo se la soluzione risolve il problema in modo che il potenziale cliente percepisce come valore reale.

Come capire se l'idea funziona?

Dopo 48 ore hai abbastanza informazioni per prendere una decisione. Non una decisione definitiva, ma una direzione. Ci sono tre segnali che cerco, e almeno uno deve essere presente perché io continui a investire tempo sull'idea.

1. Le persone chiedono "quando posso usarlo?" Non per educazione, non per farti un complimento. Lo chiedono perché hanno il problema adesso e vogliono la soluzione adesso. Questo segnale vale oro, perché indica urgenza.

2. Qualcuno offre di pagare prima che sia pronto. Questo è successo con DECISOR.AI. Un direttore operativo, dopo aver visto il prototipo, mi ha chiesto quanto costava e come poteva iniziare. Il prodotto non era nemmeno vicino a essere finito. Ma la disponibilità a pagare era reale, concreta, con una cifra in mente.

3. Le persone lo condividono senza che tu lo chieda. Ricevi un messaggio da qualcuno che non conosci e che dice "mi ha parlato di te il mio collega". Questo è il segnale più forte di tutti, perché significa che il valore percepito è così alto che la gente ne parla spontaneamente.

Se nessuno di questi tre segnali si manifesta nelle 48 ore, non è la fine del mondo. Ma è un segnale chiaro che qualcosa non funziona. Forse il problema non è abbastanza doloroso. Forse la soluzione non è abbastanza chiara. Forse il target è sbagliato. In ogni caso, hai investito due giorni invece di due mesi. Puoi iterare sul posizionamento, cambiare target, oppure passare all'idea successiva senza rimpianti.

L'errore più grande: innamorarsi del codice

Come ho scritto in Il codice è diventato una commodity, il codice è la parte facile. Con Claude Code e gli altri strumenti di vibecoding, costruire software è diventato accessibile a chiunque abbia un'idea e la pazienza di descriverla bene. Ma questa facilità crea una trappola insidiosa: ti innamori del codice.

Succede così. Costruisci il prototipo, funziona, ti entusiasmi. Invece di mostrarlo alle persone e chiedere feedback, aggiungi una feature. Poi un'altra. Poi rifattorizzi il backend perché "così è più pulito". Poi aggiungi la dark mode perché "tanto ci metto mezz'ora con Claude Code". Dopo due settimane hai un prodotto bellissimo che nessuno ha ancora visto. E quando finalmente lo mostri, scopri che il problema principale che doveva risolvere non era il problema giusto.

Questo è l'errore che vedo più spesso tra chi inizia a costruire SaaS con l'AI. La velocità di costruzione diventa una scusa per non affrontare la parte scomoda: parlare con le persone, sentirsi dire di no, scoprire che la tua idea non è così brillante come pensavi. L'AI ti permette di costruire veloce. Usa quella velocità per testare veloce, non per costruire di più.

Il processo funziona. Le idee no, a volte.

Ho fatto questo processo decine di volte. Alcune idee hanno funzionato: DECISOR.AI è nata esattamente così, da una landing page che ha raccolto interesse reale nel primo giorno e un prototipo che un cliente ha voluto pagare prima ancora che fosse finito. Altre idee sono morte dopo 48 ore, e va benissimo così. Quelle che sono morte velocemente mi hanno risparmiato mesi di lavoro su qualcosa che non avrebbe funzionato.

La cosa che ho imparato è che il processo di validazione conta più dell'idea stessa. Un'idea mediocre con un buon processo di validazione si trasforma velocemente in qualcosa di utile, perché il feedback del mercato la corregge. Un'idea brillante senza validazione resta un'idea brillante nella tua testa, e basta.

Se vuoi vedere i risultati di questo approccio, dai un'occhiata ai miei progetti. Ognuno di quelli è passato attraverso le stesse 48 ore che ho descritto qui. Non tutti sono sopravvissuti, e quelli che sono sopravvissuti non assomigliano quasi per niente alla versione originale. Ma sono tutti partiti da una domanda semplice: c'è qualcuno disposto a pagare per questo? La risposta a quella domanda, non il codice, è la cosa che conta.