La dimostrazione avviene spesso in diretta: un partner apre un assistente di codice, genera in venti minuti un prototipo di cruscotto di monitoraggio, e la sala è conquistata. Il preventivo mentale è chiuso: uno sviluppatore, un LLM, fatto.

La dimostrazione è vera. Il preventivo è falso. Perché ciò che il prototipo dei venti minuti non mostra è tutto ciò che separa un prototipo da un software in produzione in una società di gestione: l'amministrazione dell'applicazione, la gestione dei permessi, la sicurezza, i backup, la conformità, la trasformazione di un bisogno vago in una specifica e poi in uno sviluppo testato, e una roadmap che non si ferma mai perché il business non si ferma mai. La ricerca in ingegneria del software lo dice da quarant'anni: la manutenzione e l'evoluzione rappresentano, secondo gli studi classici, dal 40 all'80% del costo totale di un software lungo il suo ciclo di vita, molto più del suo sviluppo iniziale [1]. Gli LLM hanno diviso il costo della prima versione. Non hanno diviso il costo dei cinque anni successivi.

Questa scheda si gioca in due tempi: prima i conti, oggi, cifre alla mano. Poi la proiezione a due anni, dove la risposta si complica, e dove la vera domanda non è più quella che si crede.

Prima parte: i conti di oggi

Facciamo i conti

Prendiamo una società di gestione di taglia media, da 15 a 30 persone, che decide di costruire internamente il proprio strumento di gestione (CRM delle partecipate, reporting, monitoraggio). Modellizziamo onestamente quanto costa il "make", in salari lordi aziendali, Francia 2026, con ipotesi volutamente prudenti.

Di fronte, l'abbonamento a una soluzione specializzata di mercato, a perimetro comparabile: non un semplice CRM, ma la piattaforma completa che lo sviluppatore avrebbe dovuto costruire, CRM, reporting, portali, dati:

E fermiamoci sulla simmetria, perché vale tutte le dimostrazioni: la licenza costa il prezzo dello sviluppatore, 80 k€. A parità di budget, il make vi dà una persona; il buy vi dà un prodotto completo, un team intero, una roadmap che avanza senza di voi, una sicurezza collaudata e qualcuno che ne risponde. Il sovraccosto del make si annida in tutto il resto della tabella: lo stagista, l'audit, gli strumenti, il tempo di business, la ripresa del codice. In totale, quasi il doppio su cinque anni, con ipotesi che per giunta favoriscono il "make": un solo sviluppatore (nessun progetto serio regge a lungo con uno solo), nessuno slittamento di planning, nessuna ristrutturazione tecnica in corso d'opera, e una sola partenza in cinque anni. Ogni riga di questa tabella è modificabile, e vi incoraggio a rifare il calcolo con le vostre cifre; l'esperienza mostra che gli aggiustamenti vanno raramente nella direzione del "make".

Le tre righe che il preventivo mentale dimentica sempre

Il tempo di business. È la riga più sottovalutata della tabella, e spesso la più grossa nella realtà. Uno strumento interno avanza solo se il business spiega, arbitra, testa e ritesta. Ogni ora che un partner o una CFO dedica a precisare una regola di calcolo o a validare una bozza è un'ora tolta ai deal, agli LP, alle partecipate. È il rischio di perdita di focus: il vero costo del make non si legge nel budget, si legge nell'agenda delle persone meglio pagate della società.

Il fattore autobus, versione private equity. Il vostro sviluppatore, diventato col passare dei mesi l'unico essere umano a capire il codice, riceve un giorno un'offerta dal GP di fronte. Se ne va con l'unico cervello che sa perché la riga 4.218 non va assolutamente mai modificata. La ripresa di un codice da parte di un nuovo arrivato costa cara, quando è possibile; a volte finisce in riscrittura. Lo stagista, dal canto suo, era brillante, ma è tornato in aula a settembre.

L'esperienza di progettazione. Un editore specializzato non porta solo codice: porta un prodotto plasmato da decine di clienti dello stesso mestiere, che hanno incontrato i vostri problemi prima di voi, i casi limite regolamentari, gli aggiornamenti di versione, la sicurezza collaudata, il GDPR attrezzato. In interno, ogni lezione si paga una volta di più, in diretta, sui vostri dati. E ricordiamo la cifra del MIT sui progetti interni di IA generativa: il 95% dei pilota non produce alcun impatto misurabile sul conto economico [2]. Costruire il proprio strumento con un LLM significa cumulare le due scommesse.

Quando il make si giustifica comunque

Siamo onesti, perché i casi legittimi esistono: quando lo strumento È il vostro vantaggio competitivo centrale (un modello proprietario di analisi che fonda la vostra tesi di investimento), quando nessun prodotto di mercato copre un bisogno davvero singolare, o quando la vostra dimensione giustifica un vero team di ingegneria, con più sviluppatori, un product manager e un budget assunto, non uno sviluppatore solitario e uno stagista. Il make è un mestiere; il problema non è sceglierlo, è sceglierlo senza sapere che lo è.

Il momento in cui si vedono i fili

A questo punto avrete notato che l'autore di queste righe vende, precisamente, licenze software alle società di gestione. È esatto, ed è proprio per questo che conosce così bene ogni riga della tabella: quei costi, l'amministrazione, la sicurezza, gli audit, la roadmap, gli aggiornamenti di versione, li paghiamo noi, mutualizzati sull'insieme dei nostri clienti invece di gravare su uno solo. È tutta la tesi economica del software specializzato, e non è stata abrogata dagli LLM; ne esce anzi rafforzata, perché anche noi sviluppiamo più velocemente di prima, a beneficio della stessa licenza.

Allora, la prossima volta che il prototipo dei venti minuti incanta il comitato, ponete una sola domanda: chi lo mantiene tra cinque anni, e che cosa avrete fatto in meno nel frattempo? La tabella qui sopra aspetta le vostre cifre.

Seconda parte: e tra due anni, vincerà il make?

Proiettiamoci, perché l'obiezione merita di essere presa sul serio. Da qui a due anni, tutta la catena del valore della gestione si sarà digitalizzata: più flussi trattati, più informazioni assorbite, più precisione nella selezione come nell'accompagnamento. Tutti i GP saranno "aumentati" da dati e IA, e questa augmentation diventerà una commodity, necessaria ma non più sufficiente. In quel mondo, un GP non ha forse interesse, al contrario di tutto quanto precede, a investire massicciamente nella propria infrastruttura e nel proprio sistema informativo? Il make non finirà per vincere?

La frontiera non è fissa, sale

Prima chiave di lettura: la frontiera make/buy non è mai stata un dogma, è una linea che sale con il livello di astrazione. Nessuno "fa" più il proprio server di posta; tutti "facevano" i propri modelli Excel. La domanda giusta non è quindi mai make o buy in assoluto, ma: dove passa la frontiera per il mio fondo, oggi? E il paradosso della proiezione a due anni è che rafforza la prima parte sul suo stesso terreno: se la strumentazione dati e IA diventa una commodity, allora ricostruire una commodity è il peggior investimento possibile. Non si crea vantaggio competitivo rifabbricando ciò che tutti possiedono. La vecchia massima delle direzioni dei sistemi informativi non è mai stata così vera: make what makes you different, buy what makes you the same.

L'argomento che può rompersi, e quello che lo sostituisce

Siamo onesti sul punto debole: tutta la tabella della prima parte poggia sul costo della manutenzione. Se, tra tre o cinque anni, agenti autonomi manterranno, correggeranno e faranno evolvere il codice senza intervento umano, quell'argomento si erode, e il make ridiventa pensabile. Due riserve, tuttavia. La prima è aritmetica: gli editori beneficiano esattamente della stessa rivoluzione, e il divario relativo, un costo mutualizzato su decine di clienti contro un costo sostenuto da soli, persiste finché sussiste il minimo costo fisso. La seconda è più profonda e propria del nostro settore: un mestiere regolamentato non farà girare il proprio middle office su codice autogenerato e in perenne mutamento. Servirà sempre qualcuno che risponda del sistema: versioni certificate, verificabilità, catena di responsabilità. Nell'era degli agenti, la "responsabilità del software" diventa il prodotto, esattamente come la responsabilità editoriale è diventata, con l'articolo 50 dell'AI Act, la linea di demarcazione dei contenuti. Ciò che comprerete domani da un editore non è più codice: è qualcuno che ne risponde.

Buy the platform, make the last mile

Quindi sì, il GP deve investire massicciamente nel proprio sistema informativo, ma non nel senso inteso dalla musichetta. L'asset da costruire non è il tubo, è ciò che vi scorre dentro e ciò che lo pilota. Tre strati, precisamente. I dati proprietari innanzitutto: i dati operativi delle partecipate sono un giacimento che nessun altro possiede, e la loro golden source vale più di qualsiasi sviluppo. La dottrina poi: il fondo che ha documentato e codificato i propri processi e le proprie regole di investimento potrà farle eseguire da agenti; quello che le tiene nella testa dei partner, no. Le interfacce governate infine, tipo server MCP, che permetteranno a qualsiasi agente di agire su quei dati in modo controllato, registrato, verificabile. Il futuro probabile non è quindi né make né buy: è "buy the platform, make the last mile". La piattaforma specializzata si compra; lo strato proprietario del fondo, i suoi dati, le sue regole, le sue skill di agenti, si costruisce sopra. È un investimento massiccio nel sistema informativo, ma in capitale di dati e processi, non nella rifabbricazione di tubature.

Tokenizzazione: l'era della prova, versione 2

Verrà poi il capitolo blockchain: ancorare i KPI, marcare temporalmente le decisioni e le loro giustificazioni sottostanti su registri distribuiti significa estendere al dato di gestione stesso la logica di provenienza che già si applica ai contenuti. Notiamo di passaggio che la blockchain è l'esempio ultimo del buy: nessuno forgia la propria catena, ci si collega a standard mutualizzati. E anche qui, il vantaggio andrà ai fondi i cui dati sono già certificati e strutturati, pronti per essere timbrati; non si tokenizza un file Excel in quattro versioni.

What's the next big move?

Se tutti sono aumentati, l'alfa dell'augmentation scompare, e la differenziazione rifluisce verso ciò che non si commoditizza. Si delineano tre candidati. Il GP come data company innanzitutto: il suo valore di franchise includerà il suo giacimento di dati privati accumulati e i modelli affinati su di essi, cosa che gli LP finiranno per valorizzare in due diligence. Il passaggio dal supporto alla decisione all'esecuzione delegata poi: agenti che fanno sourcing, sorvegliano i covenant, preparano i comitati, e il cui valore dipenderà interamente dalla qualità della dottrina codificata che si fa loro applicare, un sistema operativo del giudizio proprio di ciascun fondo. La distribuzione infine: la tokenizzazione delle quote aprirà i mercati privati a ticket più piccoli e farà della trasparenza verificabile in tempo reale un argomento di raccolta. In tutti e tre gli scenari, il vincitore non è chi avrà ricodificato il proprio CRM. È chi avrà capitalizzato i propri dati e la propria dottrina.

Verdetto

Make or buy è, in fondo, un falso dibattito, e la proiezione a due anni non lo rovescia: lo sposta. La commodity si compra, oggi come domani, e domani ancora di più. Ciò che si costruisce è ciò che solo voi possedete: i vostri dati, i vostri processi, la vostra dottrina. La vera domanda del vostro prossimo comitato non è dunque "quanto costerebbe il nostro strumento fatto in casa?". È: "che cosa possediamo che nessuno può comprare, e che cosa abbiamo fatto quest'anno perché valga di più?"

Riferimenti

[1] Robert L. Glass, "Facts and Fallacies of Software Engineering", Addison-Wesley, 2002, in particolare il fatto n. 41 sulla quota della manutenzione nel costo di vita di un software (dal 40 all'80% secondo gli studi): https://dl.acm.org/doi/book/10.5555/579853

[2] "The GenAI Divide: State of AI in Business 2025", MIT, progetto NANDA; sintesi di Fortune: https://finance.yahoo.com/news/mit-report-95-generative-ai-105412686.html