Ogni presentazione di vibe coding menziona la proprietà del codice da qualche parte nel primo paragrafo. Esporta su GitHub. Nessun formato proprietario. Portalo con te. Sembra l’opposto del lock-in, e per la parte della tua app fatta solo di componenti React, per lo più lo è.
La parte che non compare mai nella presentazione è il database. Ed è lì che vive davvero l’app.
Cosa esporta davvero l‘“esportazione”
Bolt e Base44 offrono entrambi una semplice sincronizzazione con GitHub per il frontend, e Lovable fa lo stesso per il suo output React/TypeScript. Se la tua app è un sito di marketing o un prototipo statico, quell’esportazione rappresenta quasi tutto, e puoi consegnare il repository a uno sviluppatore e uscire pulito.
Le app aziendali non sono così. Nel momento in cui il tuo progetto ha login, ruoli e dati reali, gran parte di ciò che lo fa funzionare non è nell’albero dei componenti, ma nello schema, nelle regole di autenticazione e nella logica dei permessi che ci sono dietro. È esattamente quello il livello che queste piattaforme sono più riluttanti a lasciar andare.
Base44 rende questo esplicito invece che implicito: i recensori notano che il codice frontend viene esportato su GitHub, ma il database e il backend restano interamente ospitati sull’infrastruttura di Base44 e non possono essere modificati o esportati direttamente. Un utente di Base44 che cercava di recuperare i propri file dalla piattaforma lo ha detto senza mezzi termini su Reddit: “Non vedo file src tra quelli accessibili, quindi temo di dover pagare un anno del piano builder solo per ottenere il build fuori da Base44. Sono 480 dollari, il che è un po’ assurdo.” Tecnicamente puoi andartene. Ma prima paghi un abbonamento per scoprire con cosa te ne vai.
Il problema Hotel California
Le lamentele su Lovable vanno un passo oltre, perché il problema non è solo cosa non si esporta, ma cosa cambia senza avvisare. Un thread di Reddit diventato un punto di riferimento nella community descrive l’IA di Lovable che migra autonomamente il database Supabase privato di un utente verso Lovable Cloud, senza consenso esplicito, e definisce la piattaforma “un Hotel California per il tuo database: puoi entrare, ma non puoi mai andartene.”
È una modalità di guasto diversa da “manca il pulsante di esportazione”. È la piattaforma che sposta silenziosamente proprio ciò che avresti dovuto esportare in primo luogo. Se avevi dato per scontato che i tuoi dati vivessero nel tuo progetto Supabase perché è così che lo strumento si presenta, scoprire il contrario dopo il fatto è esattamente il tipo di sorpresa che diventa un thread di avvertimento su Reddit, che altri sviluppatori trovano più tardi, proprio prima di fare la stessa supposizione.
Il lock-in del backend di Base44 arriva alla stessa conclusione da un’angolazione diversa: un recensore su Product Hunt ha notato che anche quando il codice frontend si esporta senza problemi, il database e il backend restano intrappolati nell’infrastruttura chiusa di Base44, impedendo una vera migrazione del database. Due piattaforme, due meccanismi, lo stesso risultato: la parte dell’app che contiene i tuoi dati aziendali reali è proprio quella che non puoi portarti via facilmente.
Perché questo peggiora invece di restare stabile
Niente di tutto questo conta molto il primo giorno, perché il primo giorno è una demo con dati di esempio. Comincia a contare quando l’app ha utenti reali e lo schema è cresciuto oltre quello che un singolo prompt aveva inizialmente impostato.
Il debito di schema è il meccanismo che trasforma “prima o poi migreremo” in “siamo bloccati”. Sviluppatori di lunga data su Lovable riferiscono che lasciare che l’IA progetti lo schema del database funziona bene all’inizio, ma tra il sesto e il nono mese crea un debito di schema così grave che aggiungere un singolo nuovo campo può richiedere di riscrivere decine di flussi di lavoro a valle. A quel punto migrare non significa più copiare una tabella, ma districare un sistema che nessuno ha documentato completamente mentre lo costruiva. La stessa ricerca segnala che sviluppatori esperti ora sconsigliano Lovable per qualsiasi cosa destinata a durare più di 18-24 mesi, raccomandando di passare a uno stack basato sul codice prima che quel debito si aggravi ulteriormente.
Aggiungici una piattaforma che si aggiorna anche sotto i tuoi piedi. Gli sviluppatori su Lovable descrivono come gli aggiornamenti della piattaforma stessa rompano regolarmente le app dei clienti già esistenti, al punto che alcuni ora fanno pagare ai clienti una quota mensile di manutenzione solo per assorbire le regressioni introdotte dalla piattaforma stessa. Non sei bloccato solo nel database. Sei bloccato a riparare i danni causati dal fornitore mentre sei bloccato.
“Ho davvero paura di Base44, perché sto costruendo le fondamenta della mia attività su quella piattaforma… qualcosa funziona oggi e domani te lo tolgono.” - Utente Base44, r/Base44
Cosa riduce davvero il rischio
Non faremo finta che esista una versione di “piattaforma ospitata” che significhi zero lock-in. Anche Softr è ospitata, e se chiudi il tuo account non te ne vai con un’app portabile, proprio come non lo faresti con Lovable o Base44. La domanda onesta non è “posso evitare del tutto il lock-in”, ma “quanti dei miei dati restano raggiungibili mentre uso ancora la piattaforma, e quanto è difficile l’uscita se mai ne avrò bisogno”.
Su questa domanda il meccanismo conta più dello slogan di marketing. Alcune cose che vale la pena controllare prima di costruire qualcosa di strutturale su qualsiasi piattaforma:
- Uno strumento esterno può raggiungere i tuoi dati senza passare dall’interfaccia dell’app? Il database di Softr espone un server MCP (
mcp.softr.io) oltre a un’API REST, così strumenti come Claude, Cursor o uno script possono leggere, scrivere o ristrutturare il tuo schema in linguaggio naturale mentre stai ancora costruendo. Softr presenta questo direttamente come un modo per prevenire il lock-in, mantenendo il database accessibile al di fuori di un’unica interfaccia, il che è una promessa diversa da “potrai esportare il codice prima o poi”. - La piattaforma sposta silenziosamente la tua infrastruttura senza dirtelo? Questa è esattamente la lamentela su Lovable. Se la tua piattaforma può riassegnare dove vivono i tuoi dati come parte di un’azione dell’IA, chiedi cosa lo attiva e se puoi disattivarlo.
- Quanto costa davvero modificare lo schema sei mesi dopo? Non il primo giorno, quando tutto è un’impalcatura fresca generata dall’IA, ma dopo che l’uso reale ha plasmato i dati. Il debito di schema è la versione lenta del lock-in, ed è quella che non compare in una pagina dei prezzi.
Se l’app è davvero un prototipo o un progetto personale, niente di tutto questo dovrebbe impedirti di crearla con il vibe coding questo weekend, codice esportabile incluso. Ma se è un portale clienti, uno strumento interno, o qualsiasi cosa con utenti e dati reali, il problema del giorno due e il problema del lock-in sono lo stesso problema con due nomi diversi: l’impianto a cui non avevi pensato il primo giorno è esattamente ciò che sarà più difficile spostare il duecentesimo giorno. Consulta la nostra classifica dei portali clienti prima di scegliere una base da cui non potrai andartene facilmente.