Why internal tools built in-house turn into a maintenance problem

Internal tools built in-house turn into a maintenance problem when the logic lives in one person's head, nothing is documented, and a change that should take an hour takes weeks. The platform is rarely the cause. The cause is key-person dependency and undocumented decisions nobody can safely unpick later. 

The tool that works fine in its first year is the same tool that becomes untouchable in its third. Nothing visible breaks. What changes is the cost of changing it, and that cost climbs quietly until a routine request, a new tax rule, a renamed field, a different approval step, turns into a project nobody wants to own.

Why do in-house internal tools get harder to change over time?

In-house internal tools get harder to change because the logic accumulates faster than the documentation, and each new requirement gets added on top of the last without a plan for how it all holds together. The first version solves one clear problem. Then a second team asks for one more field, finance asks for one more rule, and an exception gets hard-coded to handle a single client. None of those changes is large on its own. Together they produce a tool where moving one part quietly breaks another.

 This is the same pattern teams hit when they extend an ERP past what it was built for. One operations leader described it directly: "When you start developing some custom things inside a standard ERP, it breaks other things." [Fireflies transcript, Stackdrop discovery call, 2026-05-06] The tool stops being a clean expression of how the work happens and becomes a record of every decision made under pressure, with no note of why. For more on why the rules inside a tool shape what you can safely change later, see the logic behind how your tools behave.

What is key-person dependency and why does it break internal tools?

Key-person dependency is when the knowledge of how a tool works lives with one person instead of in the system, so the tool becomes unmaintainable the moment that person leaves. The build can be sound and still carry this risk. If only the original author knows why a calculation runs the way it does, or which fields are safe to touch, then every change has to route through one calendar, and every absence becomes a freeze.

The risk surfaces most often when that person is about to leave. One operations leader, planning two years ahead, put it plainly: "The person who manages our access database will retire in one or two years. It will be difficult to replace her with someone who has also this access knowledge." [Fireflies transcript, Stackdrop discovery call, 2026-05-06] The same worry shows up the other way round when teams evaluate who should build a tool in the first place. The question we hear most from non-technical buyers is: "What happens when you leave? My team are non-technical and they need to be able to own this going forward." [discovery call, private capital fund, 2024-12-09] That instinct is the right one. A tool only one person can maintain is a liability waiting for a resignation letter. It is also a common reason tools get quietly abandoned once the person who understood them moves on, a pattern we go into in why internal tools get abandoned.

How much does internal tool maintenance actually cost?

Internal tool maintenance costs show up as hours, not line items, which is why they stay invisible until they are large. A change that should take an hour takes a week because someone has to reverse-engineer the original build before touching it. Multiply that by every small request across a year and the number stops being a rounding error. For organisations running three to five manual-heavy processes, the people cost alone sits between EUR 80,000 and EUR 200,000 per year, before counting the cost of the changes the team stopped asking for because they knew the answer would be "not worth it." We break that calculation down in the real cost of slow operations.

The harder cost is the one nobody invoices. When a tool is fragile, teams route around it. They keep a spreadsheet alongside it, re-key data by hand, and add manual checks to catch what the tool can no longer be trusted to do. The maintenance burden does not disappear; it moves into the day-to-day work of the people the tool was meant to free up.

What makes an internal tool cheap to maintain?

An internal tool is cheap to maintain when its logic is documented, the interface is separated from the data, someone owns it, and governance was built in from the start, not bolted on after something went wrong. Documentation means the next person can read why a rule exists instead of guessing. Separation means a change to how a screen looks does not put the underlying data at risk. Ownership means there is a named person or team responsible for the tool's health, not an assumption it will keep running because it always has.

This is what we design for across more than 200 internal tools delivered for over 50 EMEA clients: build so the client's own team, including non-technical colleagues, can run and change the tool without depending on whoever wrote the first version. Governance, access controls, and an audit trail go in at the start, because adding them later means rebuilding. The test of a well-built internal tool is not whether it works on launch day. It is whether a different person can safely change it eighteen months later. If your current tools fail that test, talk to a team that maintains what it builds.

FAQ

Should we rebuild or refactor a tool nobody can maintain?

Refactor when the data model is sound and the problem is undocumented logic or tangled code; rebuild when the underlying structure can no longer support how the business works today. The deciding factor is usually the data, not the interface. If the schema still reflects reality, a documented refactor is faster and lower-risk. If the tool has drifted far from how the team operates now, a rebuild that captures the current process is cheaper over a two-year horizon.

How do you document an internal tool that was never documented?

Start by recording the decisions, not the code: what each rule does, why it exists, and which parts are safe to change. The fastest route is to sit with the person who built or runs it and capture the reasoning behind the parts that look arbitrary, because those are the parts that break when someone else edits them. Pair that with a plain-language map of how data moves through the tool. The goal is that a new person can answer "why does it do this?" without finding the original author.

Does low-code make maintenance easier or harder than custom code?

Low-code makes maintenance easier when it is built with the same discipline as good custom code, and harder when it is treated as a shortcut around that discipline. A governed low-code build on a platform like Retool keeps the interface, data, and access rules visible and separable, which is what makes later changes safe. A low-code tool assembled without documentation or ownership develops the same key-person dependency as any other build. The platform sets the ceiling; the practice decides whether you reach it.