There is a tune playing in more and more executive committees these days: "With LLMs, development costs ten times less. Why keep paying for SaaS? We could just rebuild the tool ourselves." The demonstration is often performed live: a partner opens a coding assistant, generates a prototype tracking dashboard in twenty minutes, and the room is won over. The mental quote is settled: one developer, one LLM, done.

The demonstration is true. The quote is false. Because what the twenty-minute prototype does not show is everything that separates a prototype from software running in production at an asset management firm: application administration, access rights, security, backups, compliance, turning a vague need into a specification and then into tested code, and a roadmap that never stops because the business never stops. Software engineering research has been saying it for forty years: maintenance and evolution account, according to the classic studies, for 40 to 80% of a software product's total lifecycle cost, far more than its initial development [1]. LLMs have divided the cost of version one. They have not divided the cost of the following five years.

This piece plays out in two acts: first the math, today, numbers on the table. Then the two-year projection, where the answer gets more complicated, and where the real question is no longer the one you think.

Part one: today's math

Let's run the numbers

Take a mid-sized asset management firm, 15 to 30 people, that decides to build its management tool in-house (portfolio CRM, reporting, monitoring). Let us model honestly what "make" costs, in fully loaded French salaries, 2026, with deliberately conservative assumptions.

Facing it, a subscription to a specialized market solution, at comparable scope: not a mere CRM, but the full platform the developer was supposed to build, CRM, reporting, portals, data:

And pause on the symmetry, because it is worth every demonstration: the license costs the price of the developer, 80 k€. For the same budget, make gets you one person; buy gets you a complete product, an entire team, a roadmap that moves forward without you, battle-tested security, and someone who answers for it. The extra cost of make sits in every other line of the table: the intern, the audit, the tooling, the business time, the code takeover. In total, nearly double over five years, with assumptions that actually favor "make": a single developer (no serious project survives long on one), no schedule slippage, no mid-course technical rebuild, and a single departure in five years. Every line of this table is adjustable, and I encourage you to redo the math with your own numbers; experience shows the adjustments rarely go make's way.

The three lines the mental quote always forgets

Business time. This is the most underestimated line in the table, and often the largest in reality. An internal tool only advances if the business explains, arbitrates, tests and re-tests. Every hour a partner or a CFO spends clarifying a calculation rule or validating a mockup is an hour taken from deals, LPs and portfolio companies. That is the defocus risk: the true cost of make is not read in the budget, it is read in the calendars of the best-paid people in the firm.

The bus factor, private equity edition. Your developer, who over the months has become the only human who understands the code, one day receives an offer from the GP across the street. He leaves with the only brain that knows why line 4,218 must never, ever be modified. Having a newcomer take over a codebase is expensive when it is possible at all; sometimes it ends in a rewrite. The intern, for his part, was brilliant, but he went back to school in September.

Design expertise. A specialized vendor brings more than code: it brings a product shaped by dozens of clients in the same business, who hit your problems before you did, the regulatory edge cases, the version upgrades, proven security, tooled-up GDPR. In-house, every lesson is paid for once more, live, on your own data. And recall MIT's figure on internal generative AI projects: 95% of pilots produce no measurable impact on the P&L [2]. Building your own tool with an LLM means stacking the two bets.

When make is justified anyway

Let us be honest, because legitimate cases exist: when the tool IS your core competitive advantage (a proprietary analysis model that grounds your investment thesis), when no market product covers a genuinely singular need, or when your size justifies a real engineering team, with several developers, a product manager and an owned budget, not one lone developer and an intern. Make is a profession; the problem is not choosing it, it is choosing it without knowing that it is one.

The moment you see the strings

By now you will have noticed that the author of these lines sells, precisely, software licenses to asset management firms. That is correct, and it is exactly why he knows every line of the table so well: these costs, administration, security, audits, roadmap, version upgrades, we pay them, pooled across all our clients instead of being borne by one alone. That is the entire economic thesis of specialized software, and it has not been repealed by LLMs; it comes out reinforced, because we too now build faster than before, to the benefit of the same license.

So the next time the twenty-minute prototype dazzles the committee, ask a single question: who maintains it in five years, and what will you have done less of in the meantime? The table above is waiting for your numbers.

Part two: will make win in two years?

Let us project ourselves, because the objection deserves to be taken seriously. Within two years, the entire asset management value chain will have digitized: more flows processed, more information absorbed, more precision in selection and in portfolio support. Every GP will be "augmented" by data and AI, and that augmentation will become a commodity, necessary but no longer sufficient. In that world, shouldn't a GP, contrary to everything above, invest massively in its infrastructure and IT? Won't make end up winning?

The frontier is not fixed, it rises

First reading key: the make/buy frontier has never been a dogma, it is a line that rises with the level of abstraction. Nobody "makes" their mail server anymore; everybody used to "make" their Excel models. The right question is therefore never make or buy in the absolute, but: where does the frontier sit for my fund, today? And the paradox of the two-year projection is that it reinforces part one on its own turf: if data and AI tooling becomes a commodity, then rebuilding a commodity is the worst possible investment. You do not create competitive advantage by re-manufacturing what everyone owns. The old CIO maxim has never been truer: make what makes you different, buy what makes you the same.

The argument that could break, and the one that replaces it

Let us be honest about the weak point: the entire table in part one rests on the cost of maintenance. If, in three or five years, autonomous agents maintain, fix and evolve code without human intervention, that argument erodes, and make becomes thinkable again. Two reservations, however. The first is arithmetic: vendors benefit from exactly the same revolution, and the relative gap, a cost pooled across dozens of clients versus a cost borne alone, persists as long as the slightest fixed cost remains. The second is deeper and specific to our industry: a regulated business will not run its middle office on self-generated, ever-shifting code. Someone will always have to answer for the system: certified versions, auditability, a chain of responsibility. In the age of agents, "software accountability" becomes the product, exactly as editorial responsibility became, with Article 50 of the AI Act, the dividing line for content. What you will buy from a vendor tomorrow is no longer code; it is someone who answers for it.

Buy the platform, make the last mile

So yes, the GP should invest massively in its IT, but not in the sense the little tune intends. The asset to build is not the pipe; it is what flows through it and what steers it. Three layers, precisely. Proprietary data first: the operational data of your portfolio companies is a deposit nobody else owns, and its golden source is worth more than any development. Doctrine next: the fund that has documented and codified its processes and investment rules will be able to have agents execute them; the fund that keeps them in the partners' heads will not. Governed interfaces finally, MCP-type servers, which will let any agent act on that data in a controlled, logged, auditable way. The probable future is therefore neither make nor buy: it is "buy the platform, make the last mile". The specialized platform is bought; the fund's proprietary layer, its data, its rules, its agent skills, is built on top. That is a massive IT investment, but in data and process capital, not in re-manufacturing plumbing.

Tokenization: the age of proof, version 2

Then will come the blockchain chapter: anchoring KPIs, timestamping decisions and their underlying rationales on distributed ledgers means extending to management data itself the provenance logic that already applies to content. Note in passing that blockchain is the ultimate buy: nobody forges their own chain, everyone plugs into pooled standards. And here again, the advantage will go to funds whose data is already certified and structured, ready to be stamped; you do not tokenize an Excel file that exists in four versions.

What's the next big move?

If everyone is augmented, the alpha of augmentation disappears, and differentiation flows back to what does not commoditize. Three candidates emerge. The GP as a data company first: its franchise value will include its accumulated private data deposit and the models refined on it, something LPs will eventually price into due diligence. The shift from decision support to delegated execution next: agents that source, monitor covenants, prepare committees, and whose value will depend entirely on the quality of the codified doctrine they are given to apply, an operating system of judgment specific to each fund. Distribution finally: the tokenization of fund units will open private markets to smaller tickets and make real-time verifiable transparency a fundraising argument. In all three scenarios, the winner is not the firm that recoded its CRM. It is the one that capitalized its data and its doctrine.

Verdict

Make or buy is, deep down, a false debate, and the two-year projection does not reverse it: it displaces it. Commodity is bought, today as tomorrow, and tomorrow even more so. What gets built is what you alone possess: your data, your processes, your doctrine. The real question for your next committee is therefore not "how much would our in-house tool cost?". It is: "what do we own that nobody can buy, and what did we do this year to make it worth more?"

References

[1] Robert L. Glass, "Facts and Fallacies of Software Engineering", Addison-Wesley, 2002, notably fact #41 on maintenance's share of software lifecycle cost (40 to 80% depending on the studies): https://dl.acm.org/doi/book/10.5555/579853

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