Dal prototipo al prodotto reale: cosa manca ancora

Nei moduli precedenti hai visto come nasce un progetto su Lovable, come si pianifica con l'AI prima di costruire, come si integra una API esterna e come si collega tutto a GitHub per non perdere il lavoro. Se hai seguito il percorso, probabilmente hai già qualcosa che funziona: un'app che si apre, che fa quello che le hai chiesto, che puoi mostrare con orgoglio a un amico o a un cliente. È un traguardo vero. Ma è anche il punto in cui nasce la domanda più importante di questo modulo: quello che hai costruito è pronto per essere usato da persone reali, con dati reali?

La risposta, quasi sempre, è: non ancora del tutto. E questa lezione serve proprio a spiegare, senza allarmismi ma senza edulcorare, dove sta il divario.

## In breve

Un prototipo Lovable dimostra che un'idea funziona. Un prodotto in produzione deve reggere l'uso reale: persone che si registrano davvero, dati che vanno protetti davvero, pagamenti che devono davvero arrivare, errori che prima o poi succedono davvero. Il divario tra i due riguarda soprattutto cinque aree: come sono strutturati e protetti i dati, come funziona l'autenticazione, cosa succede quando qualcosa va storto, come si gestiscono i pagamenti se servono, e chi si occupa della manutenzione dopo il lancio. Nessuna di queste cose è impossibile da affrontare da soli con Lovable, ma nessuna va data per scontata solo perché il prototipo "funziona".

Che cos'è il divario prototipo-prodotto (e cosa non è)

Il divario tra prototipo e prodotto non è una questione di "saper programmare o no". Non è nemmeno un giudizio sulla qualità di quello che hai costruito finora: un prototipo che fa il suo lavoro, validare un'idea, mostrarla a qualcuno, testarla con te stesso, ha già avuto successo nel suo scopo.

Quello che è, invece, è la differenza tra un ambiente controllato (tu che usi la tua app, con i tuoi dati di prova, in un momento che scegli tu) e un ambiente che non controlli più: utenti sconosciuti, orari imprevedibili, dati veri, connessioni lente, un pulsante cliccato due volte per errore, una carta di credito rifiutata. Il prototipo deve funzionare nel percorso "felice", quello che hai testato tu. Il prodotto deve reggere anche quando qualcuno esce da quel percorso.

Come funziona (cosa cambia davvero)

Lovable genera in automatico gran parte dell'infrastruttura di un'app, schermate, logica, spesso anche un database tramite l'integrazione nativa con Supabase. Questo è ciò che rende possibile costruire un prototipo funzionante in ore invece che in settimane. Ma la documentazione ufficiale di Lovable è chiara su un punto: le impostazioni di autenticazione e le policy di accesso ai dati vivono dentro il progetto Supabase collegato, non dentro Lovable stesso, e vanno configurate, non arrivano già pronte per la produzione. Lo stesso vale, con logiche diverse, per pagamenti, dominio e monitoraggio.

In pratica, quando passi dal prototipo al prodotto, ti stai spostando da "l'AI ha generato qualcosa che funziona" a "io ho verificato che regga l'uso reale". Sono due traguardi diversi, e il secondo richiede scelte esplicite che il primo non richiedeva.

## Perché conta

Perché la differenza, quando viene ignorata, non produce solo bug fastidiosi: può esporre dati reali di persone reali. Nel 2025 un ricercatore di sicurezza ha analizzato 1.645 applicazioni pubblicate con Lovable e ne ha trovate 170, circa il 10%, con database privi di regole di accesso corrette (Row Level Security disabilitata o mal configurata su Supabase), rese pubblicamente interrogabili senza autenticazione. Il problema, tracciato come CVE-2025-48757, ha permesso in alcuni casi di leggere email, numeri di telefono e dati di pagamento direttamente dagli endpoint esposti (approfondimento su Superblocks). Non è un caso isolato del vibe coding: uno studio di Veracode del 2025 ha rilevato che il codice generato da AI introduce vulnerabilità di sicurezza in circa il 45% dei casi analizzati, un dato rimasto sostanzialmente stabile anche nelle versioni più recenti dei modelli.

Questo non significa che Lovable sia pericoloso di per sé, né che il vibe coding vada evitato: significa che la fase "dal prototipo al prodotto" è esattamente il momento in cui questi rischi vanno affrontati di proposito, prima che qualcun altro li scopra al posto tuo.

## Esempio lampante

### Caso ipotetico

Un personal trainer freelance costruisce su Lovable, in un weekend, un'app per gestire le prenotazioni delle sue sessioni. Funziona benissimo: lui la usa per bloccare i propri orari, il calendario si aggiorna, tutto sembra a posto.

### INPUT

Il prototipo ha un solo account (il suo, usato come amministratore), un database di prenotazioni creato automaticamente da Lovable tramite Supabase, nessun sistema perché i clienti si registrino da soli, nessun pagamento collegato, e gira ancora sull'URL di anteprima fornito da Lovable.

### ANALISI

Vuole aprire l'app ai clienti veri, che dovranno registrarsi, vedere solo le proprie prenotazioni (non quelle degli altri), pagare un acconto per bloccare il posto, e trovare l'app su un indirizzo con il suo nome, non su un URL generico. Rilegge la documentazione di Supabase e scopre che, di default, senza configurare esplicitamente le regole di accesso (Row Level Security), chiunque conosca l'indirizzo tecnico del database potrebbe leggere le prenotazioni di tutti.

### DECISIONE

Prima di invitare un solo cliente reale, decide di occuparsi in ordine di: autenticazione vera per ogni cliente, regole di accesso che permettano a ciascuno di vedere solo le proprie prenotazioni, un test esplicito di cosa succede se un pagamento viene rifiutato, e solo dopo l'acquisto di un dominio personalizzato, perché un dominio sbagliato è un fastidio estetico, un database aperto è un rischio per le persone.

### OUTPUT

Un'app che dall'esterno sembra identica al prototipo del weekend, ma che internamente protegge i dati dei clienti, gestisce un pagamento fallito senza bloccarsi, e vive su un indirizzo che può davvero condividere sui social.

Come farlo: la checklist minima prima di andare online

Rivedi il modello dei dati pensando a "chi può vedere/modificare cosa". Non basta che i dati esistano: ogni tabella deve avere regole esplicite su chi può leggerla e scriverla. Su Supabase questo significa configurare correttamente la Row Level Security, non lasciarla ai valori di default.
Sostituisci l'account "admin di prova" con un'autenticazione vera. Lovable può generare flussi di login completi (email/password, magic link, accesso con Google o GitHub) appoggiandosi a Supabase Auth, lo spiega passo passo la documentazione ufficiale.
Testa esplicitamente cosa succede quando qualcosa va storto, non solo il percorso perfetto: un campo lasciato vuoto, una connessione che cade a metà, un doppio clic sullo stesso pulsante.
Aggiungi i pagamenti solo con un provider verificato, se il progetto ne ha bisogno. Stripe è l'integrazione nativa di Lovable per i pagamenti, pensata proprio per evitare di gestire a mano le parti più delicate (chiavi, webhook, dati sensibili).
Passa da un URL di anteprima a un dominio tuo, seguendo la guida ufficiale alla pubblicazione: un dominio personalizzato richiede un piano a pagamento su Lovable, ma è anche l'ultimo passo, non il primo.
Decidi chi si occupa della manutenzione dopo il lancio: chi controlla che l'app continui a funzionare quando Lovable, Supabase o le API collegate cambiano qualcosa. Anche se sei da solo, questo significa almeno: sapere dove guardare quando qualcosa smette di funzionare.

## Errori comuni

Pensare che un URL "difficile da indovinare" sia una protezione. Non lo è: un endpoint pubblico resta pubblico, indipendentemente da quanto sia scomodo da trovare.
Rimandare la sicurezza a "quando avrò più utenti". I dati dei primi dieci utenti valgono quanto quelli del millesimo, e sono spesso i più esposti, perché è nella fase iniziale che i controlli mancano ancora.
Collegare i pagamenti senza aver mai testato un pagamento che fallisce. È il caso che, puntualmente, capita nel mondo reale.
Confondere "funziona in anteprima" con "è pronto per sempre". Le dipendenze esterne (API, integrazioni, lo stesso Supabase) cambiano nel tempo: un progetto in produzione va controllato, non solo lanciato.

Quando questo conta meno

Se il tuo progetto resta davvero un prototipo, una demo per un colloquio, un esperimento personale mai condiviso con dati reali, un test interno che nessun estraneo userà mai, gran parte di questi accorgimenti può aspettare. La differenza è tutta nella parola "reale": dati reali di persone reali, oppure no. Ma anche in quel caso, vale la pena sapere che questi passaggi esistono, per non trovarsi a doverli scoprire troppo tardi il giorno in cui decidi di aprire davvero il progetto al pubblico.

## In sintesi

Un prototipo che funziona è un ottimo punto di partenza, non un punto di arrivo. Il passaggio a un prodotto reale richiede scelte esplicite su modello dei dati, autenticazione, gestione degli errori, pagamenti, dominio e manutenzione, nessuna delle quali arriva automaticamente solo perché "l'app sembra andare". Non è un lavoro impossibile da soli, ma è un lavoro che va riconosciuto come tale, invece di darlo per scontato.

## Cosa imparare dopo

Nella prossima lezione, errori comuni vibe coding, vedrai in dettaglio dove cadono più spesso le persone che arrivano fin qui, incluso l'errore che ha reso possibile l'incidente citato in questa lezione. È l'ultima tappa prima della chiusura del corso.

Una nota onesta: un percorso pratico più approfondito, pensato apposta per costruire un'applicazione reale dall'inizio alla fine, database, autenticazione, pagamenti, dominio, messa online, è in fase di progettazione. Non esiste ancora: nessun video registrato, nessuna data, nessun prezzo definito. Quando sarà pronto, ne troverai traccia qui sull'Academy.

---

Vuoi provarlo?

Prova Lovable →

Link di affiliazione: se ti iscrivi da qui, ricevo una piccola commissione, a te non cambia nulla.