Elena Marchetti, YuSMP Group
Elena Marchetti Head of Product, YuSMP Group · 12+ anni di rilascio SaaS B2B per team statunitensi ed europei

Come usare la checklist

Ogni punto è classificato come obbligatorio (non si lancia senza), default consigliato (da saltare solo con una motivazione scritta) oppure opzionale (rinviabile al post-lancio se necessario). Per ogni punto, occorre annotare il responsabile (PM, ingegnere, fondatore, avvocato) e la prova (URL, screenshot, link al risultato del test). “Fatto” senza prova non è fatto.

La checklist dovrebbe essere percorribile dall’inizio alla fine in 2–4 ore con il team riunito in una stanza. Se richiede più tempo, qualcosa non è chiaro e il prodotto non è pronto.

Prodotto (1–6)

  1. Il posizionamento in una frase è scritto e testato. Obbligatorio. La versione in 8 parole che un cliente ripeterà a un collega. Testata su 5 utenti target.
  2. Il flusso principale funziona end-to-end senza assistenza. Obbligatorio. Registrazione → attivazione → momento di valore → pagamento, senza operazioni manuali nel mezzo.
  3. Gli stati vuoti sono progettati. Default consigliato. Ogni lista, ogni dashboard, ogni feed ha uno stato vuoto significativo, non uno schermo bianco.
  4. Gli stati di errore sono progettati e comprensibili. Default consigliato. “Qualcosa è andato storto” è un fallimento del prodotto, non un messaggio di errore.
  5. L’onboarding si completa in meno di 4 minuti. Default consigliato. Misurato, non presunto. Il time-to-value è la metrica più importante per un MVP.
  6. La pagina dei prezzi rispecchia l’implementazione di fatturazione effettiva. Obbligatorio. Se la pagina dice “cancellazione in qualsiasi momento” e il flusso di cancellazione richiede 4 email, si ha una contestazione di addebito in attesa.

Ingegneria (7–14)

  1. Tutti gli ambienti usano IaC. Default consigliato. Terraform, Pulumi o SST. L’infrastruttura gestita a clic è un blocco al lancio entro il terzo mese.
  2. La pipeline CI gira su ogni PR. Obbligatorio. Lint, typecheck, test unitari, build. Sotto i 10 minuti end-to-end.
  3. Le migrazioni del database sono solo in avanti e idempotenti. Obbligatorio. Sqitch, Flyway, Prisma Migrate o Drizzle Kit. Niente “eseguire questo SQL a mano in produzione.”
  4. I segreti sono in un vault, non nei file env. Obbligatorio. AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Doppler. Ruotati.
  5. I backup sono stati testati. Obbligatorio. Non solo configurati — ripristinati almeno una volta dai dati di produzione su un DB fresco.
  6. Rate limiting sugli endpoint di autenticazione e pagamento. Obbligatorio. Minimo 100 req/min per IP; limiti più stringenti su registrazione, login, reset della password.
  7. Le build mobile sono firmate con i certificati di distribuzione corretti. Obbligatorio se c’è mobile. Perdere il certificato significa perdere la possibilità di rilasciare aggiornamenti.
  8. Un ambiente di staging esiste ed è in uso. Default consigliato. Stessa struttura del produzione, alimentato da dati anonimizzati. Le anteprime PR sono comode; lo staging è obbligatorio.

Sicurezza & conformità (15–22)

  1. HTTPS ovunque con HSTS. Obbligatorio. Nessun contenuto misto. HSTS preload inviato.
  2. La Content Security Policy è impostata e testata. Default consigliato. Anche una CSP permissiva blocca intere classi di XSS.
  3. L’autenticazione usa un provider gestito. Obbligatorio. Clerk, Auth0, Supabase Auth, WorkOS, FusionAuth — non sviluppato internamente.
  4. Le password sono hashate con bcrypt/Argon2id. Obbligatorio se si gestisce l’autenticazione internamente. Testo in chiaro o MD5 nel 2026 è imperdonabile.
  5. RLS impone l’isolamento del tenant (SaaS multi-tenant). Obbligatorio. Vedi architettura SaaS multi-tenant.
  6. La scansione delle dipendenze gira in CI. Default consigliato. Dependabot, Renovate, Snyk. Le CVE critiche bloccano il merge.
  7. Esiste un runbook per gli incidenti. Obbligatorio. Chi è di turno, come dichiarare un incidente, come comunicare con i clienti, come fare il post-mortem.
  8. Il flusso di cancellazione dei dati GDPR/CCPA funziona. Obbligatorio con utenti UE o californiani. Il test end-to-end copre la cancellazione avviata dall’utente su DB, blob, analisi e log.

Fatturazione & pagamenti (23–28)

  1. Stripe in modalità produzione, webhook verificati. Obbligatorio. Modalità test = nessun ricavo.
  2. Il gestore dei webhook è idempotente. Obbligatorio. Stripe riprova; senza idempotenza si fattura due volte.
  3. I pagamenti falliti attivano il dunning. Obbligatorio. Smart Retries attivati, email di dunning configurate.
  4. Il flusso di cancellazione rispetta la legge. Obbligatorio. La legge UE e le regole FTC click-to-cancel degli USA richiedono parità con il flusso di registrazione.
  5. IVA/tasse sulle vendite gestite. Obbligatorio per vendite UE. Stripe Tax o Quaderno coprono la maggior parte dei casi.
  6. Il flusso di rimborso ha un runbook documentato. Default consigliato. Anche gli MVP ricevono richieste di rimborso nella prima settimana.

Osservabilità & affidabilità (29–34)

  1. Tracciamento degli errori con stack trace. Obbligatorio. Sentry, Rollbar, Bugsnag. Collegato alle release per trace con source mapping.
  2. Log strutturati. Obbligatorio. Log JSON, request ID propagato end-to-end, tenant ID su ogni riga di log per il multi-tenant.
  3. Dashboard di metriche di base. Default consigliato. Latenza, tasso di errore, throughput. Livello gratuito Datadog, Grafana Cloud gratuito o Prometheus self-hosted.
  4. Controlli di uptime dall’esterno della propria infrastruttura. Obbligatorio. Better Uptime, Healthchecks.io, Pingdom. Almeno due regioni.
  5. Gli alert raggiungono una persona, non solo un canale Slack. Obbligatorio. PagerDuty, OpsGenie, o un numero di telefono. I canali vengono silenziati; le persone vengono svegliate.
  6. Esiste una pagina di stato. Default consigliato. statuspage.io, Instatus, BetterStack Status. I clienti si fideranno di più per chi ammette i disservizi piuttosto che nasconderli.

Analisi & crescita (35–39)

  1. Analisi del prodotto strumentata con 5–10 eventi nominati. Obbligatorio. PostHog o Amplitude. Attivazione, retention, conversione, engagement e eventi di valore specifici del prodotto.
  2. Il funnel dalla landing page al pagamento è misurabile. Obbligatorio. Deve essere possibile rispondere in 60 secondi a «quanti visitatori della settimana scorsa hanno pagato?»
  3. Il tagging UTM è coerente tra i canali. Default consigliato. Altrimenti l’attribuzione è fiction.
  4. Il sito marketing ha il markup Schema.org e una sitemap. Default consigliato. Vedi SEO tecnico & crescita.
  5. Esiste un loop di feedback nel prodotto. Default consigliato. Widget di feedback Linear, Canny o una semplice email. Da usare dal primo giorno.
  1. Privacy policy + consenso ai cookie + template DPA. Obbligatorio. Revisionato da un avvocato per qualsiasi traffico UE. Non copiare da un altro sito.
  2. Termini di servizio. Obbligatorio. Limitazione di responsabilità, legge applicabile, uso accettabile, politica di rimborso.
  3. Il banner di consenso ai cookie blocca correttamente i cookie non essenziali fino al consenso. Obbligatorio per l’UE. Klaro, Cookiebot, Iubenda. Il solo “Accetta tutti” non è più conforme.

Marketing & lancio (43–45)

  1. La landing page supera i Core Web Vitals. Default consigliato. LCP < 2,5s, CLS < 0,1, INP < 200ms su mobile. PageSpeed score 90+.
  2. Open Graph e Twitter Cards configurati. Default consigliato. Testare con i debugger ufficiali delle card, non solo con gli strumenti per sviluppatori.
  3. Le comunicazioni di lancio sono redatte. Default consigliato. Email alla lista d’attesa, post sui social, bozza per Product Hunt, post LinkedIn del fondatore. Redatti, non solo pianificati.

Operazioni post-lancio (46–47)

  1. Il supporto è presidiato. Obbligatorio. Una persona reale risponde entro 4 ore nei giorni lavorativi, entro 24 ore altrimenti. Email + in-app come minimo.
  2. La roadmap ha un bucket “settimana uno”, “mese uno” e “trimestre uno”. Obbligatorio. Capacità pre-allocata per i bug inevitabili e le piccole correzioni. Senza di essa, il team va in burnout entro la terza settimana.
Dashboard di lancio MVP con checklist semaforo approvazione/rifiuto
47 punti. 2–4 ore con il team in una stanza. Se un punto obbligatorio è rosso, non si lancia.

FAQ

Quanti punti deve avere una checklist di lancio MVP?

La nostra lista di produzione prevede 47 punti in nove categorie. Meno di ~30 trascura attività critiche; più di ~70 è sovradimensionato.

Qual è il punto più spesso saltato prima del lancio di un MVP?

L’osservabilità in produzione. I fondatori lanciano senza tracciamento degli errori e scoprono nella seconda settimana che il 14% degli utenti incappa silenziosamente in un percorso di errore.

Ho bisogno di una privacy policy per il mio MVP?

Sì. Anche piccole basi utenti UE/USA attivano gli obblighi GDPR/CCPA. Non è facoltativo.

L’MVP deve avere un pannello di amministrazione?

Sì — uno semplice. Retool, Forest Admin o un admin in-app da 1 giorno. Fa risparmiare 5–10 ore di supporto a settimana.

Quanti test necessita un MVP?

Test unitari su pagamenti, autenticazione e isolamento del tenant. Test smoke con Playwright su 3–5 flussi critici. Evitare E2E esaustivi.

Quali metriche occorre strumentare prima del lancio?

Attivazione, retention (D1/D7/D30), conversione (da gratuito a pagante), engagement e una metrica di valore specifica del prodotto. PostHog o Amplitude nel livello gratuito copre tutto.

Richiedi un audit di lancio prima di rilasciare

Una giornata di ingegneria senior. Lista con semaforo rosso/arancione/verde, le correzioni più rischiose in ordine di priorità, parere scritto di approvazione o bocciatura. Utile prima del lancio, prima di un round di finanziamento, prima dei piloti enterprise.

Ultimo aggiornamento: 26 maggio 2026.