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 30% 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?”
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.
- A prototype that was never meant to last quietly becomes production.
How do we build something that stays maintainable?
Scope to the workflow
We build to what the work needs, which is usually far less than a product's feature list and far more useful.
Fast, with the gates on
AI-accelerated engineering with human review, tests 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.
Sound familiar?
Start with an assessment — people, process and technology, looked at together.