Da zero a uno
Da zero a uno è il passaggio da un'idea scritta su un documento a un prodotto reale, scaricabile o usabile da persone vere. È il momento in cui le decisioni tecniche pesano di più e le informazioni disponibili sono poche. Qui spiego il metodo che uso come fractional CTO per portare una startup da questo punto a un primo prodotto in mano agli utenti, con BRUM come prova concreta.
Cosa intendo per "da zero a uno"
Da zero a uno non è la fase di validazione con un form o un prototipo no-code: quella arriva prima. È il momento successivo, quando l'idea ha già una direzione e serve costruire il primo prodotto reale, capace di reggere utenti veri e di raccogliere segnale vero, non solo interesse dichiarato. È la fase in cui uno stack sbagliato o un'architettura pensata per la scala sbagliata costano più che altrove, perché la runway per correggerli è corta.
Il metodo: una domanda da validare, non una lista di feature
Il punto di partenza non è un elenco di funzionalità, è una sola domanda chiara che il primo prodotto deve rispondere. Tutto ciò che non serve a rispondere a quella domanda aspetta la versione due. È una disciplina più che una tecnica: dire di no a feature ragionevoli in astratto ma non necessarie a validare l'ipotesi principale, per arrivare in mano agli utenti il prima possibile con qualcosa di onesto, anche se scarno.
La prova: BRUM, dal concept ai 150.000 download
Come CTO di BRUM Patenti, ho portato il prodotto dal concept al primo MVP in store in due mesi, poi iterato in continuo ascoltando gli utenti reali. Oggi la piattaforma conta 150.000 download, un rating di 4.5★ e 50.000 utenti attivi al mese: numeri che non esistevano al lancio, costruiti iterazione dopo iterazione sopra un primo rilascio pensato per imparare, non per essere perfetto.
Stack e architettura: scelte reversibili, non scale immaginarie
Nella fase da zero a uno la tentazione più comune è progettare per una scala che il prodotto non ha ancora. Le scelte tecniche dei primi mesi vanno valutate per la velocità che permettono, non per quanto reggerebbero un carico che potrebbe non arrivare mai: meglio un'architettura semplice, rifattorizzabile dopo, di una complessa pensata per un futuro incerto. Le poche decisioni davvero difficili da cambiare vanno prese con cura; il resto può restare volutamente semplice.
Dopo l'MVP: una roadmap che regge, non una wishlist
Il primo rilascio non è il traguardo: è il punto da cui iniziare a decidere cosa costruire dopo, con dati reali invece di ipotesi. È il passaggio da zero a uno a una roadmap di prodotto vera, con priorità motivate e un orizzonte breve. Ne parlo più nel dettaglio nella pagina dedicata alla product roadmap.
Come funziona un ingaggio "da zero a uno" con me
Lavoro dentro il team, una giornata e mezza a settimana, con milestone scritte ogni 30 giorni. Il contratto iniziale è di 3 mesi con rinnovo mensile, a tariffa fissa, non a ore: un ingaggio medio in questa fase dura tra 4 e 8 mesi, il tempo di portare il prodotto da zero a una prima versione solida e il team a camminare da solo.
Domande frequenti
Cosa significa "da zero a uno" per una startup?
È il passaggio da un'idea con una direzione già chiara a un primo prodotto reale in mano agli utenti: non la fase di validazione iniziale, ma quella in cui si costruisce sul serio, con le decisioni tecniche che pesano di più.
Quanto tempo serve per arrivare a un MVP in store?
Dipende dal prodotto, ma è possibile farlo in tempi brevi con lo scope giusto: con BRUM ci sono voluti due mesi dal concept al primo MVP in store, restringendo la prima versione a una sola domanda da validare.
Mi serve un cofounder tecnico o basta un fractional CTO per questa fase?
Un fractional CTO copre le stesse decisioni di un cofounder tecnico, stack, architettura, priorità, senza equity e senza un impegno permanente: utile soprattutto quando non è ancora chiaro se il fit per un cofounder esiste davvero.
Cosa serve prima di iniziare la fase da zero a uno?
Una direzione già validata, anche informalmente: un'idea con un target chiaro e una prima ipotesi su chi la userebbe. Se manca anche quello, il passo prima è la validazione, non ancora la costruzione.
Scrivi anche codice in questa fase?
Sì, quando serve sbloccare il primo rilascio o fare scelte architetturali con le mani sporche, oltre a guidare stack, scope e priorità.