Sviluppo Di MVP: Perimetro, Costi E Tempi

Lo sviluppo di un MVP va storto durante la riunione di definizione del perimetro, non durante la costruzione. Qualcuno pronuncia le parole «minimum viable product», tutti annuiscono, e poi arriva un elenco di funzionalità che contiene account utente, un pannello di amministrazione, la fatturazione, le notifiche, una dashboard e un’app mobile. Quello non è un minimum viable product. Quello è un prodotto completo, e richiederà tre volte il tempo che avete in mente.

La parola che fa i danni è «viable», cioè sostenibile. Quasi tutti i team la leggono come «abbastanza buono da vendere a chiunque», mentre significa «quanto basta per capire se qualcuno lo vuole davvero».

Il test di perimetro che fa risparmiare di più: per ogni funzionalità, chiedetevi cosa fareste di diverso a seconda della risposta. Se una funzionalità non può cambiare una decisione, non fa parte dell’MVP. Un pannello di amministrazione non vi dice se le persone vogliono il prodotto; vi dice che il prodotto sarà più facile da amministrare una volta che lo vorranno. Costruitelo per secondo.

A cosa serve davvero lo sviluppo di un MVP

Un MVP esiste per rispondere a una sola domanda con utenti reali anziché con opinioni. Di solito è questa: qualcuno pagherà per averlo, oppure qualcuno lo userà abbastanza spesso da fare la differenza?

Questo ridefinisce cosa deve entrarci. Vi serve l’unico percorso che dimostra il valore, funzionante da un capo all’altro e rifinito quanto basta perché una persona vera possa completarlo senza che voi siate seduti accanto a lei. Tutto il resto resta facoltativo finché quel percorso non ha dato la sua risposta.

Spiega anche la differenza rispetto a un prototipo. Un prototipo è usa e getta e risponde a una domanda di progettazione, spesso senza alcun back-end funzionante. Un MVP è codice di produzione con utenti veri e dati veri, costruito per essere esteso se la risposta è sì. Confondere i due costa caro in entrambe le direzioni: buttare via codice di cui avevate bisogno, oppure ingegnerizzare con cura qualcosa che state per scartare.

Cosa entra e cosa aspetta

Entra: il percorso di valore centrale, l’autenticazione minima che quel percorso richiede, un modo per incassare pagamenti se la domanda è se le persone pagheranno, e strumentazione sufficiente per vedere cosa fanno realmente gli utenti.

Aspetta: le interfacce di amministrazione, i sistemi di ruoli e permessi oltre uno o due ruoli, le preferenze di notifica, i flussi di onboarding, le integrazioni che nessuno ha chiesto e tutto ciò che viene introdotto con la frase «già che ci siamo».

Ci sono due cose che vengono tagliate a torto. La strumentazione, perché un MVP che va online senza analytics non risponde ad alcuna domanda e avrete speso i soldi per nulla. E la possibilità di cancellare o correggere i dati, perché gli utenti veri sbagliano già il primo giorno e la chirurgia manuale sul database stanca in fretta.

L’espansione di perimetro più comune è il pannello di amministrazione, ed è quasi sempre evitabile. Nelle prime settimane, eseguire query a mano è più rapido da mettere in piedi ed è perfettamente adeguato con dieci utenti. Costruite il pannello quando assistere manualmente gli utenti diventa il collo di bottiglia, che è un bel problema da avere.

Costi realistici nel Regno Unito

Un MVP viene prezzato in base al numero di cose distinte che sa fare, non in base all’idea che ci sta dietro. Le fasce che vediamo nella consegna britannica:

Una consegna offshore a £100 o £200 al giorno cambia l’aritmetica e introduce quel costo di coordinamento che trattiamo in esternalizzare lo sviluppo software . La nostra analisi dei costi dello sviluppo software su misura spiega cosa spinge verso l’alto ciascuna fascia.

Due voci di costo restano fuori da quasi ogni budget di MVP. Qualcuno deve mandarlo avanti una volta online, e questa è una cifra mensile reale, non un errore di arrotondamento. E la seconda versione, perché se l’MVP risponde bene alla sua domanda il passo immediatamente successivo è costruirci sopra, e un budget che finisce al lancio finisce esattamente quando scoprite cosa fare.

L’errore che trasforma tre mesi in nove

Costruire per una scala che ancora non avete.

L’istinto è comprensibile. A nessuno piace scrivere codice destinato a essere sostituito. Così l’MVP riceve una coda di messaggi, uno strato di cache, la scalabilità orizzontale e un confine a microservizi, nessuno dei quali regge un carico reale con cinquanta utenti, e tutti da costruire, testare e mandare in esercizio prima che la prima persona veda il prodotto.

La posizione onesta è che a un MVP è concesso di essere architetturalmente noioso. Un database, un’applicazione, un deploy semplice. Se avrà successo, ne riscriverete alcune parti conoscendo davvero dove sta il carico, e quella riscrittura sarà più economica e molto più mirata dell’ipotesi fatta prima del lancio.

L’eccezione riguarda tutto ciò che è costoso da cambiare dopo: il modello dei dati, l’approccio all’autenticazione e qualsiasi decisione che tocchi dati personali. Impostarli in modo grossomodo corretto fin dall’inizio vale la settimana in più, perché sono proprio quelli che costano di più da districare.

Come definire il perimetro in un pomeriggio

Scrivete l’unica frase che descrive cosa ottiene un utente. Poi elencate le schermate che quella frase richiede, e nient’altro. Per ogni funzionalità rimasta, applicate il test di decisione presentato all’inizio di questo articolo.

Poi tagliate comunque l’elenco di un terzo. Ogni team esagera con il perimetro alla prima passata, e il terzo che rimuovete è quasi sempre lo stesso terzo che avreste rimosso dopo il lancio.

Fissate una data anziché un elenco di funzionalità. Un MVP di tre mesi che esce vale più di uno da cinque mesi che al settimo mese è ancora a due settimane dal rilascio, e una data fissa costringe le conversazioni sul perimetro ad avvenire presto, quando costano poco.

Mecanik definisce e costruisce MVP con il suo team di sviluppo software , compresa la parte in cui qualcuno vi dissuade dal pannello di amministrazione. Se avete un elenco di funzionalità e nessuna data, è da lì che si comincia.

Post correlati: Sviluppo software su misura nel Regno Unito , Sviluppo software fintech nel Regno Unito: FCA, rails e costi , Come sviluppare una web app nel 2026 - Guida UK , Sviluppo web white label per agenzie .

Domande frequenti

Cosa deve contenere un MVP? Il percorso di valore centrale funzionante da un capo all’altro, l’autenticazione minima che quel percorso richiede, il pagamento se la domanda è se le persone pagheranno, e strumentazione sufficiente per vedere cosa fanno realmente gli utenti. Pannelli di amministrazione, sistemi di ruoli, preferenze di notifica e integrazioni che nessuno ha chiesto aspettano tutti che l’MVP abbia risposto alla sua domanda.

Quanto costa lo sviluppo di un MVP nel Regno Unito? Una web app a percorso unico con un solo tipo di utente sta di norma tra £15.000 e £35.000 in sei o dieci settimane. Due tipi di utente con pagamento e amministrazione di base stanno tra £35.000 e £75.000 in tre o cinque mesi. I prodotti multilaterali con integrazioni o requisiti di conformità partono intorno a £75.000 e richiedono cinque mesi o più.

Qual è la differenza tra un prototipo e un MVP? Un prototipo è usa e getta e risponde a una domanda di progettazione, spesso senza back-end funzionante. Un MVP è codice di produzione con utenti veri e dati veri, costruito per essere esteso se la risposta è sì. Confonderli costa caro in entrambe le direzioni: scartare codice di cui avevate bisogno, oppure sovraingegnerizzare qualcosa che state per buttare via.

Quanto dovrebbe durare la costruzione di un MVP? Da sei a dieci settimane per un’applicazione a percorso unico, da tre a cinque mesi non appena aggiungete un secondo tipo di utente e il pagamento. Se la vostra stima supera i cinque mesi, il perimetro è quasi certamente più ampio di un MVP e conviene ridurlo prima che si costruisca qualcosa, non dopo.

Qual è l’errore più comune con un MVP? Costruire per una scala che ancora non esiste. Code di messaggi, strati di cache e confini a microservizi non reggono alcun carico reale con cinquanta utenti ma vanno comunque costruiti, testati e mandati in esercizio prima del lancio. A un MVP è concesso di essere architetturalmente noioso. Le eccezioni sono il modello dei dati, l’autenticazione e tutto ciò che tocca dati personali, costosi da cambiare in seguito.