Sviluppo MVP per startup: dal round al prodotto in produzione

Come stima indicativa e non come impegno: fra 8 e 16 settimane dalla definizione del perimetro alla prima versione in produzione. La variabile che sposta di più le date non è lo sviluppo: è la velocità con cui arrivano le decisioni di perimetro dal tuo lato. Un fondatore che risponde in giornata alle domande aperte accorcia il progetto più di qualunque scelta tecnica.

No, e non è una questione di fiducia nel tuo progetto. Lavorare in equity mi renderebbe un socio con un mandato ambiguo, e l'ultima cosa che ti serve nei primi mesi è un fornitore che si comporta da socio senza esserlo. Preferisco un rapporto pulito: perimetro definito, preventivo a corpo, consegna. Se il prodotto va bene mi fa piacere, ma le decisioni sono tue.

No. Posso coprire l'architettura e le decisioni tecniche di questo progetto, che è una cosa diversa dall'essere il responsabile tecnico di un'azienda: quel ruolo richiede stare dentro le decisioni di prodotto e di persone ogni giorno, e un fornitore esterno non può farlo bene. Quello che faccio è costruire il prodotto in modo che il CTO che assumerai possa prenderlo in mano senza riscriverlo, e fargli un passaggio serio quando arriva.

È lo scenario per cui il progetto è costruito. Il codice è già nel tuo repository, l'infrastruttura è sui tuoi account, l'architettura è documentata con le alternative scartate e il backlog residuo è scritto. Faccio l'onboarding tecnico alla persona che arriva, punti fragili noti compresi, e da lì può continuare. Se serve resto disponibile per un periodo concordato, ma l'obiettivo dichiarato è che non serva.

Sì, dal primo commit: il repository è tuo e io sono un collaboratore. Vale per tutto il resto — hosting, database, servizi di terze parti sono intestati alla startup. Non esiste un momento della consegna in cui bisogna migrare qualcosa, perché non c'è mai stato niente intestato a me. È anche la ragione per cui una due diligence tecnica non trova sorprese.

Con un meccanismo, non con la buona volontà. Prima di iniziare si scrive in una frase cosa l'MVP deve dimostrare. Ogni richiesta successiva viene valutata contro quella frase: se la serve entra nel perimetro, altrimenti va nel backlog «non ora» con la decisione tracciata. Il backlog te lo consegno insieme al prodotto, quindi niente va perso: viene rinviato consapevolmente. Serve però che dal tuo lato ci sia qualcuno che possa dire no.

Deliberatamente noiose e diffuse, scelte in base a due criteri: che esista un mercato del lavoro per assumere chi le conosce, e che un CTO nuovo possa leggerle in una settimana. L'architettura di partenza è un servizio applicativo e un database, senza orchestrazione: si divide quando c'è una ragione misurata, non per anticipare una scala che non hai ancora. Le scelte specifiche dipendono dal prodotto e sono discusse con te, non imposte.

Può succedere, e non è nel mio controllo né in quello di nessun fornitore: io rispondo del prodotto, non della traction. Quello che posso fare è ridurre il danno: un perimetro minimo consuma meno runway, e un prodotto ereditabile con un'architettura documentata è riutilizzabile se cambi direzione. Diffida di chiunque colleghi il proprio lavoro tecnico a promesse di risultato di mercato.

Aiuta, perché un MVP fatto così è un investimento significativo e serve del capitale per sostenerlo. Se non hai ancora raccolto, spesso la mossa giusta non è questa: è validare con un prototipo o con strumenti no-code che il problema esista e che qualcuno paghi per risolverlo. In quel caso te lo dico in chiamata invece di venderti un progetto che ti brucia il poco che hai.