MVP in 4 settimane: la checklist da dare allo sviluppatore prima di iniziare

"Costruisci un MVP in 4 settimane" è una frase che vuol dire 5 cose diverse a 5 persone diverse. Per un founder è "voglio qualcosa che gira e che posso mostrare a 50 utenti". Per uno sviluppatore senior è "il backbone tecnologico che reggerà la crescita futura". Per un investor è "una demo cliccabile che mi convinca a metterci €100k".

Tutte e tre le interpretazioni sono legittime. Il problema è che il prezzo, il tempo e la qualità sono molto diversi. Se non chiarisci a chi stai costruendo l'MVP prima del primo commit, finisci per costruire la cosa sbagliata e dover rifare in 3 mesi.

Questa è una checklist concreta delle 12 cose da chiarire con il tuo sviluppatore prima di iniziare. Le abbiamo distillate guardando dove falliscono i progetti web-published su DevLink: 8 volte su 10, l'origine del problema è una di queste 12 caselle non riempite.

Le 3 caselle scope

1. Chi è l'utente target dell'MVP? Non "tutti i ristoranti" — molto più specifico. "I 200 ristoranti indipendenti del centro Milano che ora fanno menu su carta". Più stretto è meglio: lo sviluppatore può fare scelte tecniche ottimali per quel segmento (es. niente multi-lingua se non serve, niente ottimizzazione enterprise se sono 200 utenti).

2. Quale è la UNA azione che l'utente deve completare? Un MVP fa benissimo una sola cosa, non 7 cose mediocri. "L'utente apre l'app, scansiona il QR del tavolo, ordina, paga". Questo è uno scope da 4 settimane. "L'utente apre l'app, ordina, parla con il cameriere via chat, lascia recensione, accumula punti, condivide su socials" è uno scope da 6 mesi.

3. Cosa NON è nello scope? Sembra ovvio ma è la casella più importante. Scrivi nero su bianco le 5 feature ovvie che l'MVP NON avrà: "no admin panel", "no analytics avanzati", "no integrazione CRM", "no app Android (solo iOS)", "no multi-lingua". Tieni questa lista alla portata e quando arriva la richiesta a settimana 3 "ah ma serve anche...", puntala.

Le 4 caselle tecniche

4. Quale stack ti propone lo sviluppatore e perché? Non importa quale risponda — importa che sappia spiegare il "perché". Flutter? Perché vuoi mobile cross-platform e niente differenze visuali tra iOS e Android. Next.js? Perché vuoi che sia indicizzabile da Google. Se la risposta è "uso quello, è il mio preferito", red flag.

5. Dove gira l'app in produzione? Vercel + Firebase è una combo standard veloce. AWS bare-metal è overkill per un MVP. Decidi questo prima del primo commit perché alcune scelte tech (es. database) cambiano in base all'hosting.

6. Chi è il proprietario del codice durante e dopo? Tu. Sempre tu. Lo sviluppatore freelance scrive il codice DENTRO la TUA GitHub organization, con il TUO account owner. Se ti dice "ti consegno alla fine via zip", red flag grosso. Vuoi vedere ogni commit in tempo reale.

7. Come funzionano i deploy? Manuale o automatico? Pre-prod prima di prod? Branch protection su main? Queste cose sembrano dettagli ma fanno la differenza tra "MVP che gira ma è fragile" e "MVP che gira ed è mantenibile".

Le 3 caselle processo

8. Demo settimanale fissa. Ogni venerdì alle 17, 30 minuti, schermo condiviso, ti mostra cosa è cambiato. Non "quando è pronto", non "quando ha qualcosa da mostrare" — FISSA. Anche se la demo è "questa settimana ho finito il backend e l'app non si vede ancora", va bene. Il punto è la cadenza, non la sostanza.

9. Canale di chat dove tu puoi vedere quello che chiede a Stack Overflow / ChatGPT. Non per controllarlo, per imparare. Un buon freelance condivide link e screenshot di cose che sta valutando. Se non condivide niente per 4 settimane è perché o non sta lavorando o sta facendo tutto da solo (entrambe le cose sono male).

10. Chi prende le decisioni di scope micro? "Il bottone deve essere arancione o rosso?" non vale 30 min di call. Definisci a inizio progetto: "Per decisioni che costano meno di 1 ora di lavoro, decidi tu" — questo libera lo sviluppatore da essere bloccato per il tuo OK su micro-cose.

Le 2 caselle finali

11. Cosa significa "consegnato"? Definizione di Done concreta: "MVP è pronto quando un utente può scaricare l'app dallo store, registrarsi, completare l'azione X, e ricevere conferma email". Non "è pronto quando funziona". La seconda è discutibile, la prima no.

12. Cosa succede dopo la consegna? Hai 1 mese di support per bug fix? Va a tariffa oraria? Tu vuoi imparare a manutenere o vuoi un retainer? Queste cose vanno chiarite PRIMA di iniziare. Dopo, quando arriva il primo bug grave 2 settimane dopo la consegna, se non hai un piano sei nel panico.

La timeline realistica per un MVP da €5-10k

Per un MVP nel range €5-10k (mobile cross-platform, ~5 schermi, backend semplice con auth + database + 1 integrazione), ecco cosa ti aspetti:

• Settimana 1: kickoff + setup tecnico (repository, hosting, design system base) + scope finale documentato
• Settimana 2: backbone backend (auth, database schema, API base) + UI scheletro
• Settimana 3: feature principale end-to-end + prima demo cliccabile
• Settimana 4: polish, edge case, deploy production, primo testing reale

Se nella settimana 3 ricevi una demo che fa solo "il login funziona", c'è un problema di velocità. Se ricevi "tutto pronto, manca solo polish", c'è un problema di scope (ne hai messo troppo poco).