The Cost of Inheriting Other People's Tools
Most companies have internal tools nobody’s happy with but nobody will touch.
You know the ones. The tool sort of works, sort of doesn’t. The person maintaining it can see what’s wrong but can’t fix it. Leadership knows it’s not great but won’t approve rebuilding it. So it just sits there, collecting dust or whatever digital tools do when they aren’t used.
The inheritance problem
Here’s how it happens. Someone builds an internal tool. It works well enough that everyone starts using it. It becomes a part of the core process of the company. But then that person leaves.
The company scrambles because they can’t afford to lose the tool, so they hand it to someone else. But when you inherit a tool, you don’t just get the code. You take on all the assumptions, decisions, and constraints that went into building it. And none of that is written down anywhere.
Sure, if you’re lucky, you get a handover. Maybe a few meetings where the original developer dumps information on you. Maybe even some documentation (hopefully readable, not 100% AI-generated). But that only tells you how the tool works. You don’t get the why. Why this approach? What were the constraints? What assumptions were made? What’s the guiding principle of the entire codebase?
All of that is tucked neatly in the head of the person who just left.
So now you’re stuck reverse-engineering intent from output. AI is really good now but even it can’t tell you why things are created a certain way. And when you can see problems but don’t have the context to understand what’s safe to change, you’ve got two options.
Hi, I’m Braden
I help teams be more efficient in the AEC Industry, then share stories about it here. I also have courses, guides and scripts as part of CodedShapes Pro
Check it out if that sounds like you.
If you’re new to CodedShapes, welcome! You might enjoy these:
Fully Rebuild
Pitch a full rebuild. You put together a business case with a timeline, a budget and reasons why starting from scratch is better. It’s the whole “I can do this better and 10x cheaper” attitude.
But leadership weighs the cost of rebuilding something that “already works but ‘better’” and usually the answer is no.
Add to it
Which leads to the more common option of just adding to it. No refactor, just keeping adding on to the existing codebase. And soon enough it becomes a house of cards because the intent and context of the tool was never communicated.
You’re too scared to modify the core, so you build on top of it. Workarounds, band-aids, adapters, all just to keep the tool running. But each one makes the tool a bit more fragile, a bit harder to maintain.
It’s like a garage you’re afraid to clean out, it’s easier to just keep stacking boxes than to deal with what’s actually inside. But eventually, you’re going to run out of space and have to deal with the contents.
Why this keeps happening
My theory is that it’s a misplacement of our attention.
People only care about a tool twice: when it’s being built and when it breaks. Everything in between is invisible.
The building phase gets all the attention. There’s a budget, momentum and excitement in the air. There’s constant updates on the tool and when it launches, people clap for it because it works and it’s finished.
From that point on, no one actively working on it and there’s no budget for maintenance. Maintenance doesn’t look like work. You can point at a new feature, a launch, a demo. But you can’t point at “keeping something running that everyone assumes just runs.”
The reality is that there’s no “finish” when it comes to tools. They still need to be documented, updated and maintained.
Part of me understands this because if you think about it from leadership’s perspective. They approved the budget. They gave someone time to build it and they’ve rolled it out. Success. The tool is done, so it must be working. Move on to the next thing.
Maintenance is not a full time job and it’s harder to justify it in your timesheet. Which is why it’s often just squeezed in with the other more pressing things. Well, until it breaks, then everyone rushes you to fix it.
Thanks for reading
Subscribe to CodedShapes and I’ll send you my free guide on how to actually apply it to your projects.
What actually fixes this
The real fix here is the structure around it. Software developers, whose full time job is to deliver products to customers, have figured this out. And we can learn from them.
Document the assumptions, not just the code. Most handover docs explain how a tool works. What’s missing is why. Why this approach? What were the constraints? What depends on what? When assumptions are visible, the next person can make informed decisions instead of guessing. This is hard to do after the tool is done, the best way is to document as you build.
Give the maintainer real authority. If someone’s responsible for a tool, they need the power to act on what they see. That means either decision-making authority over the tool’s direction, or a clear escalation path that actually leads somewhere.
Treat tools as living systems, not finished products. A tool isn’t done when it launches. It’s done when it’s decommissioned. Everything in between is active work that needs to be planned for, budgeted for, and respected as real work.
None of this is glamorous and can feel like a waste of money. But it’s the key to long lasting tools beyond a single developer.
The hard part was never building it
Building an internal tool is exciting. There’s momentum, there’s a vision, there’s someone who knows exactly what they’re doing and why.
But that moment is temporary. The person leaves and the tool keeps running on assumptions that no one knows.
The hard part was always what comes after. Making sure the tool outlives the person who built it. Making sure the next person who touches it has the context to make good decisions.
If any of this sounds familiar, that’s because it’s happening at most companies right now. Somewhere in your organization, there’s a tool nobody’s happy with but is critical to how the company operates. What you need is a way to ensure continuity.
That’s the kind of problem I help teams solve. Not just building the tool, but ensuring that it doesn’t fall apart when the people change. If you want to talk about what that looks like for your team, reply to this email or book in a call with the button below.
If you’re thinking about bringing computational design into a project, I’m happy to talk through how you’re framing the problem and if it’s the right solution.
Thanks for reading.