MVP software in 12 settimane per PMI: le 4 fasi che non saltano mai

Le richieste di MVP custom che riceviamo da una PMI italiana iniziano sempre nello stesso modo: 'abbiamo un'idea, ma non sappiamo da dove partire e ci hanno detto che servono nove mesi'. Nove mesi sono troppi per la maggior parte dei casi che vediamo. Dodici settimane, se l'idea è ragionevolmente delimitata e l'azienda è disposta a tagliare il superfluo, sono sufficienti per arrivare in produzione con utenti reali.

Quello che segue è il modello a quattro fasi che applichiamo sui progetti MVP per PMI. Non è teoria: è il calendario su cui abbiamo costruito tre prodotti negli ultimi diciotto mesi. Funziona se la PMI accetta tre cose: priorità chiara, decisioni rapide, e l'idea che 'minimo' significa davvero minimo.

Fase 1 — Discovery (settimane 1-2)

Il discovery non è 'raccolta dei requisiti'. Quello lo fanno gli analisti delle software house tradizionali e produce documenti di duecento pagine che diventano obsoleti in due mesi. Il discovery è capire qual è il problema, chi lo ha davvero, quanto vale risolverlo e quale parte del problema può essere affrontata in 12 settimane.

In due settimane si fanno tre cose. Quattro-sei interviste con gli utenti finali (non con gli stakeholder, con chi userà davvero il software ogni giorno). Una mappatura del processo attuale, con i tempi di esecuzione reali misurati allo stopwatch. Un'analisi delle alternative: cosa fa l'azienda oggi, cosa farebbe con un SaaS off-the-shelf, cosa cambia con un MVP custom.

• Interviste utenti: 30-45 minuti ciascuna, registrate, con un template di 8-10 domande aperte focalizzate sul 'oggi' e non sul 'come vorresti'.
• Mappa di processo: diagramma di flusso con i punti di attrito, tempi misurati, errori frequenti, decisioni implicite.
• Benchmark alternative: tabella sintetica con 3 SaaS competitor (costo, fit, vincoli, time-to-value) confrontati con l'MVP custom.
• Output finale: un documento di 10-12 pagine che chiamiamo 'Discovery Brief'. Non di più.

Errore più comune in questa fase: ascoltare solo lo sponsor (il CEO, il direttore, il responsabile che ha avuto l'idea). Lo sponsor ti dice cosa vuole credere. Gli utenti ti dicono cosa fanno davvero. Se le due cose coincidono, sei fortunato. Nel 70% dei casi, divergono. Vale la pena scoprirlo a settimana due, non a settimana dieci.

Fase 2 — Spec (settimana 3)

Una settimana di pura scrittura. Niente codice, niente design, niente meeting allungati. La spec è il documento che blocca l'ambito dell'MVP e diventa contratto operativo per le otto settimane successive. Deve essere abbastanza dettagliato per essere implementato e abbastanza sintetico per essere letto in un'ora.

Quattro sezioni, sempre nello stesso ordine. La fase di spec mal fatta è il motivo numero uno per cui i progetti MVP sforano i tempi.

1. User stories prioritizzate: 8-15 storie massimo, ciascuna in formato 'come [ruolo], voglio [azione], per [risultato]'. Tutto quello che non sta in quelle storie è fuori scope.
2. Architettura tecnica sintetica: stack scelto, integrazioni necessarie (e quelle escluse), modello dati ad alto livello, scelta di hosting.
3. Wireframe a bassa fedeltà: schermate principali in stile Balsamiq o anche su carta. Non design rifinito — quello rallenta e fa litigare.
4. Criteri di accettazione MVP: cosa significa 'finito' per ogni user story, in modo verificabile e non opinabile.

Fase 3 — Build (settimane 4-11)

Otto settimane di sviluppo iterativo, con consegne settimanali su ambiente di staging. Niente big bang, niente waterfall, niente sorprese a settimana otto. Ogni venerdì alle 16 c'è una demo di mezz'ora al cliente, su quello che è stato costruito in settimana. Cinque minuti di setup, venti minuti di walkthrough, cinque minuti di decisioni operative.

La struttura settimanale tipica di un team di tre persone (un lead, uno sviluppatore, uno con design+QA) su un MVP di media complessità.

• Settimana 4-5: scaffolding del progetto, modello dati, autenticazione, primi due flussi user-facing.
• Settimana 6-7: integrazioni esterne (pagamenti, API di terze parti, autenticazione SSO se richiesta).
• Settimana 8-9: feature core dell'MVP, le user story con valore di business più alto.
• Settimana 10: rifiniture, gestione errori, copertura dei casi limite più realistici.
• Settimana 11: testing end-to-end, performance, sicurezza base, preparazione dell'ambiente di produzione.

Tre regole operative durante le otto settimane di build. Primo: nessuna modifica della spec senza un 'change request' firmato. Secondo: il cliente ha accesso a staging in qualsiasi momento, può testare ogni giorno, non solo il venerdì. Terzo: i bug emersi vanno triagiati subito — critici si fixano, secondari vanno in backlog post-MVP. Non si rifiniscono cose che funzionano già in modo accettabile.

“Il momento più pericoloso di un MVP è la settimana nove, quando funziona quasi tutto e qualcuno propone di 'fare meglio una sola cosa'. Quella cosa diventa due, le due diventano quattro, e a settimana sedici sei fuori budget con un prodotto che hai polished ma non hai mai messo in mano agli utenti.”

Fase 4 — Handover (settimana 12)

L'handover è la fase che molte software house trascurano e che decide se l'investimento del cliente sopravvive. In settimana 12 fai tre cose: deploy in produzione con utenti reali, documentazione operativa, formazione del team cliente. Non un'attività spalmata — una settimana dedicata.

La documentazione che funziona è snella e segmentata per ruolo.

• Per l'utente finale: una guida operativa di 10-15 pagine con screenshot reali e flussi end-to-end dei task più comuni.
• Per l'amministratore di sistema: un runbook tecnico con accesso ai sistemi, come riavviare i servizi, come leggere i log principali, come gestire backup e ripristino.
• Per chi farà manutenzione (anche se non sei tu): documentazione tecnica del codice, modello dati, principali decisioni architetturali e perché sono state prese.
• Per il CEO/sponsor: una sintesi di 2 pagine con metriche di adozione attese, costi operativi mensili stimati, roadmap successiva a 90 giorni.

La formazione è di due sessioni da 90 minuti — una per gli utenti finali, una per i power user/amministratori. Entrambe registrate. Entrambe seguite da una settimana di 'shadow support' in cui il team di sviluppo è disponibile via Slack o email con tempi di risposta sotto le 4 ore.

Cosa NON includere in 12 settimane

Alcune cose che sembrano essenziali e non lo sono, nei primi tre mesi di vita di un MVP. Tagliarle è la differenza tra arrivare in produzione e non arrivarci.

• Internazionalizzazione (i18n): se i primi utenti sono italiani, l'MVP è in italiano. L'inglese si aggiunge dopo.
• Mobile app nativa: se l'MVP è web-responsive, basta. L'app nativa è un progetto separato.
• Sistema di permessi granulare: due o tre ruoli bastano. Il sistema RBAC complesso si fa dopo, quando sai chi userà davvero il prodotto.
• Dashboard e reportistica avanzata: la prima versione ha 3-5 metriche essenziali. Il resto viene quando gli utenti chiedono dati specifici.
• Integrazioni nice-to-have: ogni integrazione è 1-2 settimane. Includere solo quelle bloccanti per l'uso reale.

Se stai pensando a un MVP custom per la tua PMI e vuoi confrontare il tuo brief con quello che funziona nei nostri progetti, prendiamoci trenta minuti. Ti diciamo se le 12 settimane sono realistiche per il tuo caso, dove tagliare per restare nei tempi, e che cosa rischi di sbagliare in fase di discovery. Chiamata gratuita, senza vincoli.