Perché ho lasciato Lovable

Cos'è e perché conta

Lovable è comodo. Il motivo per cui l'ho lasciato è un altro: dentro una piattaforma così il codice vive da loro, il deploy passa da loro, i prezzi li decidono loro. Io preferisco un progetto che sta in una cartella mia.

Secondo me un anno fa quella comodità aveva senso, perché gli altri strumenti erano difficili. Oggi con Claude Code chiedo le stesse cose che chiederei a Lovable, scrivendo come in una chat, e alla fine il progetto è mio: lo porto dove voglio.

È una scelta mia, non una regola. Se ti trovi bene dove sei, resta: questa guida ti serve lo stesso, perché avere una copia tua di tutto non fa mai male.

Il punto è che un progetto non è solo il codice: ci sono i dati, gli account degli utenti, i file caricati, le chiavi, il dominio. Ogni pezzo esce da una porta diversa, e se ne dimentichi uno te ne accorgi quando un utente non riesce più a entrare.

Una regola prima di tutto: non cancellare nulla finché il nuovo non funziona.

1. Il codice su un tuo GitHub

Su Lovable: Project settings → Git → GitHub. Colleghi il tuo account e fai creare il repository: Lovable lo crea privato e lo tiene sincronizzato nei due sensi, quello che cambi in Lovable va su GitHub e viceversa.

Su Replit: Tools → Git. Se il progetto non ha ancora un repository, premi «Initialize Git Repository». Poi colleghi GitHub (la prima volta Replit ti chiede di autorizzarlo), fai un commit e il push di tutti i file.

Poi cloni il repository sul tuo computer, dal pulsante «Code» della pagina del repo su GitHub. Da qui è una cartella tua.

2. Il database: struttura e dati

Il codice porta la struttura del database, non i dati. Su Lovable la struttura sta nelle migration, file SQL di solito nella cartella supabase/migrations. I dati, cioè le righe vere, li esporti a parte.

Senza i dati hai un'app vuota.

Su Lovable Cloud l'export del database è nelle impostazioni avanzate del Cloud: More → Cloud → Overview → Advanced settings → Export data. Il link arriva per email: è un archivio di backup di Postgres, con struttura e dati, e si ripristina con pg_restore. File caricati e chiavi restano fuori: li porti a mano, come spiego più sotto.

Su Replit i database sono due. Quello di sviluppo lo usi mentre costruisci. Quello di produzione lo usa l'app pubblicata, ed è lì che stanno i dati dei tuoi utenti: è quello da esportare.

Apri lo strumento Database e scegli quello di produzione. Nella scheda My Data puoi esportare i dati in un file. Nella scheda Settings c'è la stringa di connessione: secondo la documentazione di Replit, al database di produzione si collega qualsiasi client compatibile con PostgreSQL, quindi anche pg_dump. Trattala come una password.

Lo importi in un Postgres o Supabase tuo, nuovo e vuoto.

3. Variabili d'ambiente e chiavi

Le variabili segrete non escono col codice né con l'export del database. E su Lovable i segreti non si possono rileggere, solo sostituire: il valore lo prendi dal servizio che te l'ha dato.

Su Replit le trovi in Tools → Secrets, con i valori visibili. Se l'app è pubblicata, controlla anche i segreti di produzione nelle impostazioni del Publishing: possono essere diversi.

Fai la lista di tutte: database, API, pagamenti, email. Mettile nel .env sul computer e nelle impostazioni del nuovo hosting, mai nel codice.

Quando la nuova app funziona, rigenerale tutte e revoca le vecchie: sono passate da un'altra piattaforma, e non sai più dove sono finite.

4. Utenti, file, dominio

Gli utenti

Gli account di login non viaggiano con le tabelle: se sposti solo i dati, gli utenti restano indietro.

L'export completo di Lovable Cloud invece li include, con le password cifrate. Se lo ripristini in un progetto Supabase, gli utenti tengono la loro password; le sessioni no, quindi tutti rifaranno il login.

Su Replit, in Tools → Users & Auth, scheda Users, vedi chi si è registrato. Con Replit Auth gli utenti entrano con un account Replit. Le loro righe nel database viaggiano con i dati, il modo di entrare no: decidi prima il nuovo login e come far rientrare chi c'è già.

Se arrivi da un'altra strada e le password non si possono portare, prepara un'email di «reimposta la password» da mandare il giorno del cambio.

I file caricati

Foto, documenti, avatar: non sono nel database e non sono nel codice. Su Lovable Cloud li trovi in More → Cloud → Storage. Scaricali e ricaricali sul nuovo storage, in bucket (le «cartelle» dello storage) con gli stessi nomi.

Su Replit stanno in App Storage: Tools → App Storage, scegli il bucket dal menu in alto a sinistra e nella vista Objects scarichi ogni file con l'icona accanto.

Poi conta i file prima e dopo.

Il dominio

Segnati dove è registrato il dominio e copia i suoi record DNS attuali prima di cambiarli. Su Replit il dominio collegato è in Publishing, scheda Domains. Se l'hai comprato dentro la piattaforma, controlla come si trasferisce prima di chiudere qualsiasi cosa.

5. Apri la cartella con Claude Code

Apri il terminale nella cartella del progetto e lancia Claude Code (cd nella cartella, poi claude). Legge i file da solo. Io gli do queste richieste, in quest'ordine.

Leggi tutto il progetto e spiegami come è fatto: framework, database, login, servizi esterni. Fammi la lista delle variabili d'ambiente che servono.

Questa è la mappa. Nei progetti Replit l'app di solito trova il database nella variabile DATABASE_URL: sul nuovo dovrà puntare al tuo.

Crea un file .env.example con tutte le variabili, senza valori veri, e aggiungi .env al .gitignore.

Il .env.example ha solo i nomi. I valori veri stanno nel .env, sul tuo computer, e il .gitignore dice a git di non caricarlo mai.

Fallo partire in locale. Se qualcosa dipende dalla vecchia piattaforma, dimmi cosa e proponimi come sostituirlo.

Qui escono le cose nascoste: un login che passa dalla piattaforma, un indirizzo scritto nel codice. Quanto Claude Code chiede prima di agire dipende dalla modalità di permessi, che cambi con Shift+Tab. Quando chiede, leggi cosa sta per fare prima di dire sì.

Importa il dump del database in un database locale e controlla che le pagine mostrino i dati veri.

Ti serve Postgres sul computer: se manca, chiedi a Claude Code di aiutarti a installarlo. Poi apri l'app: se vedi i tuoi utenti e i tuoi contenuti, i dati ci sono.

6. Pubblica dove controlli tu

Prepara il deploy su [Vercel / il tuo server]: dimmi i passi, le variabili da impostare e cosa cambiare nel DNS. Non toccare niente finché non ti dico ok.

L'ultima frase conta: prima voglio leggere il piano. Puoi anche usare la plan mode (Shift+Tab, o /plan davanti al prompt): Claude scrive un piano e non modifica i file finché non lo approvi.

Prima di spostare il dominio, prova tutto sull'indirizzo che ti dà il nuovo hosting: login con un account vecchio, un file caricato, i pagamenti in modalità test. Poi, solo quando la nuova versione funziona, in quest'ordine:

1. Sposti il dominio, e aggiungi il nuovo indirizzo tra gli URL di redirect autorizzati dal login.
2. Rigeneri le chiavi e revochi le vecchie.
3. Spegni la vecchia versione.

Gli errori più comuni

• Esportare da Replit il database di sviluppo. I dati dell'app pubblicata stanno in quello di produzione: esporta quello.
• Scrivere i valori veri nel .env.example. Lì vanno solo i nomi; i valori stanno nel .env, che git ignora.
• Dimenticare come entrano gli utenti. Decidi prima il nuovo login e come fai rientrare chi è già registrato.
• Copiare le vecchie chiavi sul nuovo e chiuderla lì. Rigenerale e revoca quelle vecchie.

Checklist

• Codice su un GitHub tuo, privato, clonato sul computer
• Struttura e dati esportati dal database di produzione
• Lista delle variabili e .env.example senza valori veri
• Utenti, file e record DNS salvati
• App in locale con i dati veri
• Login, file e pagamenti provati sul nuovo hosting
• Dominio spostato, chiavi rigenerate, vecchia spenta per ultima

Domande frequenti