There is a moment in the life of almost every internal build when the problem outgrows what an individual builder should own. Recognizing that moment and acting on it is not failure. It is the mark of a builder who understands their role clearly.
The question today is not “can we build it?” It’s whether the organization should own the system after it works. Who will maintain it? Validate it? Monitor it? Who will ensure it respects permissions? Take responsibility when the output is wrong?
AI lowered the cost of starting. It did not lower the cost of owning. Building something that demonstrates a problem is worth solving is a contribution. Knowing when to hand it to the appropriate support team is what makes it lasting.
The most persistent misconception in internal tool-building is that the cost of building a tool is the cost of building it. It is not. The cost of building a tool is the cost of everything that comes after.
Development time is the visible cost: the hours spent designing, prompting, coding, testing, and deploying. What rarely gets counted is the maintenance burden that begins the moment the tool goes into use: fixing unexpected behavior, updating the tool when a connected system changes, answering questions from colleagues, retraining users, investigating exceptions, revisiting permissions, and eventually sunsetting the tool when it can no longer be sustained.
Download our latest eBook for the full guide.
For AI-powered tools, the burden is more dynamic than traditional spreadsheet macros. Models change. McKinsey has estimated that technical debt can amount to 20 to 40 percent of the value of an organization’s technology estate before depreciation. That is the enterprise version of a simple truth: shortcuts compound.
The honest cost-effectiveness question is not “is building this cheaper than buying a vendor solution?”
The honest question is: Is building this, maintaining it, updating it, securing it, monitoring it, supporting it, and eventually sunsetting it cheaper than buying a vendor solution, and is the person who will do all of that work actually available to do it?
Consider:
A real estate investment firm needed to run performance attribution on its portfolio. The issue was a daily calculation that broke down returns by property, by strategy, by period — it was manual, time-consuming, and error-prone. Someone on the team built a custom tool to automate it. The tool worked, producing outputs the team needed daily, and freeing up meaningful time that had previously gone to a process nobody enjoyed.
2 years later, it stopped rolling. The outputs, however, did not stop. What the tool produced after it stopped rolling was not nothing — it was stale data, carried forward, still formatted correctly, still landing in the right place, still being read and trusted and used to inform decisions.
Nobody knew what they didn't know. What makes these failures particularly dangerous is precisely what makes the tools valuable in the first place — they became the fabric of daily operations. The takeaway: invisible infrastructure fails invisibly.
The signals are recognizable:
At that point, the right move is not to build faster or extend the tool further. The right move is to surface the problem to the people equipped to own it at the scale it has become: IT, leadership, risk, finance, a consultant, or a vendor.
Read "Your Builders Are Already Building: A CRE Leader's Guide to Build vs. Buy in the AI Era" for a practical framework on how to answer the build vs. buy investment question .