L’esportazione del codice è la funzionalità che gli acquirenti cercano quando temono il lock-in, e il ragionamento è corretto: se possiedete il codice, nessun fornitore può bloccarvi o imporvi prezzi proibitivi. Ma il termine “esportabile” copre realtà molto diverse: da una codebase pulita che i vostri sviluppatori possono eseguire ovunque a un groviglio di codice che funge da bozza per una ricostruzione. Questa guida distingue la portabilità che vi protegge da quella che sembra solo proteggervi, e spiega come integrarla nella scelta della piattaforma.
I criteri alla base dell’analisi sono definiti in /methodology.
I due significati di lock-in
Il lock-in ha una dimensione legata al codice e una legata ai dati, e i due scenari falliscono in modi diversi.
Lock-in del codice: riguarda la possibilità di spostare la logica dell’applicazione altrove. Bubble è il caso più estremo: non esiste l’esportazione del codice sorgente né dell’architettura del database, quindi andarsene significa ricostruire ogni pagina, workflow e modulo da zero sulla nuova piattaforma. Una curva di costi sgradita al secondo anno non diventa quindi una rinegoziazione, ma una decisione di ricostruzione; ecco perché il lock-in va inserito nei calcoli dell’acquisto iniziale, non in una nota a piè di pagina.
Lock-in dei dati: riguarda la possibilità di esportare i propri record. Questa è solitamente la via d’uscita più semplice; anche su Bubble, le righe di dati possono essere esportate. Per la maggior parte delle app aziendali, l’estrazione dei dati è la parte che conta davvero, poiché il valore dell’app risiede nei suoi record, non nello stile dei pulsanti.
L’export è reale, ma “esportabile” non significa “manutenibile”
Gli strumenti che esportano il codice offrono un valore genuino. Bolt scarica codebase standard React/Vite con sincronizzazione GitHub e senza formati proprietari. Lovable genera React e TypeScript che potete sincronizzare su GitHub e continuare a sviluppare in VS Code o Cursor. Replit rinuncia al prezzo fisso ma restituisce codice reale ed esportabile, che è il lato positivo del suo modello a crediti.
Il problema è il contenuto dell’export. Un utente di Lovable lo spiega chiaramente: “il codice sottostante non è davvero fatto per essere portatissimo pulitamente. La soluzione più semplice è usare la landing page come riferimento visivo e farla ricostruire da uno sviluppatore”. Recensioni su G2 e Product Hunt descrivono lo stesso ostacolo: i builder AI gestiscono il primo 70% della costruzione ma faticano con l’ultimo 30% della logica di business, e molti consigliano di esportare per finire lo sviluppo a mano. L’export può quindi essere una via d’uscita o una bozza a metà; tutto dipende dalla qualità del codice generato e dalle competenze del team che lo riceve.
L’export aiuta solo il team che sa usarlo
Questo è il criterio che quasi tutte le promesse di export ignorano. Un export vi protegge solo se qualcuno è in grado di leggere e mantenere ciò che ne deriva. Per un team di ingegneria, una codebase React/TypeScript su GitHub è una reale via d’uscita e un asset concreto. Per l’operatore non tecnico che costruisce un portale clienti, una codebase esportata non è una fuga; è un peso che non sa come aprire, e la manutenibilità che l’export avrebbe dovuto garantire svanisce nel momento in cui il creatore originale lascia il progetto.
In altre parole, l’esportazione del codice aumenta la manutenibilità per i team con sviluppatori e non fa nulla per i team che ne sono sprovvisti. Valutatelo in base al vostro team reale, non a quello dei casi studio del fornitore.
L’altro modo per neutralizzare il lock-in
Esiste una seconda risposta al lock-in che non prevede l’esportazione del codice: eliminare il motivo di voler andare via. Una piattaforma con un conto fisso, prevedibile e a bassa manutenzione crea pochissima pressione all’uscita, perché la curva dei costi non ha picchi e le modifiche post-lancio non richiedono uno sviluppatore. Softr non esporta il codice e lo dichiara onestamente nel suo scorecard, ma combina un prezzo fisso (da 49$ a 269$/mese fatturati annualmente, senza contatore di utilizzo) con un punteggio di manutenibilità di 9.0; per questo, la conversazione sulla ricostruzione al secondo anno che Bubble impone raramente ha inizio. L’esportazione dei dati copre i record; il prezzo fisso copre tutto il resto.
Questo è il compromesso da valutare: l’export del codice offre una via d’uscita per i team in grado di percorrerla, mentre il prezzo fisso unito a una bassa manutenzione elimina il motivo di cercare la porta. Nessuna delle due opzioni è universalmente migliore; rispondono a paure diverse.
Come integrare la portabilità nella decisione
Ponetevi tre domande prima di pagare un sovrapprezzo per l’export. Il vostro team è effettivamente in grado di leggere e mantenere il codice esportato? Il codice è abbastanza pulito da poter essere eseguito altrove, o è solo una bozza per una ricostruzione? E la fatturazione della piattaforma è così volatile da rendere realisticamente necessaria l’uscita? Se avete ingegneri e una fattura volatile, date molto peso all’export del codice e valutate Replit o Bolt. Se non siete tecnici e il canone è fisso, date invece priorità all’export dei dati e alla manutenibilità; il confronto Bubble vs Softr mostra esattamente questo bilanciamento. Partite dai criteri in /methodology e dalla guida build vs buy per definire onestamente i vostri pesi di valutazione.