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.
- La logica può essere esportata?
- Bubble: nessun export del codice sorgente
- Andarsene significa ricostruire tutto da zero
- Influisce sui calcoli d'acquisto
- I record possono essere esportati?
- Anche Bubble esporta le righe di dati
- Di solito la via d'uscita più semplice
- Il valore risiede nei record
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
C’è una seconda risposta al lock-in che non coinvolge affatto l’esportazione del codice: rimuovere il motivo per cui si vorrebbe lasciare. Una piattaforma con una fattura flat e prevedibile e una bassa manutenzione crea poca pressione all’uscita, perché la curva dei costi non ha mai picchi e le modifiche del secondo giorno non richiedono mai uno sviluppatore. Softr non esporta nemmeno il codice, e il suo punteggio lo indica onestamente, ma abbina prezzi flat (da 19 a 329$/mese fatturati annualmente, nessun misuratore di utilizzo) a un punteggio di manutenibilità di 9.0, quindi la conversazione sulla ricostruzione del secondo anno che Bubble impone raramente inizia. L’esportazione dei dati copre i record; la fattura flat copre 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.