MVP per startup: cosa costruire prima, cosa evitare
Il primo MVP non deve essere il prodotto finale. Deve dimostrare un'ipotesi commerciale. Linee guida pratiche per non sprecare i primi 6 mesi.
Gianmarco Pacetti
L'errore più comune che vedo nei founder al primo prodotto è costruire troppo. Sei mesi, 50k€, e un MVP che fa tutto bene tranne quello che doveva fare: dimostrare che qualcuno è disposto a pagare. È un errore costoso, evitabile, e ricorrente — anche tra fondatori esperti che dovrebbero saperne di più.
In questo articolo metto a fuoco cosa dovrebbe contenere un MVP nel 2026 e cosa non deve assolutamente contenere. È materiale che ho rifinito accompagnando una dozzina di startup dalla fase 0 ai primi clienti paganti.
Cos'è davvero un MVP
“
Un MVP è la versione più piccola e più semplice del tuo prodotto che permette di dimostrare l'ipotesi più rischiosa del tuo modello di business.
Notare le parole: più piccola, più semplice, ipotesi più rischiosa. Non c'è scritto "carino", non c'è scritto "scalabile", non c'è scritto "tecnologicamente perfetto".
L'ipotesi più rischiosa di solito è una di queste:
C'è qualcuno disposto a pagare per questo?
Il problema che risolvo è abbastanza grande da farglielo cercare attivamente?
La mia soluzione funziona meglio dell'alternativa attuale (anche se questa è "non fare nulla")?
Se il tuo MVP non risponde a nessuna di queste, non è un MVP, è un demo.
Le 4 categorie di MVP (e quando usare quale)
1. Landing page MVP (test di domanda)
Blog
Continua a leggere
Raccontaci cosa vuoi costruire
Che si tratti di un sito, un gestionale, un’automazione o una nuova piattaforma, ti aiutiamo a capire la soluzione più adatta.
La cosa più piccola che puoi fare: una landing page con copy chiaro, screenshot finto del prodotto, e bottone "Iscriviti alla beta". Misuri quanti si iscrivono.
Quando usarla: quando non sei sicuro che il problema esista davvero.
Tempo di costruzione: 3-5 giorni
Costo: 500-2000€
Cosa misura: domanda di base
2. Concierge MVP (servizio manuale, prodotto digitale)
Il prodotto finale sarà automatico, ma all'inizio fai tutto a mano dietro le quinte. Il cliente vede un'interfaccia, dietro c'è una persona (tu) che fa il lavoro.
Esempio: un'app per ottimizzare la SEO. Versione MVP: il cliente compila un form, tu personalmente generi il report in Notion in 2 ore, lo mandi via email. Funziona? Allora puoi automatizzare. Non funziona? Hai risparmiato 6 mesi di codice.
Quando usarla: quando il valore è chiaro ma vuoi validare che le persone usino davvero il flusso.
Tempo di costruzione: 2-4 settimane
Costo: 3-10k€
Cosa misura: utilizzo reale + willingness to pay
3. Single-feature MVP (una sola cosa, fatta bene)
Costruisci una sola feature, ma quella vera: la più importante per il valore al cliente. Niente login social, niente dashboard, niente pannello admin elegante. Solo la cosa che il cliente paga per fare.
Esempio: se costruisci uno strumento per generare contratti, il MVP è "carica un PDF di template, compila i campi, esporta". Stop. Niente storico contratti, niente collaborazione, niente firma digitale. Solo la cosa.
Quando usarla: quando hai validato il problema e devi validare la soluzione tecnica.
Tempo di costruzione: 6-12 settimane
Costo: 15-35k€
Cosa misura: feasibility tecnica + retention
4. Closed-beta MVP (10 utenti, supporto manuale ad altissima intensità)
Versione completa ma chiusa a massimo 10-20 utenti, scelti uno per uno. Supporto via WhatsApp 24/7. L'obiettivo non è scalare, è imparare.
Quando usarla: quando hai bisogno di iterazione veloce con feedback qualitativo profondo.
Tempo di costruzione: 8-16 settimane
Costo: 25-60k€
Cosa misura: retention + product/market fit qualitativo
Cosa NON deve avere un MVP
Lista nera di feature che vedo aggiungere "perché sennò non è serio":
❌ Sistema di pagamenti se non hai ancora dimostrato che qualcuno vuole pagare (usa Stripe Payment Link manuale)
❌ Multi-tenancy / multi-organizzazione se il primo cliente è ancora un'ipotesi
❌ Localizzazione in 5 lingue
❌ App mobile nativa se la web responsive è sufficiente
❌ Login social (email + password è OK per i primi 100 utenti)
❌ Onboarding flow elaborato con tutorial interattivo
❌ Sistema di permessi/ruoli articolato
❌ Audit log
❌ Notifiche push
❌ Dashboard analytics interna
Ogni feature in questa lista significa 2-4 settimane di lavoro in più prima di parlare col primo cliente. Sono settimane bruciate prima di sapere se il prodotto serve.
Lo stack tecnico che consiglio per gli MVP
Nel 2026 c'è uno stack quasi obbligato per startup early-stage:
Frontend: Next.js 16 + Tailwind (tutti i pattern già pronti)
Backend: Server Actions di Next.js o tRPC (zero overhead)
Database: Postgres su Neon o Supabase (gratis fino a un certo punto, scalabile)
Auth: Auth.js / Clerk / Supabase Auth (5 minuti di setup)
Email transazionali: Resend (DX migliore di SendGrid)
Hosting: Vercel (zero ops, scaling automatico)
Analytics: PostHog o Plausible
Stack costo zero per i primi mesi, scala bene fino ai primi 10k MAU senza dover riarchitettare.
Il framework decisionale che uso per i clienti
Quando un founder mi contatta per un MVP, faccio queste 4 domande:
Qual è la cosa più rischiosa che non sai di sicuro nel tuo modello?
Qual è la più piccola cosa che puoi costruire per scoprirlo?
Quanti utenti ti servono per essere convinto della risposta?
Quanto tempo hai prima di doverlo dimostrare?
Da queste 4 risposte esce sempre il tipo di MVP giusto (landing, concierge, single-feature, closed-beta) e una stima realistica di tempo + budget.
Se stai partendo ora
Se sei a inizio di un progetto e vuoi capire la versione minima che ha senso, scrivimi. Faccio anche workshop di 2-3 ore per founder che vogliono validare l'idea prima di spendere — costano meno di una giornata di sviluppo e spesso evitano mesi di lavoro nella direzione sbagliata.
