Costi e scelte · 6 min di lettura ·
Il codice di Lovable è tuo? Proprietà dell'app e rischio lock-in
Il codice della tua app fatta con Lovable, Bolt o altri tool AI è tuo? Cosa dicono in genere i termini, cos'è il lock-in e come ridurre la dipendenza.
«Il codice di Lovable è mio?» In generale sì: le principali piattaforme per creare app con l'AI dichiarano nei loro termini che il codice e i contenuti che crei sono tuoi. Ma possedere il codice non significa poterlo portare via facilmente. Il vero rischio, anche economico, si chiama lock-in: la dipendenza da una piattaforma da cui diventa costoso uscire. Qui sotto vediamo cosa dicono in genere i termini, dove si nasconde la dipendenza e come ridurla. Non è consulenza legale.
Di chi è il codice, secondo le piattaforme
Abbiamo controllato cosa dichiarano due degli strumenti più usati. I termini però cambiano, quindi verifica sempre la versione in vigore sul sito del fornitore.
- Lovable afferma, nei termini e nella documentazione, che app, codice e contenuti creati con lo strumento sono tuoi, fatti salvi i diritti di terzi come le licenze open source. Dichiara anche che puoi modificarli, usarli commercialmente e ospitarli dove preferisci.
- Bolt (di StackBlitz) dichiara di non rivendicare la proprietà di ciò che crei e di trasferirti i propri eventuali diritti sul risultato generato dall'AI, sempre fatti salvi i diritti di terzi.
Per gli altri strumenti (Replit, v0, Base44 e simili) cerca nei termini la sezione dedicata ai contenuti dell'utente o all'output dell'AI. Le parole chiave da cercare sono ownership, your content, output.
Cosa vuol dire «fatti salvi i diritti di terzi»
La tua app non è fatta solo di codice scritto per te. Usa librerie open source, cioè pezzi di codice scritti da altri e condivisi con licenze precise. Usa font, icone, a volte immagini. Ognuno di questi elementi ha le sue regole. Di solito le licenze più comuni permettono l'uso commerciale, ma è bene saperlo se l'app diventa un prodotto importante.
Proprietà del codice e diritto d'autore
Che la piattaforma non rivendichi nulla è una cosa. Che il codice sia tutelato dal diritto d'autore è un'altra, e dipende dalle leggi del Paese e dal contributo creativo umano. È un tema ancora in evoluzione: se è rilevante per il tuo progetto, per esempio perché stai cercando investitori o vendendo l'app, chiedi un parere a un avvocato.
Cos'è il lock-in e perché costa
Il lock-in è la situazione in cui lasciare un fornitore costa così tanto, in tempo, soldi o rischi, che di fatto non puoi farlo. Non è una clausola scritta: è una conseguenza pratica di come è costruita l'app.
Pensa a una casa costruita su un terreno in affitto. La casa è tua, ma le fondamenta poggiano sul terreno di qualcun altro. Se le condizioni dell'affitto cambiano, spostarla è un lavoro enorme.
Per questo il lock-in è soprattutto un tema di costi:
- se i prezzi o i limiti del piano cambiano, hai poco margine di trattativa;
- se l'AI della piattaforma entra in un ciclo di correzioni che consuma crediti, non hai un'alternativa pronta (ne parliamo nella guida su cosa fare quando l'AI continua a rompere il codice);
- se vuoi affidare il progetto a uno sviluppatore, deve prima capire come portarlo fuori;
- se una funzione che ti serve non è supportata, sei bloccato.
Le voci di spesa di un'app online, con o senza piattaforma, le trovi nella guida su quanto costa tenere online un'app creata con l'AI.
Dove si nasconde la dipendenza
Un'app non è un blocco unico. Alcune parti si spostano facilmente, altre molto meno.
| Componente | Di solito è portabile? | Cosa controllare |
|---|---|---|
| Codice dell'interfaccia (frontend) | Sì, se è su un repository tuo | Che la sincronizzazione con GitHub sia attiva |
| Database | Sì, con un po' di lavoro | Che tu sappia esportare struttura e dati |
| Utenti e password | Più delicato | Che il servizio permetta di esportare gli utenti |
| File caricati | Sì, ma vanno copiati | Dove sono salvati e come scaricarli |
| Funzioni lato server | Dipende | Se usano servizi specifici della piattaforma |
| Dominio | Sì, se è registrato a tuo nome | Chi ha accesso al pannello del dominio |
| Pagamenti, email, servizi esterni | Sì, se gli account sono tuoi | Che non siano intestati alla piattaforma o a un collaboratore |
Due esempi concreti. Lovable dichiara che database, file e configurazione del suo backend integrato sono esportabili e che il percorso supportato per uscire è verso Supabase, gestito o installato su server propri. Spostarsi su un database diverso significa invece reimplementare da sé autenticazione, archiviazione dei file e funzioni. Il codice dell'interfaccia è normale codice React e si porta via con molto meno sforzo.
Gli utenti meritano un'attenzione particolare. Le password non vengono salvate in chiaro, ma trasformate in un'impronta che non si può decifrare (in gergo hash), e non tutti i servizi di autenticazione permettono di portarle altrove così come sono. Nel caso peggiore, dopo il trasloco gli utenti dovranno reimpostare la password: un fastidio gestibile, se lo sai in anticipo e lo comunichi bene.
L'ultima riga della tabella è spesso la più trascurata. Se il dominio, l'account Stripe o il progetto del database sono intestati a qualcun altro, il problema non è tecnico ma di controllo.
Come capire quanto sei legato alla piattaforma
Rispondi con sincerità a queste domande:
- Il codice è su un repository GitHub (o simile) di cui sei proprietario?
- Sapresti scaricarlo e avviarlo sul tuo computer, o sapresti a chi chiedere di farlo?
- Sai dove si trova il database e hai mai esportato i dati?
- Hai un elenco delle chiavi e dei servizi esterni che l'app usa?
- Dominio, pagamenti, email e database sono intestati a te?
- Uno sviluppatore potrebbe lavorare sul progetto senza usare la piattaforma?
Se hai risposto «no» a più di una o due domande, non è un dramma, ma vale la pena intervenire prima che l'app cresca.
Come ridurre il lock-in senza abbandonare la piattaforma
Non serve lasciare lo strumento che usi. Spesso è la scelta migliore per andare avanti in fretta. L'obiettivo è poterlo lasciare, se un giorno servirà.
- Collega subito un repository tuo. È il passo più importante. Trovi come farlo nella guida per esportare l'app da Lovable o Bolt su GitHub.
- Esporta i dati con regolarità. Un backup del database salvato fuori dalla piattaforma ti protegge sia dal lock-in sia dagli incidenti.
- Intesta tutto a te. Dominio, account di pagamento, servizio email, progetto del database: con la tua email e il tuo metodo di pagamento.
- Documenta la configurazione. Un file con l'elenco delle variabili d'ambiente (senza i valori segreti) e dei servizi collegati vale molto più di quanto sembri.
- Usa le funzioni proprietarie con consapevolezza. Non vanno evitate, ma ogni funzione specifica della piattaforma è un pezzo in più da rifare se un giorno esci.
- Fai una prova di uscita. Una volta, pubblica una copia dell'app su un hosting diverso. Scoprirai subito cosa manca.
Quando conviene farti aiutare
Se il progetto è ancora piccolo, puoi mettere in sicurezza codice e account da solo seguendo i passi sopra. Ha senso chiedere aiuto se l'app sta crescendo e vuoi capire quanto ti costerebbe uscire, se devi spostare database e utenti, oppure se vuoi passare il progetto a uno sviluppatore senza perdere nulla.
Di solito facciamo una mappa di tutte le dipendenze, mettiamo il codice su un repository tuo e verifichiamo che l'app possa girare anche fuori dalla piattaforma. Per capire da dove partire, prenota una call gratuita.
