A working internal tool in 48 hours is a real thing now, and it is the cheapest part of owning it. The commonly cited split for software is that the initial build is around a fifth of lifetime cost. The other four fifths is keeping it working, changing it as the business changes, and fixing it when the world moves underneath it. Treat that split as folk wisdom rather than a study. It has been quoted at anything from 60 to 80 per cent for decades, and nobody who has run software for five years argues with the shape of it.
AI changed one of those numbers. The fifth got smaller. The four fifths did not move.
What the four fifths is made of
When I label post-build work, it lands in one of four buckets, and the surprise for most people is how little of it is bugs.
- Bugs. The tool does not do what was agreed. Genuinely the smallest bucket on a tool that works.
- Polish and change requests. The business changed its mind or its process. Constant, and fair.
- Maintenance. Nothing in the tool changed and nobody asked for anything. A third-party API changed its response, a platform deprecated an endpoint, a login provider retired a method. The code did nothing wrong and still stopped.
Maintenance is the bucket that catches people. A 48-hour tool usually leans on three or four outside services. Each one will change something in the next year. When it does, the question is who notices and who fixes it. If the answer is “the person who built it, if they are still here, when they have time”, the tool has no maintenance plan.
The mirage
Leadership sees the fifth shrink and reads it as the whole cost shrinking. It is the same mistake as pricing a vehicle at the purchase price.
Gartner put a number on the project version of this in July 2024. They forecast that at least 30 per cent of generative AI projects would be abandoned after proof of concept by the end of 2025, and listed the reasons: poor data quality, inadequate risk controls, escalating costs, unclear business value. That is a forecast about AI initiatives in general, not a measurement of AI-written code. The reasons still fit. A tool that was cheap to build and has no budget to run is a proof of concept that happens to be in production.
What to do about it
- Price the year, not the weekend. For every tool that runs part of the business, write down what it depends on and who fixes it when one of those changes. If nobody is named, the cost is unknown, not zero.
- Put the tool on a care plan. A few hours a month, held by someone, to watch the services it depends on and apply the changes. This is the plan the company already has for its accounting software. AI-built tools are not exempt.
- Add the invisible parts before the tool matters. Monitoring that says when it broke, not a user. A note of what data it reads and writes. A security pass. The infrastructure playbook has eight parts with a “done looks like” line for each. The rule from it: eight shown, rely on it; four shown, it is still a prototype.
- Ask the deprecation question at build time. Which of these APIs is beta, and what happens when it goes? If the build chose a beta service and the service is retired in six months, that is on the build, not on the business.
Done looks like a tool that survived its first API change without anyone noticing except the person on the care plan.