Quanto tempo serve per un MVP: fasi, fattori e tempi degli store
Non chiederti quanto ci vorrà: decidi quanto vuoi metterci, e taglia di conseguenza.
Quanto tempo serve per sviluppare un MVP?
Il tempo giusto è quello che decidi prima di cominciare, perché in un MVP è la scadenza a definire il perimetro, non il contrario. Chi fa la domanda al contrario («quanto ci vuole per fare tutto questo?») di solito si ritrova con un progetto lungo e una risposta tardiva.
Dovresti riuscire a costruirlo in fretta: in settimane, non in mesi.
Nella lezione sulla pianificazione dell'MVP Seibel aggiunge che alcune startup possono partire con una landing page e un foglio di calcolo, mentre hardware, biotech e settori regolati richiedono più tempo. Basecamp, nel metodo Shape Up, lavora a cicli di sei settimane perché sono abbastanza lunghe da costruire qualcosa di significativo dall'inizio alla fine.
Per contrasto: la guida prezzi di Clutch, basata su recensioni di clienti verificati, indica una durata media di circa 13 mesi per i progetti di sviluppo software in generale. Un MVP che somiglia a quella media non è più un esperimento: è un prodotto costruito prima di sapere se serve.
Quali sono le fasi di un MVP e cosa ne decide la durata?
Le fasi sono cinque e ognuna ha un fattore che ne comanda la durata. Nella tabella abbiamo messo, dove esistono, i riferimenti pubblici; non sono promesse, sono punti di partenza per ragionare.
| Fase | Cosa decide quanto dura | Riferimento pubblico |
|---|---|---|
| Validazione e interviste | Quanto facilmente raggiungi il tuo cliente ideale | Nessuno standard: fissa un numero di conversazioni e una data |
| Prototipo e test | Complessità dei flussi da provare | Nel Design Sprint di GV il prototipo si costruisce in un giorno e si testa il giorno dopo |
| Specifica e perimetro | Velocità delle decisioni dei founder | Seibel (YC) consiglia di fissare un limite di tempo alla specifica |
| Sviluppo | Perimetro, integrazioni, numero di piattaforme | Shape Up lavora a cicli fissi di sei settimane |
| Pubblicazione sugli store | Piattaforma, completezza della richiesta, tipo di account | Apple: almeno metà delle richieste esaminate in meno di 24 ore; Google: fino a 7 giorni o più nei casi eccezionali |
Nota che due fasi su cinque non dipendono dallo sviluppo. Se la validazione è fatta bene, lo sviluppo parte con meno incertezze; il metodo è in come validare un'idea di business. E a volte la risposta arriva prima, con un test senza codice: le opzioni sono in tipi di MVP.
Cosa allunga i tempi di un MVP?
Quasi sempre il perimetro che cresce senza che nessuno lo decida. Seguono le cause che vediamo più spesso:
- Perimetro che si allarga in silenzio: ogni «già che ci siamo» aggiunge giorni, e senza una specifica scritta nessuno se ne accorge.
- Decisioni lente: domande di prodotto che restano aperte per giorni bloccano lo sviluppo più di qualsiasi bug.
- Integrazioni con sistemi di terzi: documentazione incompleta, ambienti di test che mancano, accessi da chiedere.
- Più piattaforme insieme: web, iOS e Android in parallelo moltiplicano test e rilasci.
- Contenuti e dati in ritardo: testi, listini, dati da importare che arrivano a progetto quasi finito.
- Store e regole di piattaforma: un rifiuto in revisione significa correggere e ripresentare.
Quanto tempo richiedono App Store e Google Play?
Su App Store la revisione è di solito rapida; su Google Play può richiedere fino a una settimana, e per i nuovi account personali c'è un test obbligatorio prima della pubblicazione. Sono tempi da mettere in calendario, non da scoprire il giorno del lancio.
90%
Apple precisa che le richieste incomplete rallentano la revisione o vengono respinte (App Review). Google indica che alcune app possono richiedere fino a 7 giorni o più in casi eccezionali; in più, gli account sviluppatore personali creati dopo il 13 novembre 2023 devono fare un test chiuso con almeno 12 tester per almeno 14 giorni consecutivi prima di chiedere l'accesso alla produzione. La procedura completa è in come pubblicare un'app su App Store e Play Store.
Come si accorciano i tempi senza tagliare la qualità?
Fissando la scadenza e lasciando che sia il perimetro a cedere. È un metodo più che un trucco, e funziona anche se non scrivi una riga di codice.
Il metodo della scadenza fissa
Decidi quanto tempo vale la domanda
Shape Up lo chiama appetite: invece di chiederti quanto ci vorrà, decidi quanto tempo vuoi spendere. Due settimane? Sei? La risposta dice quanto è grande l'MVP.
Scrivi una specifica di una pagina
Utente, problema, percorso principale, metrica. Seibel osserva che senza specifica scritta un piano di tre settimane diventa di tre mesi senza che nessuno se ne accorga.
Prepara la lista dei tagli
Ordina le funzioni dalla meno importante. Quando sei in ritardo tagli dalla cima della lista, non sposti la data.
Mostra qualcosa ogni settimana
Una demo settimanale con dati veri fa emergere i problemi quando costano poco da correggere.
Prevedi un interruttore
In Shape Up un progetto che non chiude nel suo ciclo non viene prorogato in automatico. Decidi prima cosa farai se la scadenza arriva e l'MVP non è pronto: tagliare ancora, fermarti o ripensare.
Quando un ritardo è un segnale d'allarme?
Quando non sai spiegare cosa lo causa. Un ritardo con una causa nota (uno store che respinge, un'integrazione lenta) si gestisce; uno senza spiegazione di solito nasconde un perimetro fuori controllo.
- Le demo settimanali saltano o mostrano sempre le stesse cose.
- Nessuno sa dire cosa resta da fare e in che ordine.
- Ogni riunione aggiunge funzioni e nessuna ne toglie.
- Il lancio viene rimandato per aggiungere ancora qualcosa, invece che per sistemare un problema.
Il tempo, poi, si traduce in costo: le voci che fanno il prezzo sono in quanto costa sviluppare un MVP. E se pensi di accorciare tutto con l'intelligenza artificiale, leggi prima MVP con AI e vibe coding: il prototipo arriva prima, la produzione non sempre.
Domande frequenti
Si può fare un MVP in un mese?
A volte sì, se il perimetro è stretto, la piattaforma è una e non ci sono integrazioni complesse. Seibel di Y Combinator suggerisce proprio di chiederti cosa potresti lanciare in poche settimane e di tenere solo quello. Con app native, dati sensibili o settori regolati è più difficile.
Quanto tempo ci vuole per pubblicare un'app sugli store?
Apple dichiara di esaminare almeno il 50% delle app in meno di 24 ore e il 90% in meno di 48. Su Google Play la revisione può arrivare a 7 giorni o più nei casi eccezionali, e i nuovi account personali devono prima completare un test chiuso di 14 giorni con almeno 12 tester.
Perché i tempi di sviluppo si allungano quasi sempre?
Perché il perimetro cresce un pezzo alla volta e le decisioni restano aperte. Una specifica scritta, una lista dei tagli e una demo settimanale rendono visibile il ritardo quando è ancora piccolo.
Con l'intelligenza artificiale si fa prima?
Il primo prototipo arriva molto più in fretta. Il tempo si sposta su sicurezza, dati, test e pubblicazione, che restano lavoro vero. Ne parliamo in MVP con AI e vibe coding.
Quanto deve durare la validazione prima di costruire?
Finché hai una risposta chiara all'ipotesi più rischiosa, non a tempo indefinito. Fissa un numero di conversazioni e una data in anticipo: se la risposta non arriva, di solito è la domanda a essere vaga.
Fonti
- Y Combinator, Startup School Week 2 Recap: Michael Seibel, How to plan an MVP (2019) (19 ottobre 2026)
- Basecamp, Shape Up (Ryan Singer): Introduction (19 ottobre 2026)
- GV (Google Ventures), The Design Sprint (19 ottobre 2026)
- Apple Developer, App Review (19 ottobre 2026)
- Google Play Console Help, Prepare your app for review (19 ottobre 2026)
- Google Play Console Help, App testing requirements for new personal developer accounts (19 ottobre 2026)
- Clutch, Software Development Company Pricing Guide (2026) (19 ottobre 2026)
Dati e definizioni verificati alle date indicate.
