--- title: "The tool was free to build. Maintaining it is not." description: "Why internal tools built in-house get hard to change, and the design choices that keep them cheap to maintain." canonical: "https://stackdrop.co/blog/in-house-internal-tools-maintenance-problem" published: "2026-06-23T09:00:00.000Z" updated: "2026-06-23T09:00:00.000Z" authors: ["John Miniadis"] topics: ["Rescue and migration", "Production"] readers: ["operators", "leaders"] --- # The tool was free to build. Maintaining it is not. A new tax rule needs one extra field on the invoice screen. The request goes to the only person who understands the tool, and it waits behind everything else on their list. When the change finally lands, a report on another screen breaks. That is the maintenance problem in an in-house internal tool. The logic lives in one person's head, nothing is written down, and a change that should take an hour takes weeks. The platform is rarely the cause. The tool that works fine in its first year is often the one nobody will touch in its third. Nothing visible breaks. What climbs is the cost of changing it. A routine request, such as a renamed field or a new approval step, becomes a project nobody wants to own. ## How a tool gets harder to change 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 for a single client. None of those changes is large. Together they produce a tool where moving one part breaks another. The same thing happens when a standard ERP is extended with custom work it was not designed for. The tool stops describing how the work happens. It becomes a record of every decision made under pressure, with no note of why. [Why your internal tools behave the way they do](https://stackdrop.co/blog/systems-logic-internal-tools) covers how the rules inside a tool decide what you can safely change later. [A one-line change should not take three weeks](https://stackdrop.co/blog/internal-tools-slow-to-change-architecture) covers the architecture side. ## When one person holds the knowledge Key-person dependency means the knowledge of how a tool works lives with one person instead of in the system. The build can be sound and still carry it. If only the author knows why a calculation works as it does, or which fields are safe to touch, every change waits on one calendar. Every absence becomes a freeze. It surfaces most when that person is about to leave. At one manufacturer, part of the operation ran on a Microsoft Access database that one person understood. She was a year or two from retirement, and nobody else knew the database the way she did. Teams without engineers raise the same concern from the other side. When they choose who builds a tool, the first question is often what happens after the builders leave. That is the right question. A tool only one person can maintain is waiting on a resignation letter, and it is a common reason tools get abandoned. [Built well, used by nobody](https://stackdrop.co/blog/behavioral-adoption-internal-tools) covers that pattern. ## What maintenance really costs Maintenance shows up as hours, not line items, which is why it stays invisible until it is large. A change that should take an hour takes a week, because someone has to work out how the original build fits together before touching it. Across every small request in a year, that adds up. The bigger cost is the one nobody invoices. When a tool is fragile, teams route around it. They keep a spreadsheet beside it, re-key data by hand, and add manual checks for what the tool can no longer be trusted to do. They also stop asking for changes, because they already know the answer. The burden moves into the daily work of the people the tool was meant to free up. [The hidden cost of manual processes](https://stackdrop.co/blog/the-hidden-cost-of-manual-processes) covers that side of the bill. ## What keeps a tool cheap to maintain Four properties, decided at the start: - **Documented logic.** The next person reads why a rule exists instead of guessing. - **The interface separate from the data.** A change to how a screen looks does not put the underlying records at risk. - **A named owner.** One person or team is responsible for the tool's health, so nobody assumes it will keep running because it always has. - **Access rules and an audit trail from the first release.** Adding them later means rebuilding. The real test of an internal tool comes 18 months after launch. Can a different person change it safely? ## Rebuild or refactor Refactor when the data model is sound and the trouble is undocumented logic or tangled code. Rebuild when the structure no longer matches how the business works today. The data usually decides it. If the schema still reflects reality, a documented refactor is quicker and carries less risk. If the tool has drifted far from how the team operates now, a rebuild that captures the current process costs less over two years. ## Documenting a tool nobody documented Start with the decisions rather than the code: what each rule does, why it exists, and which parts are safe to change. Sit with the person who built or runs the tool, and capture the reasoning behind the parts that look arbitrary. Those are the parts that break when someone else edits them. Add 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 it easier? It does, when the build has the same discipline as good custom code. On Retool, the interface, the data connections, and the access rules stay visible and separate, which is what makes later changes safe. Retool's new app builder adds version history and source control, so every change has a record and can be rolled back. A tool assembled without documentation or an owner develops the same key-person dependency on any platform. The practice decides the outcome. ## Our view We recommend designing for the second person from the first release, because most of a tool's lifetime cost is the cost of changing it. Document the rules, separate the interface from the data, name an owner, and build in access and audit before go-live. That is the standard across the more than 200 internal tools we have built. The customer's team can run and change each one without whoever wrote the first version. The product owner decides what changes next, and whether we stay for the running of it.