Come costruire un MVP senza sviluppatore, e cosa nessuno ti dice prima

Costruire ha smesso di essere il collo di bottiglia. Quasi nessuno ha aggiornato il proprio piano per tenerne conto.

Ecco la domanda che mi viene posta, e la domanda che ci sta sotto.

La domanda posta: posso costruire il mio prodotto senza assumere qualcuno per lo sviluppo? Sì. Nel 2026 una persona sola con strumenti di IA può avere un’applicazione funzionante online in circa una settimana, contro un tempo tradizionale per un MVP di otto a sedici settimane. I dati di Altar.io mettono la media più vicina ai quattro mesi, con tre mesi come valore più comune.

La domanda che ci sta sotto: funzionerà? E la risposta onesta è che dipende da cose che non hanno nulla a che fare con il costruire.

CB Insights ha analizzato 431 aziende finanziate da capitale di rischio che hanno chiuso e ha trovato che il 43% è fallito per scarsa corrispondenza tra prodotto e mercato. Al 70% «sono finiti i capitali», che la stessa analisi tratta come sintomo anziché come causa. Restare senza soldi è ciò che accade lungo la strada verso il problema vero.

Nessuno di quei fallimenti è stato causato da uno sviluppo lento. Il che significa che rimuovere il collo di bottiglia dello sviluppo, da solo, non muove il numero.

Cosa è cambiato con precisione

Non «il software adesso è facile». Qualcosa di più stretto e più utile.

Il costo di produrre un’applicazione è crollato. Il costo di decidere cosa l’applicazione dovrebbe essere non si è mosso affatto.

Per vent’anni il collo di bottiglia dello sviluppo ha nascosto quel secondo costo. Quando costruire richiedeva quattro mesi e 80.000 dollari, i quattro mesi imponevano una forma di disciplina: avevi tempo per parlare con i clienti mentre l’ingegneria lavorava, e la spesa ti faceva pensare prima di impegnarti.

Togli i quattro mesi e ora pensare è facoltativo. È il rischio vero del 2026, ed è nuovo. Puoi costruire la cosa sbagliata molto più in fretta di prima, e sembrerà notevolmente finita mentre è sbagliata.

Le quattro decisioni da prendere prima di promptare qualsiasi cosa

Non un processo. Quattro domande, e puoi rispondere a tutte in un pomeriggio.

1. Per chi è esattamente, e cosa fanno invece oggi?

Non un mercato. Una persona, e il suo aggiramento attuale: un foglio di calcolo, un gruppo su WhatsApp, un’agenzia, tre ore di domenica. Se non riesci a nominare l’aggiramento, non sai ancora se il problema sia reale, perché tutti hanno un aggiramento per i problemi che fanno davvero male.

2. Qual è la sola cosa che deve fare?

L’unica azione che rende migliore la giornata di qualcuno. Tutto il resto è la versione due. Questo conta più di prima, perché gli strumenti di IA costruiranno volentieri tutte le nove funzioni che descrivi, e nove funzioni sono il modo in cui si finisce con un prodotto che nessuno riesce a spiegare.

3. Quali sono le cose nel tuo prodotto, e come si collegano?

È quella che i fondatori saltano, ed è quella che decide se il sesto mese sia sopravvivibile. Utenti, ordini, progetti, fatture: quali che siano i tuoi sostantivi. Quale appartiene a quale. Cosa deve essere unico. Cosa succede quando uno viene cancellato.

Non ti serve vocabolario tecnico. «Un cliente può avere molti progetti, un progetto ha esattamente un proprietario, due clienti non possono condividere un indirizzo di posta elettronica» è un modello dei dati. Scriverlo richiede quindici minuti ed è il quarto d’ora con più leva di tutta l’impresa. Se il vocabolario non ti è familiare, il glossario tecnico copre i termini senza presumere che li conosca già.

4. Come saprai se sta funzionando?

Scegli il numero prima di lanciare, perché dopo il lancio troverai un numero che sembra incoraggiante. Le iscrizioni sono di solito quello sbagliato. Se qualcuno sia tornato una seconda volta è di solito quello giusto.

Perché la terza domanda è quella che morde

Per ciò che accade quando la salti.

Ogni decisione che non prendi esplicitamente viene comunque presa. La prende il generatore, al momento della generazione, da un contesto che non comprende la tua attività. Lo strumento non si ferma a chiedere se due clienti possano condividere un indirizzo di posta elettronica. Sceglie qualcosa di plausibile e va avanti.

Poi al quarto mese ti servono le squadre, o la fatturazione, o un secondo tipo di utente, e si scopre che la risposta scelta in silenzio nella prima settimana rende quel cambiamento una ricostruzione anziché un’aggiunta. Ogni correzione rompe qualcos’altro. Continuare con i prompt peggiora le cose.

Chi costruisce chiama questo il problema del 70%: l’app arriva a quasi finita e smette di avanzare. L’ostacolo non è mai codice mancante. È una decisione presa implicitamente, centinaia di generazioni prima, che non si può più cambiare a basso costo.

La versione di questo su scala di settore è misurabile. La ricerca DORA del 2025 ha trovato che una maggiore adozione dell’IA è associata a una crescita della produttività di rilascio e a una crescita dell’instabilità allo stesso tempo: più rapidi e più fragili, insieme. L’analisi di GitClear su 623 milioni di modifiche al codice ha trovato il codice duplicato in aumento dell’81% rispetto al riferimento del 2023, mentre l’attività di rifattorizzazione è calata dal 21% delle modifiche nel 2022 al 3,8% nel 2026.

La generazione è economica. La coerenza no, e nulla la produce per caso. La pratica costruita per affrontare questo è lo sviluppo guidato dalle specifiche, e la versione architetturale dell’argomento sta qui.

Cosa fare davvero, in ordine

1. Scrivi le quattro risposte. Una pagina. Fallo prima di aprire qualsiasi strumento. Se non riesci a rispondere alla terza domanda, non sei pronto a costruire: sei pronto a parlare con altri due clienti.
2. Scegli uno strumento in base a cosa succede al sesto mese, non a cosa succede questo pomeriggio. Ogni opzione di questa categoria produrrà qualcosa di notevole oggi. Differiscono enormemente sul fatto che tu possa ancora estenderlo dopo. Il panorama, confrontato onestamente.
3. Costruisci la sola cosa. Resisti alla seconda funzione fino a quando qualcuno non ha usato la prima due volte. È molto più difficile di quanto sembri quando aggiungere funzioni è quasi gratis.
4. Mettila davanti a cinque persone vere, non cinquanta. Cinque persone che hanno il problema ti diranno più di cinquanta che stanno essendo gentili. Guarda dove si fermano anziché chiedere se gli è piaciuto.
5. Decidi cosa fai del numero. Se nessuno è tornato, la risposta non è più funzioni. È di nuovo la prima domanda.

Per cosa ti serve davvero ancora qualcuno nello sviluppo

Preferisco essere sincero su questo anziché venderti una fantasia.

Qualsiasi cosa in cui sbagliare è costoso. Pagamenti oltre una cassa standard, dati sanitari, qualsiasi cosa regolamentata. Non perché gli strumenti non sappiano produrla, ma perché non puoi valutare se ciò che hanno prodotto sia sicuro, e in quegli ambiti «sembrava a posto» non è uno standard.

Le migrazioni sotto carico. Cambiare la forma di dati vivi con clienti veri sopra è davvero difficile e va storto in silenzio.

Il momento in cui funziona. È il problema buono. Quando l’uso cresce, serve qualcuno che capisca il sistema e se ne prenda carico. Pianifica quell’assunzione come una pietra miliare del successo anziché come un fallimento da evitare.

Per cosa probabilmente non ti serve qualcuno nello sviluppo: per arrivare al punto in cui sai se qualcuno voglia questa cosa. Prima serviva. Ora no, ed è un cambiamento reale che vale la pena sfruttare.

La trappola della dimostrazione notevole

Una schermata funzionante è enormemente persuasiva, anche per te.

La mostrerai a delle persone e saranno incoraggianti, perché guardare un’interfaccia rifinita produce una reazione diversa dal sentirsi chiedere di cambiare il proprio modo di lavorare. L’incoraggiamento non è una prova. La dimostrazione vale qualcosa solo se qualcuno la usa due volte senza che tu sia nella stanza.

Preferirei vedere un fondatore con un prodotto brutto e quaranta utenti che tornano che uno con un prodotto bello, quattrocento iscrizioni e nessuna seconda visita. Il secondo è molto più facile da ottenere e molto più difficile da recuperare, perché sembra progresso.

La parte che non è diventata più facile

Puoi costruire la cosa in una settimana, ora. È reale, è davvero nuovo, e chi ti dice il contrario non ha provato di recente.

Ma il 43% di quelle 431 aziende chiuse è morto di scarsa corrispondenza tra prodotto e mercato, e nemmeno una è morta perché costruire richiedeva troppo tempo. Il collo di bottiglia si è spostato. Si è spostato sulla parte che è sempre stata quella difficile e che prima era nascosta dietro quattro mesi di ingegneria.

Quali decisioni, in quale ordine, per chi. È questo il lavoro adesso. È sempre stato il lavoro.

Costruire era solo abbastanza rumoroso da coprirlo.

Letture collegate

Sulle decisioni architetturali in particolare, sviluppo SaaS per fondatori non tecnici. Su quanto ti costeranno davvero gli strumenti, gettoni, crediti o sforzo.

Domande frequenti

Si può davvero costruire un’app senza sviluppatore nel 2026? Sì. Una persona senza profilo tecnico può portare online un’applicazione funzionante in circa una settimana usando costruttori di app con IA, contro un tempo tradizionale per un MVP di otto a sedici settimane. Il vincolo non è più se riesci a costruirla: è se hai deciso le cose giuste prima di iniziare.

Quanto tempo serve per costruire un MVP? Tradizionalmente da otto a sedici settimane, con i dati che mettono la media più vicina ai quattro mesi e tre mesi come tempo più comune. Con gli strumenti di IA una persona sola può raggiungere un prodotto funzionante in circa una settimana, anche se quella velocità aiuta solo se le decisioni sottostanti sono state prese deliberatamente.

Cosa dovrei decidere prima di costruire? Quattro cose: per chi è e cosa fanno invece oggi, l’unica azione che il prodotto deve sostenere, quali cose ci sono nel tuo prodotto e come si collegano tra loro, e il numero che ti dirà se sta funzionando. La terza è quella che la maggior parte dei fondatori salta e quella che causa i problemi più costosi più tardi.

Perché gli MVP costruiti dall’IA smettono di funzionare dopo qualche mese? Perché decisioni che nessuno ha preso esplicitamente sono state prese implicitamente dal generatore, e quelle decisioni vincolano tutto ciò che viene dopo. È il problema del 70%: l’app arriva a quasi finita e si arresta, perché l’ostacolo è una scelta architetturale anziché funzionalità mancante.

Devo capire i database per costruire un MVP? Non ti serve vocabolario tecnico, ma ti serve saper dire quali cose esistono nel tuo prodotto e come si collegano. «Un cliente può avere molti progetti, un progetto ha un proprietario, due clienti non possono condividere un indirizzo di posta elettronica» è un modello dei dati espresso in italiano semplice, e scriverlo è una delle cose di maggior valore che puoi fare.

Quando mi serve davvero assumere qualcuno per lo sviluppo? Per qualsiasi cosa in cui sbagliare è costoso (dati regolamentati, pagamenti oltre la cassa standard) perché non puoi valutare se il risultato sia sicuro. Per migrare dati vivi sotto carico. E quando il prodotto inizia a funzionare e qualcuno deve prendersi carico del sistema come si deve. Tratta quest’ultimo punto come una pietra miliare del successo.

Quanto costa costruire un MVP senza sviluppatore? Gli strumenti vanno dai livelli gratuiti a qualche centinaio di dollari al mese secondo quanto iteri, che è drasticamente meno di una costruzione tradizionale. I costi che colgono di sorpresa i fondatori sono quelli dopo il lancio: l’hosting mentre l’uso cresce, e la ricostruzione se l’architettura iniziale non può sostenere la prossima funzione.