Hay una musiquilla que suena cada vez más en los comités de dirección: "Con los LLM, desarrollar cuesta diez veces menos. ¿Por qué seguir pagando SaaS? Podemos rehacer la herramienta nosotros mismos." La demostración suele hacerse en directo: un socio abre un asistente de código, genera en veinte minutos un prototipo de cuadro de seguimiento, y la sala queda conquistada. El presupuesto mental está cerrado: un desarrollador, un LLM, y listo.

La demostración es cierta. El presupuesto es falso. Porque lo que el prototipo de veinte minutos no muestra es todo lo que separa un prototipo de un software en producción en una gestora: la administración de la aplicación, la gestión de permisos, la seguridad, las copias de respaldo, el cumplimiento normativo, la transformación de una necesidad difusa en una especificación y luego en un desarrollo probado, y una hoja de ruta que nunca se detiene porque el negocio nunca se detiene. La investigación en ingeniería de software lo dice desde hace cuarenta años: el mantenimiento y la evolución representan, según los estudios clásicos, entre el 40 y el 80% del coste total de un software a lo largo de su ciclo de vida, mucho más que su desarrollo inicial [1]. Los LLM han dividido el coste de la primera versión. No han dividido el coste de los cinco años siguientes.

Esta ficha se juega en dos tiempos: primero las cuentas, hoy, con cifras sobre la mesa. Después la proyección a dos años, donde la respuesta se complica, y donde la verdadera pregunta ya no es la que uno cree.

Primera parte: las cuentas de hoy

Hagamos números

Tomemos una gestora de tamaño medio, de 15 a 30 personas, que decide construir internamente su herramienta de gestión (CRM de participadas, reporting, seguimiento). Modelicemos honestamente lo que cuesta el "make", en salarios con cargas sociales, Francia 2026, con hipótesis deliberadamente prudentes.

Enfrente, la suscripción a una solución especializada del mercado, con un alcance comparable: no un simple CRM, sino la plataforma completa que el desarrollador debía construir, CRM, reporting, portales, datos:

Y detengámonos en la simetría, porque vale por todas las demostraciones: la licencia cuesta el precio del desarrollador, 80 k€. A igual presupuesto, el make le da una persona; el buy le da un producto completo, un equipo entero, una hoja de ruta que avanza sin usted, una seguridad probada y alguien que responde por ello. El sobrecoste del make se aloja en todo el resto de la tabla: el becario, la auditoría, las herramientas, el tiempo de negocio, la retoma del código. En total, casi el doble a cinco años, con hipótesis que además favorecen al "make": un solo desarrollador (ningún proyecto serio se sostiene mucho tiempo con uno), sin retrasos de planificación, sin refactorización técnica a mitad de camino, y una única marcha en cinco años. Cada línea de esta tabla es ajustable, y le animo a rehacer el cálculo con sus cifras; la experiencia muestra que los ajustes rara vez van en el sentido del "make".

Las tres líneas que el presupuesto mental siempre olvida

El tiempo de negocio. Es la línea más subestimada de la tabla, y a menudo la mayor en la realidad. Una herramienta interna solo avanza si el negocio explica, arbitra, prueba y vuelve a probar. Cada hora que un socio o una CFO dedica a precisar una regla de cálculo o a validar una maqueta es una hora restada a los deals, a los LPs, a las participadas. Es el riesgo de desenfoque: el verdadero coste del make no se lee en el presupuesto, se lee en la agenda de las personas mejor pagadas de la firma.

El factor autobús, versión private equity. Su desarrollador, convertido con los meses en el único humano que entiende el código, recibe un día una oferta del GP de enfrente. Se marcha con el único cerebro que sabe por qué la línea 4.218 no debe modificarse jamás. La retoma de un código por un recién llegado cuesta caro, cuando es posible; a veces termina en reescritura. El becario, por su parte, era brillante, pero volvió a clase en septiembre.

La experiencia de diseño. Un editor especializado no aporta solo código: aporta un producto moldeado por decenas de clientes del mismo sector, que ya se toparon con sus problemas antes que usted, los casos límite regulatorios, las subidas de versión, la seguridad probada, el RGPD instrumentado. En interno, cada lección se paga una vez más, en directo, sobre sus propios datos. Y recordemos la cifra del MIT sobre los proyectos internos de IA generativa: el 95% de los pilotos no produce ningún impacto medible en la cuenta de resultados [2]. Construir su herramienta con un LLM es acumular las dos apuestas.

Cuándo se justifica el make, a pesar de todo

Seamos honestos, porque hay casos legítimos: cuando la herramienta ES su ventaja competitiva central (un modelo propietario de análisis que fundamenta su tesis de inversión), cuando ningún producto del mercado cubre una necesidad realmente singular, o cuando su tamaño justifica un verdadero equipo de ingeniería, con varios desarrolladores, un product manager y un presupuesto asumido, no un desarrollador solitario y un becario. El make es un oficio; el problema no es elegirlo, es elegirlo sin saber que lo es.

El momento en que se ven los hilos

A estas alturas habrá notado que el autor de estas líneas vende, precisamente, licencias de software a gestoras. Es exacto, y es justamente por eso que conoce tan bien cada línea de la tabla: esos costes, la administración, la seguridad, las auditorías, la hoja de ruta, las subidas de versión, los pagamos nosotros, mutualizados entre el conjunto de nuestros clientes en lugar de recaer sobre uno solo. Esa es toda la tesis económica del software especializado, y no ha sido derogada por los LLM; sale incluso reforzada, porque nosotros también desarrollamos más rápido que antes, en beneficio de la misma licencia.

Así que la próxima vez que el prototipo de veinte minutos maraville al comité, haga una sola pregunta: ¿quién lo mantiene dentro de cinco años, y qué habrán dejado de hacer mientras tanto? La tabla de arriba espera sus cifras.

Segunda parte: ¿ganará el make dentro de dos años?

Proyectémonos, porque la objeción merece tomarse en serio. De aquí a dos años, toda la cadena de valor de la gestión se habrá digitalizado: más flujos tratados, más información absorbida, más precisión en la selección y en el acompañamiento. Todos los GPs estarán "aumentados" por los datos y la IA, y esa augmentación se convertirá en una commodity, necesaria pero ya no suficiente. En ese mundo, ¿no le conviene a un GP, al contrario de todo lo anterior, invertir masivamente en su infraestructura y su sistema de información? ¿No acabará ganando el make?

La frontera no es fija, sube

Primera clave de lectura: la frontera make/buy nunca ha sido un dogma, es una línea que sube con el nivel de abstracción. Ya nadie "hace" su servidor de correo; todo el mundo "hacía" sus modelos de Excel. La buena pregunta nunca es make o buy en absoluto, sino: ¿por dónde pasa la frontera para mi fondo, hoy? Y la paradoja de la proyección a dos años es que refuerza la primera parte en su propio terreno: si el utillaje de datos e IA se convierte en commodity, entonces reconstruir una commodity es la peor inversión posible. No se crea ventaja competitiva refabricando lo que todo el mundo posee. La vieja máxima de las direcciones de sistemas nunca fue tan cierta: make what makes you different, buy what makes you the same.

El argumento que puede romperse, y el que lo sustituye

Seamos honestos sobre el punto débil: toda la tabla de la primera parte descansa sobre el coste del mantenimiento. Si, dentro de tres o cinco años, agentes autónomos mantienen, corrigen y hacen evolucionar el código sin intervención humana, ese argumento se erosiona, y el make vuelve a ser pensable. Dos reservas, sin embargo. La primera es aritmética: los editores se benefician exactamente de la misma revolución, y la brecha relativa, un coste mutualizado entre decenas de clientes frente a un coste soportado en solitario, persiste mientras subsista el menor coste fijo. La segunda es más profunda y propia de nuestro sector: un negocio regulado no hará funcionar su middle office sobre código autogenerado y cambiante. Siempre hará falta alguien que responda del sistema: versiones certificadas, auditabilidad, cadena de responsabilidad. En la era de los agentes, la "responsabilidad del software" se convierte en el producto, exactamente como la responsabilidad editorial se convirtió, con el artículo 50 del AI Act, en la línea divisoria de los contenidos. Lo que usted comprará mañana a un editor ya no es código: es alguien que responde por él.

Buy the platform, make the last mile

Así que sí, el GP debe invertir masivamente en su sistema de información, pero no en el sentido que pretende la musiquilla. El activo a construir no es la tubería, es lo que fluye por dentro y lo que la pilota. Tres capas, precisamente. Los datos propietarios primero: los datos operativos de las participadas son un yacimiento que nadie más posee, y su golden source vale más que cualquier desarrollo. La doctrina después: el fondo que ha documentado y codificado sus procesos y sus reglas de inversión podrá hacerlas ejecutar por agentes; el que las guarda en la cabeza de los socios, no. Las interfaces gobernadas por último, tipo servidores MCP, que permitirán a cualquier agente actuar sobre esos datos de manera controlada, registrada, auditable. El futuro probable no es por tanto ni make ni buy: es "buy the platform, make the last mile". La plataforma especializada se compra; la capa propietaria del fondo, sus datos, sus reglas, sus skills de agentes, se construye encima. Es una inversión masiva en el sistema de información, pero en capital de datos y procesos, no en la refabricación de fontanería.

Tokenización: la era de la prueba, versión 2

Vendrá después el capítulo blockchain: anclar los KPIs, sellar temporalmente las decisiones y sus justificaciones subyacentes en registros distribuidos es extender al propio dato de gestión la lógica de procedencia que ya se aplica a los contenidos. Notemos de paso que la blockchain es el ejemplo último del buy: nadie forja su propia cadena, uno se conecta a estándares mutualizados. Y de nuevo, la ventaja irá a los fondos cuyos datos ya están certificados y estructurados, listos para ser sellados; no se tokeniza un archivo Excel en cuatro versiones.

What's the next big move?

Si todo el mundo está aumentado, el alfa de la augmentación desaparece, y la diferenciación refluye hacia lo que no se convierte en commodity. Se perfilan tres candidatos. El GP como data company primero: su valor de franquicia incluirá su yacimiento de datos privados acumulados y los modelos afinados sobre ellos, algo que los LPs acabarán valorando en due diligence. El paso de la ayuda a la decisión a la ejecución delegada después: agentes que hacen sourcing, vigilan covenants, preparan comités, y cuyo valor dependerá enteramente de la calidad de la doctrina codificada que se les haga aplicar, un sistema operativo del juicio propio de cada fondo. La distribución por último: la tokenización de las participaciones abrirá los mercados privados a tickets más pequeños y hará de la transparencia verificable en tiempo real un argumento de captación. En los tres escenarios, el ganador no es quien haya recodificado su CRM. Es quien haya capitalizado sus datos y su doctrina.

Veredicto

Make or buy es, en el fondo, un falso debate, y la proyección a dos años no lo invierte: lo desplaza. La commodity se compra, hoy como mañana, y mañana más todavía. Lo que se construye es lo que solo usted posee: sus datos, sus procesos, su doctrina. La verdadera pregunta de su próximo comité no es por tanto "¿cuánto costaría nuestra herramienta casera?". Es: "¿qué poseemos que nadie puede comprar, y qué hemos hecho este año para que valga más?"

Referencias

[1] Robert L. Glass, "Facts and Fallacies of Software Engineering", Addison-Wesley, 2002, en particular el hecho n.º 41 sobre la parte del mantenimiento en el coste de vida de un software (del 40 al 80% según los estudios): https://dl.acm.org/doi/book/10.5555/579853

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