AI lowered the cost of custom software, and many CRE firms read that as a reason to build everything. The conclusion is wrong because the premise is incomplete. AI cut the cost of writing code. It did not cut the cost of owning software: maintaining it, reviewing it, securing it and keeping it correct as the business changes. Writing was never most of the bill. So the build-versus-buy line moved, but only for one kind of tool: small, narrow, stable software where the first build was the dominant cost. For systems a firm depends on every day, the line barely moved at all.
Key Takeaways
AI reduced the cost of writing code. It did not reduce the cost of owning software, which is where most of a system's lifetime cost has always sat.
Robert Glass, in Facts and Fallacies of Software Engineering, put maintenance at 40 to 80 percent of total software cost. Cutting only the build shrinks the smaller share of the bill.
The measured gains are uneven. A 2023 controlled experiment found developers finished a bounded greenfield task 55.8 percent faster with an AI assistant, while METR's 2025 trial found experienced developers 19 percent slower on mature codebases.
The build-versus-buy line moved furthest for narrow, stable, firm-specific tools. It moved least for systems of record.
A cheaper first version is not a cheaper decade. The right comparison is lifetime cost of ownership against lifetime subscription cost.
What did AI change about the cost of custom software?
AI changed the cost of producing a first working version. A developer with a capable assistant can turn a clear specification into running code faster than before, especially on new, self-contained projects. What AI did not change is the work that follows: review, testing, hosting, security, upgrades, and the ongoing cost of someone who understands the system.
The clearest evidence of the gain comes from a 2023 randomized experiment by Peng, Kalliamvakou, Cihon and Demirer (arXiv 2302.06590). Ninety-five professional developers were asked to build an HTTP server in JavaScript. The group with an AI pair programmer finished 55.8 percent faster than the group without one.
The task in that study matters as much as the result. It was new code, a defined goal, no existing system to respect and no production history to protect. That is the most favorable case for AI assistance, and it is also a fair description of the first version of a small internal tool.
Why does a cheaper build not mean cheaper software?
A cheaper build does not mean cheaper software because building is the minority of what software costs over its life. The larger share is maintenance: fixing defects, adapting to changed inputs, patching dependencies and answering the question of why a number looks wrong. AI helps with some of that work, but far less reliably.
Robert Glass's Facts and Fallacies of Software Engineering (2002) summarized decades of research into one rule: maintenance typically consumes 40 to 80 percent of software cost, and most of it is enhancement rather than bug fixing. The software keeps changing because the business around it keeps changing.
METR's 2025 randomized trial (METR) tested exactly that kind of work. Sixteen experienced developers completed 246 real tasks in large, mature repositories they already knew. With AI tools allowed, they took 19 percent longer, even though they believed afterward that AI had made them about 20 percent faster. The overhead of reviewing and integrating generated code absorbed the gain.
Read together, the two studies describe the shape of the shift. AI is strongest at the start of a system's life and weakest in the long middle, which is where the money goes.
Cost component | Share of lifetime cost | Effect of AI assistance |
|---|---|---|
First build | Minority | Large reduction on bounded, new projects |
Enhancement and change | Majority of maintenance | Mixed; slower on mature codebases in METR's trial |
Review and testing | Grows with output volume | Increases, since more generated code needs checking |
Hosting, security, upgrades | Fixed and recurring | Little change |
Owner who understands the system | Recurring | No change; key-person risk remains |
Where did the build-versus-buy line move for CRE firms?
The line moved toward building for narrow, stable tools that encode a firm's own method: a screening filter that applies house rules, a report that reshapes data into the firm's format, a checker that flags a clause the team cares about. For these, the first build was most of the cost, so a cheaper build changes the answer.
These tools share three traits. Their scope is small, so review is fast. Their inputs change slowly, so maintenance stays light. And their logic is specific to the firm, so no vendor product fits them without a workaround. The earlier argument that off-the-shelf software is built for the median firm applies here with more force, because the cost of serving the firm's own edge dropped.
The line did not move for systems of record: the lease database, the accounting ledger, the document store, the extraction pipeline that feeds underwriting. These systems carry heavy maintenance, strict correctness requirements and audit exposure. Their cost was always dominated by ownership, and ownership did not get cheaper. The layered view from the proptech build vs buy question still holds: own the layer that encodes your judgment, buy the plumbing.
"AI made the first draft of software cheap. It did nothing to make the tenth year of software cheap."
How should an operator run the new build-versus-buy math?
An operator should compare lifetime cost, not build cost. Estimate the first build, then add annual ownership cost over the years the firm expects to use the tool. Compare that total to the subscription over the same period. AI changes the first number. It rarely changes the second, and the second usually decides the answer.
Worked example: two tools, one assumption
The inputs below are illustrative, chosen to show the mechanics rather than to describe any real product. Assume AI assistance halves the first build cost and leaves annual ownership cost unchanged. Each tool is compared against a packaged subscription over the same five-year holding period.
Input | Narrow screening tool | Lease system of record |
|---|---|---|
Build cost before AI | $100,000 | $300,000 |
Build cost with AI (halved) | $50,000 | $150,000 |
Annual ownership cost | $10,000 | $60,000 |
Five-year ownership | $50,000 | $300,000 |
Five-year total before AI | $150,000 | $600,000 |
Five-year total with AI | $100,000 | $450,000 |
Five-year subscription alternative | $150,000 ($30,000 a year) | $300,000 ($60,000 a year) |
Decision before AI | Tie | Buy |
Decision with AI | Build | Buy |
The screening tool flips. Its build was two-thirds of its lifetime cost, so halving the build cut the total by a third and moved it below the subscription.
The system of record does not flip. Its build was half of its lifetime cost, so the same 50 percent reduction cut the total by only 25 percent, and it still costs $150,000 more than buying. The rule falls out of the arithmetic: the larger the build's share of lifetime cost, the more AI moves the decision.
This example also ignores two costs that push further toward buying for large systems. The first is review cost, which rises when more code is generated than a team can read carefully. The second is the cost of proving the system works before depending on it, the discipline covered in acceptance testing.
What mistakes follow from reading AI as "build everything"?
The main mistake is treating a fast first version as proof of a cheap system. A firm builds a working prototype in weeks, declares victory and discovers the maintenance bill a year later, often after the developer who understood it has moved on. The prototype was cheap. The dependency it created was not.
Three failure patterns recur:
Failure | What happens | Why AI makes it more likely |
|---|---|---|
Prototype becomes production | A demo quietly turns into a system the team relies on | Demos arrive faster, before anyone decides to own them |
Unreviewed volume | More code is written than anyone checks | Generation outpaces review capacity |
Orphaned tools | The builder leaves and nobody can change the tool | Faster builds spread tools across more people |
Each of these is an ownership failure, not a build failure. The firm that asks who will own a tool in year three before it approves the build avoids all three.
Frequently Asked Questions
Did AI make custom software cheaper for CRE firms?
AI made the first build cheaper, especially for small, new projects with clear specifications. It did not make ownership cheaper. Since maintenance has historically been 40 to 80 percent of software cost, the total savings are smaller than the build savings suggest.
Which CRE tools are now worth building instead of buying?
Narrow, stable tools that encode the firm's own method are the strongest candidates, such as screening filters, formatting reports and clause checkers. They have small scope, slow-changing inputs and logic no vendor product fits well.
Should a CRE firm build its own system of record now that AI exists?
Usually not. Systems of record carry heavy, recurring ownership costs and strict correctness requirements. Halving the build cost of such a system rarely brings its lifetime cost below a subscription.
Does AI make experienced developers faster?
It depends on the work. A 2023 controlled experiment found a 55.8 percent speedup on a new, bounded task, while METR's 2025 trial found experienced developers 19 percent slower on large, mature codebases they knew well.
Conclusion
AI cut the cost of custom software at the point where software was already cheapest to reason about: the first version. It left the expensive part, owning the system for years, largely where it was. For the underwriter, principal or asset manager, that means the build-versus-buy line moved in a specific direction. Build more of the small tools that carry the firm's method, where the first build was most of the cost. Keep buying the systems of record, where ownership was always the bill. The decision is still made on lifetime cost, and AI changed only one line of that calculation.