Quasi tutti, quando comprano o vendono un'app, guardano solo il prezzo. Poi arriva il bonifico, una stretta di mano, e sembra finita. Non lo è. Il prezzo è la parte facile. La parte che fa fallire un micro-deal — o che genera telefonate furiose tre mesi dopo — è il passaggio di consegne: tutto ciò che deve davvero spostarsi da una persona all'altra perché l'app continui a funzionare e sia legalmente tua. Ecco cosa trasferire, in concreto.
1. Codice e repository
Non un file zip: il repository vero, con tutta la storia — commit, branch, issue. Ti serve per capire com'è fatto e per mantenerlo nel tempo. Insieme al codice viaggiano le pipeline di build, le configurazioni e la documentazione: anche due righe di README valgono oro. Se ti consegnano solo "l'ultima versione" senza storia, chiediti perché.
2. Account e infrastruttura — le chiavi del regno
Qui si gioca la partita vera: cloud e hosting, database (con un dump pulito), dominio e DNS, email, variabili d'ambiente, chiavi API e tutti i servizi di terze parti collegati — pagamenti, analytics, notifiche, monitoraggio errori.
La domanda che conta: questi account sono intestati a un'azienda o al fondatore in persona? Se stanno nel suo account personale, "ti do l'accesso" non basta — vanno trasferiti o migrati sui tuoi. Un accesso condiviso oggi è un accesso revocato domani.
"Ti do le password" non è un passaggio di consegne. È un prestito.
3. Gli store — il punto più sottovalutato
Trasferire un'app su App Store o Google Play non è un copia-incolla. Entrambi hanno una procedura di trasferimento con condizioni: verificale prima di promettere — o di farti promettere — che sia automatico. Se il trasferimento non è possibile, l'alternativa è ereditare l'intero account sviluppatore, con tutto quello che contiene. E ricorda: recensioni, valutazioni e storico della scheda vivono sul listing. Perderli significa ripartire da zero, anche con la stessa identica app.
4. Dati degli utenti — non è un foglio Excel
Passare un database di utenti è un evento di protezione dati, non un copia-incolla. Base giuridica, informativa privacy, comunicazione agli utenti: ci sono regole, e nel dubbio si verificano prima, non dopo. "Ti do anche il database utenti come bonus" è esattamente il tipo di frase che crea problemi seri a entrambe le parti.
5. IP e contratti — la parte che protegge tutto il resto
Il passaggio di consegne tecnico non vale niente senza quello legale. Serve una cessione scritta di codice, marchio e asset. E un controllo che spesso salta: chi ha scritto i vari pezzi di codice? Se un freelance ha contribuito e non ha mai ceduto i diritti, quel codice non è del tutto vendibile. Stessa cosa per le licenze open source usate, i domini e gli handle social. Chi possiede cosa è metà della due diligence.
La checklist, prima di firmare
Non chiudere finché non hai ricevuto (o consegnato):
- repository trasferito, con la storia
- cloud, database e dominio trasferiti o migrati — non solo "condivisi"
- store: trasferimento avviato, o account sviluppatore ceduto
- chiavi API e secret ruotati e nelle tue mani
- cessione di IP, marchio e asset messa per iscritto e firmata
- contributor esterni: diritti ceduti, nero su bianco
- dati utenti: base giuridica e privacy a posto
Un acquisto fatto bene è la differenza tra rilevare un prodotto che funziona e ritrovarsi con una cartella di file. E, come sempre nei micro-deal, è fondatore contro fondatore: un passaggio di consegne ordinato è il modo più concreto di dimostrare — da entrambe le parti — che ci si può fidare.
Prima ancora di arrivare qui servono un prezzo che regga e un processo chiaro: il primo lo trovi in Valuta & Vendi, il secondo nelle fasi di un micro-deal. E se parti da zero, la Guida M&A mette in fila i termini.