App creata con l'AI: funziona in anteprima ma non online?

Se la tua app creata con l'AI funziona in anteprima ma non online, sei nel posto giusto: è uno dei problemi più frequenti per chi costruisce con Lovable, Bolt, Replit o v0. Quasi sempre la causa non è un difetto misterioso, ma una differenza tra l'ambiente di prova e quello pubblico: una variabile mancante, un indirizzo configurato solo per l'anteprima, un permesso del database. Qui vediamo perché succede, come capire qual è il tuo caso e cosa puoi sistemare da solo.

Perché anteprima e versione online non sono la stessa cosa

L'anteprima è la finestra in cui vedi l'app mentre la costruisci. Gira in un ambiente di sviluppo preparato dalla piattaforma, dove molte cose sono già collegate e configurate per te. È come provare una ricetta nella cucina di casa: hai tutti gli ingredienti a portata di mano.

La versione online, invece, passa da due fasi. La prima è la build: un processo automatico che prende il codice e lo trasforma in file ottimizzati che il browser può leggere velocemente. La seconda è il deploy, cioè la pubblicazione di quei file su un server raggiungibile da chiunque. Per restare nella metafora, è come cucinare la stessa ricetta in un ristorante: la ricetta è uguale, ma la cucina è un'altra, e se manca un ingrediente te ne accorgi solo al momento del servizio.

Quando un'app funziona in anteprima ma si rompe dopo la pubblicazione, quasi sempre qualcosa che nell'anteprima c'era (un'impostazione, una chiave, un indirizzo) nell'ambiente online manca o è diverso.

Le cause più comuni quando l'app non funziona online

1. Variabili d'ambiente mancanti

Le variabili d'ambiente sono impostazioni che vivono fuori dal codice: l'indirizzo del database, la chiave di un servizio esterno, l'URL del sito. Pensale come i post-it attaccati al frigo con i numeri utili: il codice li legge quando gli servono. Nell'anteprima spesso sono già impostate; online vanno inserite nel pannello dell'hosting, cioè il servizio che tiene in piedi il sito.

Se mancano, l'app si apre ma non carica i dati, oppure resta bianca. Un segnale tipico è un errore come supabaseUrl is required. nella console del browser. Ne parliamo in dettaglio nella guida sulle variabili d'ambiente e le chiavi API che mancano online.

2. Indirizzi di login e redirect pensati per l'anteprima

Se l'app ha un login, il servizio di autenticazione (per esempio Supabase) conserva un elenco di indirizzi autorizzati: dopo l'accesso o la conferma dell'email, l'utente viene rimandato solo lì. Se quell'elenco contiene solo l'indirizzo dell'anteprima o localhost (il «computer locale» usato durante lo sviluppo), online il login fallisce o ti riporta alla pagina sbagliata. Lo approfondiamo nell'articolo sugli errori di login e autenticazione.

3. Le pagine interne danno 404 o restano bianche

Molte app create con l'AI sono SPA (single page application): in realtà esiste un'unica pagina, e il passaggio da una schermata all'altra lo gestisce il codice nel browser. Nell'anteprima funziona tutto. Online, invece, se ricarichi una pagina interna come /dashboard, il server cerca un file che non esiste e risponde 404 Not Found. Serve una regola che dica all'hosting di servire sempre la pagina principale. Trovi i dettagli nella guida sulla pagina bianca dopo il deploy.

4. Il database o un servizio esterno rifiuta le richieste

Online le richieste partono da un indirizzo diverso da quello dell'anteprima. Alcuni servizi accettano richieste solo da domini autorizzati e bloccano gli altri: è il classico errore CORS, che in console compare come Access to fetch at ... has been blocked by CORS policy. In altri casi è il database a rifiutare l'accesso, con messaggi come permission denied for table o 401 Unauthorized, perché le regole di sicurezza non sono state pensate per gli utenti reali.

5. Online c'è una versione vecchia

Su diverse piattaforme le modifiche fatte in chat non finiscono online da sole: bisogna ripubblicare. Capita anche che il browser mostri una copia salvata (la cache) della versione precedente. Risultato: tu vedi l'app aggiornata in anteprima, i tuoi utenti no.

Come capire qual è il tuo caso

Il modo più rapido è guardare cosa dice il browser. Apri l'app online con Chrome, Edge o Firefox, premi F12 (oppure clic destro e «Ispeziona») e scegli la scheda Console: i messaggi in rosso sono gli errori. La scheda Rete (Network) mostra invece ogni richiesta che l'app fa al database o ad altri servizi, con il relativo esito.

Due verifiche semplici aiutano a restringere il campo. Prima: apri l'app in una finestra in incognito, così escludi la cache e le sessioni salvate. Seconda: prova da un altro dispositivo o da un'altra rete. Se il problema c'è ovunque, è nella configurazione; se c'è solo sul tuo computer, è probabilmente qualcosa di locale.

Quando leggi la console, concentrati sul primo errore della lista. Spesso gli altri sono solo conseguenze a catena del primo.

Cosa puoi fare tu, passo per passo

1. Ripubblica l'ultima versione. Assicurati di aver premuto il pulsante di pubblicazione o aggiornamento dopo le ultime modifiche, poi ricarica la pagina online con Ctrl+Maiusc+R (Cmd+Maiusc+R su Mac).
2. Annota l'errore esatto. Copia il primo messaggio rosso della console, parola per parola. «Non funziona» non aiuta nessuno; 401 Unauthorized su una richiesta al database dice già molto.
3. Confronta le variabili. Fai l'elenco delle variabili che usa l'app e controlla che esistano anche nel pannello dell'hosting, con lo stesso identico nome. Dopo averle aggiunte serve un nuovo deploy.
4. Aggiorna gli indirizzi autorizzati. Nel servizio di login aggiungi l'indirizzo pubblico dell'app (e il dominio personalizzato, se ne hai uno) tra gli URL consentiti.
5. Prova una pagina interna. Aprila digitando direttamente l'indirizzo e poi ricaricala. Se risponde 404, il problema è il routing.
6. Chiedi all'AI in modo mirato. Incolla l'errore esatto e descrivi dove compare («solo online, non in anteprima»). Chiedi prima una spiegazione della causa, poi la correzione di quel punto soltanto.

L'ultimo passaggio è importante. Se chiedi genericamente «sistema l'app», l'AI tende a modificare molti file insieme e rischi di peggiorare la situazione: è il meccanismo che descriviamo nell'articolo su cosa fare quando l'AI continua a rompere il codice.

Cosa è meglio non fare

• Non incollare chiavi segrete direttamente nel codice per «far funzionare» l'app online. Risolvi un problema e ne crei uno di sicurezza, perché quel codice finisce nel browser di chiunque visiti il sito.
• Non disattivare le regole di sicurezza del database per far sparire un permission denied. L'errore scompare, ma i dati diventano accessibili a tutti.
• Non fare dieci modifiche insieme. Cambia una cosa, ripubblica, verifica. Se qualcosa migliora o peggiora, saprai esattamente perché.

Quando conviene farti aiutare

Se dopo questi controlli l'errore resta, o se la console mostra messaggi che non sai interpretare, vale la pena farsi dare un'occhiata da qualcuno che questi problemi li vede spesso. Lo stesso vale se l'app gestisce già dati di utenti reali o pagamenti: lì un intervento fatto a tentativi costa più di una verifica fatta con metodo.

Di solito, in una prima chiamata, guardiamo insieme la console, la configurazione dell'hosting e quella del database, e ti diciamo con chiarezza qual è la causa e cosa serve per risolverla. Se vuoi, prenota una call gratuita di 20 minuti: alla fine saprai dove mettere le mani, che tu decida di farlo da solo o con noi.