Lovable, Bolt, v0: quando gli MVP vibe-coded diventano un mutuo di debito tecnico

Le app vibe-coded come Lovable, Bolt e v0 sono eccellenti per i prototipi e inadatte come MVP di produzione. Ogni volta che se ne riceve una in eredità, la ricostruzione da zero è inevitabile, perché sistemare struttura, hook e autenticazione costa più che ricominciare. Questo articolo traccia il confine tra il prototipo che questi strumenti possono sostenere e l'MVP che non possono.

Ora tutti sanno programmare. Un founder senza esperienza tecnica può descrivere un SaaS in italiano semplice il sabato mattina e avere qualcosa su un URL pubblico prima di pranzo. Si tratta di un vero cambiamento nel modo in cui nasce il software, ed è in gran parte positivo. Ha però generato un nuovo tipo di fallimento che non esisteva due anni fa: app in produzione che nessuno in azienda sa leggere.

Ogni settimana ci sono founder che hanno pubblicato una build con Lovable, firmato i primi tre clienti e poi si sono scontrati con un muro che non riescono a descrivere. La piattaforma ha fatto il lavoro. La piattaforma ha anche preso ogni decisione architetturale prima che il founder capisse quali fossero importanti.

Questo articolo non attacca Lovable, Bolt o v0. Hanno un ruolo legittimo nella fase di prototipazione. La linea viene tracciata dal lato del cliente: cosa producono questi strumenti rispetto a ciò di cui un MVP ha bisogno per sopravvivere al primo cliente pagante, più il pattern di cleanup ricorrente in ogni codebase ricevuta in eredità.

• Il vibe-coding vince nella fase di prototipo, dove la velocità conta più della struttura e nulla arriva ai clienti.
• Gli MVP falliscono in modo diverso rispetto ai prototipi. Autenticazione, multi-tenancy, un pannello di amministrazione e l'osservabilità sono irrinunciabili nel momento in cui un cliente reale accede.
• Il costo del cleanup è il costo della ricostruzione. Ogni MVP vibe-coded ricevuto in eredità viene ricostruito da zero. La build con Lovable era un costo affondato, non tempo risparmiato.
• Il pattern è costante. Struttura scadente, uso errato di useEffect, re-render inutili, rotte backend aperte, autenticazione raffazzonata: sempre in quest'ordine.
• Usi Lovable per ciò in cui eccelle. Demo, mockup interni, esplorazione di idee. Si assumano ingegneri per qualsiasi cosa per cui un cliente paghi.

Ora tutti sanno programmare (e va quasi bene così)

Nel 2025 la barriera all'ingresso per "ho costruito qualcosa" è crollata. v0 genera un componente Next.js da uno screenshot, Lovable crea uno scaffold di backend Supabase da un paragrafo, Bolt assembla un'app già deployata in una singola chat e Replit Agent gestisce l'intero ciclo finché qualcosa compila.

Questo rappresenta un vantaggio reale per l'esplorazione delle idee. Un non-tecnico che una volta impiegava tre settimane per trovare un freelancer ora può validare l'idea in pixel reali in tre ore. Un designer può costruire la demo per il suo pitch invece di mockupparla in Figma. Nessuno di questi casi d'uso richiede disciplina da produzione.

Il problema inizia al passo successivo, quando il prototipo viene ribattezzato "MVP", mostrato a un cliente pagante e trattato come software di produzione. Gli strumenti non segnalano quando si attraversa quel confine. Il founder raramente sa di averlo attraversato.

La linea del prototipo e la linea dell'MVP

Un prototipo è una domanda. Un MVP è un contratto.

Un prototipo chiede: questa idea ha senso in pixel? Gira in locale, fallisce in modo rumoroso e non viene consegnato a nessuno. Il modo di fallire è "noto che c'è qualcosa di sbagliato e correggo il prompt." È un artefatto di apprendimento, e le uniche persone esposte sono il founder e un complice di fiducia.

Un MVP è la prima versione che i clienti paganti toccano. Nel momento in cui denaro o dati personali cambiano di mano, anche il contratto implicito cambia. Il cliente si aspetta che il suo accesso continui a funzionare, che i suoi dati rimangano privati e che l'app non perda la sua sessione perché un useEffect è stato eseguito due volte. Non sono requisiti avanzati: sono il minimo indispensabile.

Il motivo per cui la maggior parte delle app vibe-coded attraversa questo confine silenziosamente è che lo strumento continuava a dire "production-ready" mentre produceva un prototipo. Il controllo che rileva il passaggio è umano, non tecnico: un founder che sa cosa deve fare un MVP prima di poter accettare denaro.

Quando il confine ha rilevanza economica, la mossa giusta è assumere ingegneri, non usare un prompt più veloce. webvise realizza build MVP con una timeline fissa da 3 a 5 settimane, con autenticazione, fatturazione, pannello di amministrazione e osservabilità inclusi fin dal kickoff.

Cosa si trova davvero nelle codebase vibe-coded

Quando un founder consegna un progetto Lovable o Bolt e chiede una revisione, il pattern è così costante da poter anticipare cosa ci sarà prima che il repo finisca di clonare. Cinque problemi, grosso modo nell'ordine in cui fanno male.

Struttura scadente. File nominati in base al prompt che li ha generati, componenti annidati a quattro livelli senza confini di riuso, una cartella "utils" che contiene tutta la business logic dell'app. La codebase è la trascrizione di come l'AI ha pensato, non una descrizione di ciò che l'app fa. Aggiungere una feature significa leggere metà del progetto per trovare dove vive lo stato.

Uso errato di useEffect. Ogni fetch vive in un useEffect, ogni cambio di prop scatena un re-fetch e gli effect dipendono da oggetti ricreati a ogni render. L'app bombarda il backend con richieste duplicate al primo caricamento, poi si blocca quando una di quelle richieste fallisce in silenzio. Il pattern si aggrava nel momento in cui si aggiungono i form.

Re-render inutili. Lo stato di livello superiore vive in un context provider che avvolge l'intera app, quindi ogni componente esegue il re-render a ogni keystroke. L'app sembra lenta con 10 elementi in una lista e inutilizzabile con 100. La correzione richiede una vera conoscenza di React che il prompt non ha mai richiesto.

Rotte backend aperte. Tabelle Supabase con RLS disabilitato o impostato su "authenticated" senza scoping per riga, server action che si fidano di un user_id inviato dal client, edge function che accettano qualsiasi payload perché la validazione viveva nel form. Un utente in una finestra in incognito può elencare ogni riga della tabella.

Autenticazione raffazzonata. Controlli di sessione eseguiti lato client, controlli sui ruoli basati su confronti di stringhe con campi inventati dall'AI, flussi di reset della password che inviano lo stesso formato di token a ogni utente, segreti JWT nel file .env.example committato nel repo pubblico. A volte la chiave anonima è l'unica cosa che separa l'app da "ora sono admin."

Non sono casi limite. Sono il risultato mediano di "l'AI ha spedito questo senza un ingegnere nel ciclo", tema affrontato dal punto di vista tecnico in perché il software generato dall'AI ha ancora bisogno di revisione ingegneristica.

"Funziona" è il segnale peggiore su cui fare affidamento

Le app vibe-coded superano spesso la prima demo, ed è lì che inizia il pericolo. La demo gira, i primi 10 amici si iscrivono, il primo cliente paga e il founder conclude che la build era a posto.

Il debito tecnico si accumula silenziosamente finché qualcosa non lo porta allo scoperto. I fattori scatenanti sono prevedibili:

• Primo cliente pagante reale. I suoi dati attraversano il confine di autorizzazione. Il confine manca o è sbagliato. Lo si scopre tramite un ticket di supporto, non un test CI.
• Prima feature request dopo il lancio. Il modello dati dell'AI presupponeva un utente per workspace. Il cliente ne vuole due. Aggiungere il secondo utente tocca 14 file che nessuno ha mai letto.
• Prima revisione di sicurezza. Un prospect B2B chiede documenti SOC2 o un pentest. Il pentester trova le rotte aperte in 20 minuti. La trattativa si blocca o salta.
• Prima necessità amministrativa. Il founder deve rimborsare un cliente, bloccare un bot o consultare le iscrizioni della settimana scorsa. Non c'è una pagina di amministrazione e non c'è modo di aggiungerne una senza rifare il routing.
• Primo evento di scaling. Un articolo sul blog porta traffico, le visite aumentano di colpo e l'app crolla perché ogni render recupera tutte le righe. La correzione è il problema dei re-render descritto sopra.

Ogni fattore scatenante trasforma debito invisibile in un'interruzione del servizio, una trattativa persa o un rimborso. Il tasso di interesse sul debito vibe-coded è variabile e la banca chiama sempre nel momento peggiore.

La regola della ricostruzione al 100%

Per gli MVP vibe-coded ricevuti in eredità esiste una regola che non è mai stata violata una sola volta: si ricostruisce da zero.

Il ragionamento è aritmetico. Per recuperare una codebase Lovable bisogna leggere ogni file scritto dall'AI, documentare il modello dati che il founder non ha mai visto, districare la catena di useEffect, bloccare le rotte, correggere l'autenticazione e rifattorizzare la struttura in qualcosa che un essere umano possa estendere. Quel lavoro equivale a una ricostruzione completa con un vincolo in più: non rompere i clienti che stanno già usando la versione difettosa.

Una ricostruzione pulita sullo stack consolidato richiede da 3 a 6 settimane. Un recupero richiede da 8 a 12 settimane, perché ogni fase di cleanup è vincolata dallo schema precedente e dai dati in produzione. I "risparmi" dalla build Lovable originale non esistono: erano anticipi sul prossimo ciclo di lavoro.

La formulazione onesta per un founder: la build con Lovable ha pagato per la validazione. Ha portato i primi clienti, e questo ha un valore reale. Il codice stesso è un costo affondato. L'MVP inizia adesso.

Come appare un MVP vero

Per fare un confronto, webvise ha consegnato un MVP in produzione per un servizio immobiliare che emette certificati di finanziamento per acquirenti immobiliari, usando un workflow personalizzato invece di uno scaffold vibe-coded.

La build è una piattaforma full-stack con un workflow di finanziamento come elemento centrale di conversione, una dashboard amministrativa per gestire il ciclo di vita delle richieste e generazione automatica di certificati PDF entro la finestra di servizio promessa. Lo stack è Next.js con tRPC per type safety end-to-end, Drizzle su Neon Postgres e Better Auth per la gestione delle sessioni. Il contratto era a prezzo fisso.

Questa tempistica non è magia. Circa l'85% di ogni nuovo progetto sullo stack è cablaggio già presente nel progetto precedente, perché la stessa configurazione Next.js, React, tRPC, Drizzle, Neon, Better Auth, Polar, AI SDK 6 via Vercel AI Gateway e Inngest viene applicata a ogni incarico. Il restante 15% è il lavoro davvero unico per il cliente: la logica di dominio, il modello dati, i flussi di lavoro. Gli strumenti AI accelerano quel 15% all'interno della struttura esistente, non la sostituiscono.

Questa è la versione di "MVP AI-native" che sopravvive al primo cliente pagante.

Quando usare comunque Lovable, Bolt o v0

La scelta giusta dipende dalla fase: vibe-coding per demo ed esplorazione, ingegneri per i percorsi di prodotto a pagamento.

La mossa onesta per un founder è pubblicare il prototipo su Lovable, validare e poi assumere ingegneri prima che arrivi il primo cliente pagante. L'errore è lasciare che "funziona" trasporti la build oltre il confine da solo.

webvise realizza build MVP in 3 a 5 settimane sullo stesso stack usato per i SaaS in produzione. Autenticazione, fatturazione, amministrazione e osservabilità sono inclusi fin dal primo giorno. Se ha una build vibe-coded che funziona oggi ma la sta ostacolando, descriva cosa sta riscontrando per capire se si tratta di un cleanup o di una ricostruzione. Finora la risposta è sempre stata una ricostruzione.