Due anni su Web3, e cosa ho sbagliato con 21BJ e Sp3llbound

A maggio 2025 ho chiuso due progetti nello stesso mese: 21BJ, un gioco di carte fantasy per mobile su cui lavoravo da aprile 2023, e Sp3llbound Studios, lo studio di sviluppo Web3 nato a giugno 2024. Ventiquattro mesi sul primo, undici sul secondo. Zero prodotti vendibili alla fine.

L'errore non è stato tecnico. Il codice funzionava, le build uscivano, il gioco si giocava. L'errore è stato costruire per un mercato che davo per scontato invece di verificarlo, e continuare a costruire anche quando i numeri dicevano che non c'era.

Perché due anni non hanno prodotto un mercato

Perché il mercato non l'ho mai testato: l'ho assunto. Nel 2023 il gaming Web3 era una premessa che circolava ovunque nel mio ambiente, e io l'ho trattata come un fatto acquisito invece che come l'ipotesi più rischiosa del progetto.

21BJ era un casinò fantasy senza scommesse reali. Sulla carta risolveva una tensione precisa: il gameplay del casinò senza il rischio del gioco d'azzardo. Nella pratica non ho mai trovato le persone che quella tensione la sentivano davvero. Chi vuole il brivido vuole i soldi veri. Chi non li vuole gioca ad altro. Il pubblico che stava esattamente nel mezzo l'avevo immaginato io.

Sp3llbound è arrivato dopo, ed è stato l'errore peggiore: invece di mettere in discussione la premessa, l'ho raddoppiata. Ho pensato che il problema fosse l'esecuzione, non la direzione, e ho aperto uno studio per eseguire meglio. Ho costruito una struttura più grande sopra un'ipotesi che non avevo ancora verificato.

I tre segnali che ho ignorato per ventiquattro mesi

Non è stato un crollo improvviso. Sono state tre cose piccole, ripetute per mesi, ognuna delle quali avevo una spiegazione pronta per non guardare.

Gli utenti si registravano e non tornavano. Lo spiegavo con l'onboarding. Ho rifatto l'onboarding tre volte. Non era l'onboarding: era che non avevano motivo di tornare.

Dovevo sempre aggiungere una frase per far capire il problema. Ogni volta che spiegavo il prodotto, servivano trenta secondi di premessa prima che l'altro annuisse. Quando un problema è reale non serve la premessa: la persona ti interrompe per dirti che ce l'ha anche lei. Se devi spiegare il problema, non lo stanno sentendo.

Lavoravo solo sulle feature. Non su distribuzione, non su prezzo, non sul parlare con le persone. Le feature erano la parte comoda: misurabile, controllabile, e con la sensazione di aver fatto qualcosa a fine giornata. Distribuzione e prezzo erano la parte dove potevo scoprire di avere torto, e infatti le rimandavo.

Il filo comune è questo: ogni segnale aveva una spiegazione che spostava il problema su qualcosa che sapevo risolvere. Un problema di onboarding lo so risolvere. Un problema di mercato no. Quindi ogni volta il mio cervello sceglieva la prima versione.

La domanda che ha chiuso il discorso

Me la sono posta così: se ripartissi oggi da zero, con quello che so adesso, ricomincerei questo progetto?

No. Su nessuno dei due.

E se la risposta è no, ogni giorno in più è una scelta che non farei. Non è un fallimento: è aver capito che stavo continuando a pagare una decisione presa un anno e mezzo prima, non a prenderne una nuova. Il costo dei mesi già spesi era irrecuperabile in ogni caso. L'unica cosa ancora in mio potere era smettere di aggiungerne altri.

Questa domanda funziona perché separa due cose che di solito stanno appiccicate: quanto hai già investito e quanto vale la pena investire da adesso. La prima è un dato storico, non una ragione.

La lista pratica per chiudere senza fare danni

Quando ho deciso, ho fatto le cose in quest'ordine. Con Sp3llbound c'erano anche dei soci, quindi il punto zero è stato metterlo per iscritto prima di comunicarlo fuori.

1. Disattivare i pagamenti prima di tutto il resto, così nessuno paga per un servizio che sta finendo. È il punto che ha più conseguenze legali e reputazionali se lo sbagli.
2. Avvisare gli utenti attivi con una data precisa, non un "prossimamente". Una data permette alle persone di organizzarsi. Un "presto" le lascia in sospeso e ti fa arrivare le mail per settimane.
3. Dare un export dei dati senza farlo chiedere. Se qualcuno deve aprire un ticket per riavere le sue cose, hai trasformato una chiusura in un'ultima brutta esperienza.
4. Tenere il dominio e una pagina che spiega cosa è successo. Costa dieci euro l'anno ed evita che l'unico risultato su di te sia un dominio scaduto pieno di spam.
5. Scrivere cosa non ha funzionato, mentre te lo ricordi bene. È il punto che salta sempre ed è quello che serve di più. Dopo due settimane ti ricordi solo la versione comoda della storia, quella in cui il mercato non era pronto.

Il quinto punto è il motivo per cui questo articolo esiste. Ed è anche il motivo per cui 21BJ e Sp3llbound sono ancora sulla pagina progetti con lo stesso spazio di quelli vivi.

Cosa mi è rimasto

Il codice quasi niente. Quello che è rimasto sono tre abitudini che uso ancora adesso.

Parlare con le persone prima di costruire, non dopo aver finito la prima versione. Misurare il ritorno e non la registrazione: quanti tornano la settimana dopo è l'unico numero che nel 2023 non guardavo mai. E mettere una data di scadenza a ogni scommessa: se entro quella data non è successa una cosa precisa, chiudo. La data si decide da lucidi, all'inizio, non quando sei già dentro fino al collo.

Vengo dalla fisica, e la cosa più stupida di questa storia è che la fisica quelle abitudini me le aveva già insegnate. Un'ipotesi vale zero finché non la metti alla prova, e i dati non si negoziano. Le ho applicate al codice per due anni e non al mercato.

Le stesse tre cose hanno reso possibile costruire e vendere Bitzuma in cinque mesi, pochi mesi dopo aver chiuso questi due.

Domande frequenti

Quanto tempo ci hai messo a capire che 21BJ non funzionava?

Circa un anno per sospettarlo, altri dodici mesi per ammetterlo. Il ritardo non è stato nel capire, è stato nell'accettare che i mesi già spesi non contavano come argomento per continuare.

Chiudere due progetti insieme è stato un caso?

No. Sp3llbound era nato per eseguire meglio la stessa premessa di 21BJ. Quando la premessa è caduta, sono caduti insieme. È il rischio di costruire il secondo progetto sopra l'ipotesi non verificata del primo.

Ti sei pentito di aver lavorato sul Web3?

Del settore no, del metodo sì. Il problema non è stato scegliere un mercato incerto: è stato non trattarlo come incerto, e quindi non testare per primo la cosa che poteva far crollare tutto.

Come decidi adesso se un progetto vale?

Le prime due settimane servono a cercare persone che il problema ce l'hanno già e che stanno usando qualcosa di scomodo per risolverlo. Se non le trovo, non parte. Ne scrivo in da co-founder a solo founder.