Nobody sets out to build an internal tools estate. What happens is that someone in operations needs an answer the ERP will not give, so they export to a spreadsheet. The spreadsheet becomes the way the team schedules work. Someone adds a macro. A developer writes a script that emails a report every Monday. Two years later a new hire asks how pricing is calculated and the honest answer is that it is calculated in a workbook on a shared drive, by a formula nobody has read since the person who wrote it changed roles.
That is an internal tool. So is the admin panel, the Access database, the Airtable base, the Power Automate flow, and the batch job on the server under someone's desk. This guide is about deciding which of them deserve to be treated as real software, because the answer is emphatically not all of them.
Where internal tools come from
Almost every internal tool has one of three origins, and the origin tells you a lot about how it will fail.
- The spreadsheet that grew. Started as one person's working file, became the system of record for something, and now has concurrency problems, no history, and no validation. Fails by corruption and disagreement.
- The thing one developer built. Genuinely useful, often genuinely good, and completely undocumented. Runs on credentials in a config file and knowledge in one head. Fails when that person leaves.
- The workaround for a system that does not fit. Exists because the ERP or the SaaS platform cannot express a rule the business actually runs on. Fails quietly, by drifting out of sync with the system it patches.
The third category is worth dwelling on, because it is the one most likely to be misdiagnosed. When a business has a dozen workarounds around one platform, the tools are not the problem. They are the symptom, and replacing them individually just rebuilds the same patchwork in a nicer language.
The test for whether it deserves engineering
Crudeness is not the test. Plenty of ugly tools are perfectly appropriate, and rebuilding them is a waste of money. The useful questions are about consequence and continuity.
| Question | Leave it alone if | Build it properly if |
|---|---|---|
| What breaks when it stops? | One person is inconvenienced for an afternoon. | Invoices do not go out, or technicians do not get dispatched. |
| Who can fix it? | Several people understand it, or it is simple enough to re-derive. | Exactly one person, and the fix is not written down anywhere. |
| What does it know? | It performs a calculation anyone could reconstruct from a policy document. | It encodes pricing, eligibility, or scheduling rules that exist nowhere else. |
| How many people touch it? | One owner, occasional use, no concurrency. | Several people edit it during the same working hours. |
| What data is in it? | Nothing sensitive, nothing regulated, nothing customer-identifying. | Personal data, payment details, or anything an auditor would ask about. |
| How would you audit it? | You would not need to. | Someone has already asked who changed a number, and there was no answer. |
What separates a tool that lasts
When a tool does justify real engineering, the difference between one that lasts and one that becomes next year's problem has very little to do with the framework it is written in.
- Someone owns it by name, and that ownership survives a reorganization. An unowned tool decays no matter how well it was built.
- It can be deployed by someone who did not write it, from a documented process, without a person's laptop being involved.
- The rules it encodes are covered by tests, so that the reason a threshold is 14 days rather than 30 is recoverable after the author has gone.
- Access is modeled rather than assumed. Who can see what, and who can approve what, expressed in the tool rather than in the habit of the people using it.
- Actions are attributable. Not full compliance tooling, just an honest record of who changed what and when, because that question always eventually gets asked.
- It has an off switch. A tool you cannot retire without an archaeology project will still be running in five years for reasons nobody remembers.
None of that is exotic and none of it requires a large budget. What it requires is treating the tool as a thing the business owns rather than a favour someone did for a colleague.
The maintenance question people skip
Internal tools are usually costed as a build. They are actually a subscription, paid in attention. Dependencies need updating, the platform it integrates with changes its API, the tax rule changes, someone leaves and the knowledge goes with them.
A useful discipline before building anything internal: name the person who will maintain it, and the budget it will consume annually. If neither answer exists, you are not deciding whether to build a tool. You are deciding whether to create an orphan, and orphans are how the estate got into its current state.
The other cost people miss is the one paid at the boundary. An internal tool almost never stands alone: it reads from one system and writes to another, and both of those will change without asking you. An API version is deprecated, a field changes meaning, a vendor alters an export format. None of that is visible in the build estimate, and all of it lands on whoever owns the tool. Budgeting roughly fifteen to twenty-five per cent of build cost per year is a reasonable starting assumption, and it is lower for a tool that only reads than for one that writes.
When not to build
We build software for a living, so treat the following with appropriate suspicion. It is still true.
- When a well-established product does the job and your requirements are genuinely ordinary. Payroll, accounting, email, and expense management are solved problems and you will not out-build them.
- When the process is still changing weekly. Building software around an unstable process just encodes this month's version of it in the most expensive available medium.
- When the tool would serve three people and a manual process would take an hour a week. That is a rounding error against the cost of building and maintaining anything.
- When the real problem is that a platform you already pay for is configured badly. Fixing the configuration is cheaper and does not add another system to the estate.
Common questions
- Is it worth rebuilding a spreadsheet that works?
- Usually not, on its own. A spreadsheet that one person owns, that is backed up, and that the business could survive losing for a week is doing its job. What changes the answer is concurrency, consequence, or secrecy: several people editing at once, money or dispatch depending on the output, or rules inside it that exist nowhere else. Those are the conditions that make a spreadsheet a liability rather than a tool.
- Should internal tools be built by the operations team or by engineers?
- Both, at different risk levels. Tools that the business should be able to change without a ticket are better owned by the people doing the work, and low-code platforms are genuinely good at this. Tools on a revenue path, holding sensitive data, or encoding rules that need to be auditable belong with engineers. The failure mode is letting a tool drift from the first category into the second without anyone noticing that it has.
- How much does an internal tool cost to build?
- A focused single-workflow tool built properly is typically $25,000 to $90,000 depending on integrations and how much of the business rule has to be discovered rather than documented. The larger variable is almost never the interface. It is how many other systems it has to agree with, and how much of the underlying process nobody has written down.
- We have dozens of these. Where do we start?
- With an inventory rather than a build. Most businesses cannot name every tool they depend on, which means any prioritization is guesswork. Find them, rank them by what breaks if they stop and by how many people could fix them, then act on the top of that list. It is common for the highest-risk item to be something nobody had been worrying about.
- Can you take over a tool somebody else built?
- Yes, and it is often the cheaper path. Getting an existing tool building reliably, adding tests around the behaviour worth keeping, and documenting the rules inside it usually costs a fraction of a rebuild and removes most of the risk. Unfamiliar code and unfashionable technology are not the same thing as unsalvageable.