The tool we need doesn't exist and buying one doesn't fit
When every product on the market covers 70% and misses the part that actually matters, building the missing piece is now a reasonable option. AI-assisted engineering has moved small internal applications from “not worth a project” to a few weeks of work.
Is it really cheaper to build than to buy?
For a narrow internal tool, increasingly yes — but the honest comparison is not licence cost against build cost. It is the total of the licence, the workarounds for the part it does not do, the integration nobody budgeted, and the process your team will bend to fit the product.
What changed is the cost of the build, not the cost of maintaining it. An application produced quickly and understood by nobody is a liability whichever way it was made. So the question worth asking is not “can we build this?” but “will we still be able to change it in two years?”
The gap also rarely stays in one place. When a product covers most of what four teams need, four teams each build their own version of the rest: a spreadsheet here, a script there, an app somewhere else. None of them knows the others had the same problem. The cost is not the tool that was built. It is the three that did not need to be.
Haven't we built this before, in a spreadsheet?
Yes. Before the app builder, the fast tool was the spreadsheet. Someone needed what the system could not give, so they built it in a workbook. It worked. It got shared. It grew macros, hidden tabs and a second copy nobody reconciled. Then the person who understood it left.
That is technical debt. Nobody called it that, because nobody thought of a workbook as software. It was software: it ran the process, it held the logic, and it failed the way software fails, silently and on the day it mattered.
Generative AI puts the same speed in a new tool, and the same debt comes with it. An application generated in an afternoon and never designed is a spreadsheet with a login page.
What skill is missing when people start building with AI?
Writing the code was never the hard part, and now the AI does most of it. What is still missing is the part the tools do not cover: knowing what a piece of software is, and where it lives once it exists.
A tool never runs alone. It reads data that belongs to someone, it sits inside a network with rules, and it will be touched by people who did not write it. Security, architecture, maintainability: the things that get forgotten when a quick solution is built with generative AI, exactly as they were forgotten when it was built in Excel. The shift is simple to say: from prompting a tool to engineering one.
What usually goes wrong when building an internal tool?
- The build is scoped against the product it replaces, rather than against the workflow it serves.
- Speed of delivery becomes the only measure, and the maintainability bill arrives later.
- It is built for the team but not with them, so nobody inside can change it.
- Three teams solve the same missing piece three different ways, because nobody knew the other two had it.
- Nobody asked where it would live: what it can reach, what it depends on, who patches it.
How do we develop something that stays maintainable?
Scope to the workflow, once
We build to what the work needs, which is usually far less than a product's feature list and far more useful — and we check first whether another team has already built it.
Fast, with the gates on
AI-accelerated engineering with human review, tests, a security check and a maintainability standard: the speed without the debt.
Handover is the deliverable
Your people can run it, govern it and change it. If that is not true, the project is not finished.
Is the missing piece still a spreadsheet?
Describe the workflow the product never quite fit. We will tell you honestly whether it is a few weeks of build, a configuration nobody tried, or something another team already has.