A new person starts on Monday. By Friday they can do roughly nothing unsupervised. Three weeks in they are handling simple cases, and someone has printed them a cheat sheet explaining which of the eleven fields on the order screen actually matter. Your internal tools are costing you three weeks of salary on every single hire, and nobody has ever put that on a budget line.
The usual response is better training and more documentation. That treats the symptom. If competent adults need weeks to learn how to do a job they were hired to do, the software is describing your organisation's accumulated history rather than the work.
Why internal tools get complicated
Nobody designs this. It accumulates, and understanding how helps you unpick it.
Fields get added and never removed. Someone needed to track something in 2021, a field appeared, that person left, and the field remains. Multiply by five years and half your form is archaeology.
Exceptions become permanent structure. One awkward client needed different handling, so a special path was added. Now everyone must understand a workflow that applies to one customer.
Systems are joined by people rather than integration. The order goes in one system, gets copied into another, and someone reconciles them weekly. The reconciliation becomes a documented job, so the gap between systems is now a role.
And the people who built it already knew the business, so nothing was designed for someone encountering it fresh. The interface makes sense if you were present for the decisions and is close to unreadable if you were not.
There is also a quieter force at work: nobody is ever rewarded for removing something. Adding a field solves a visible problem for a specific person who asked. Removing one risks breaking something for someone who did not speak up, and produces no obvious win for whoever did it. So the incentives point in one direction only, and complexity ratchets upward year after year without any single decision being wrong. Recognising this is useful, because it means simplification will not happen organically. Somebody has to be given the job explicitly.
Measure what it costs before you argue for change
Simplifying internal tools competes against customer facing work, and it loses that argument unless you can put a number on it.
Start with time to productivity: how long before a new hire works unsupervised, multiplied by salary, multiplied by hires per year. In a team with meaningful turnover this is a substantial recurring cost.
Add the ongoing drag. Time spent on manual reconciliation, correcting errors caused by confusing interfaces, and asking colleagues how to do things. That last one is doubly expensive because it consumes two people.
Then add the error cost. Mistakes traceable to someone misunderstanding a screen or filling the wrong field. These are usually recorded as human error, and the pattern of which errors recur tells you exactly which parts of the interface are misleading.
The total is generally large enough to justify real work, and it is invisible precisely because it is spread across every person every day rather than appearing as a single line.
Read More - Nobody Opens Your App After Day One: How to Fix App Retention
Find the cheat sheets
The fastest diagnostic available costs nothing. Ask your team to send you whatever informal documentation they use: the notes app, the printed sheet taped to a monitor, the shared document explaining what to actually do.
These are a precise map of where your internal tools fail. Every cheat sheet exists because the software did not make something clear enough. If four people independently wrote down the same sequence, that sequence should have been one button.
Pay particular attention to instructions of the form "ignore this field" or "always put X here" or "this says one thing but means another." Each is a piece of the interface actively working against the person using it, and each is usually cheap to fix once identified.
Delete from your internal tools before you build
The instinct is to build a better system. Start by removing things instead, because it is faster, cheaper, and frequently sufficient.
Audit every field on your most used screens and find out who uses each one and for what. You will discover fields nobody has read in years, still required, still confusing every new hire. Removing them costs almost nothing and immediately reduces what someone must learn.
Do the same with reports, statuses, and permission levels. Most organisations have far more statuses than the process actually has meaningful states, several of which mean the same thing to different departments. Consolidating them removes ambiguity and shortens training.
This work is unglamorous and it is where most of the return sits. A screen with six relevant fields is dramatically easier to learn than one with eighteen fields where twelve are ignored, and getting there requires deletion rather than development.
The shadow process nobody documented
There is a category of complexity that never appears in any system audit, because it happens outside the software entirely. Ask a few people to describe how a routine job actually gets done, end to end, and compare that against how the process is officially documented.
The gap is usually substantial. Someone messages a colleague to check something the system cannot show. A spreadsheet sits alongside the main tool holding the information it does not capture. A step happens by email because nobody trusts the built in notification. None of this appears in your internal tools and all of it is part of the job a new hire has to learn.
This matters because it explains onboarding time that looks inexplicable on paper. A new starter is not only learning eleven fields, they are learning that the third one is unreliable so everyone checks it manually, and that the status field is ignored because a separate tracker is the real source of truth. None of that is written down anywhere, which is why it takes weeks and why documentation never fixes it.
Mapping the shadow process is uncomfortable and genuinely valuable. Every workaround you find is either a missing feature or a trust problem, and both are fixable once visible. Teams that do this exercise routinely discover that two or three specific gaps generate most of the informal activity, and closing those removes a disproportionate share of what new people struggle with.
Read More - Your Cloud Bill Grows Faster Than Revenue: How to Cut SaaS Infrastructure Cost
Design for the newest person
The principle that fixes this durably is designing for someone who started last week rather than for the person who has been there five years.
Experienced staff adapt to bad interfaces and stop noticing. They have internalised which fields matter, which warnings to ignore, and which sequence works. Their feedback is genuinely valuable and systematically blind to exactly the problems that cost you three weeks per hire.
Practical version: make the common path obvious and put the rare path behind something. Use labels that match the words your team actually say, not the words in the database schema. Validate at entry so mistakes are prevented rather than discovered. And make the next step visible, so nobody has to remember what happens after they save.
The test is whether a competent new starter can complete a routine task correctly without asking anyone. If not, the gap between what the interface communicates and what the job requires is being paid for in salary, permanently.
If your internal tools are costing weeks per hire, our custom software development and web app development teams rebuild around the process rather than the history. Related reading: when a spreadsheet becomes business software, disconnected tools, and escaping vendor lock in.
Frequently Asked Questions
Is this not solved by better training?
Training helps and it treats the symptom. If competent people need weeks to learn a routine task, the complexity is in the software rather than in their ability. Better documentation makes a confusing system survivable while leaving the recurring cost in place on every hire and every daily interaction.
How do we find which fields to remove?
Ask who reads each one and for what decision, then check whether the data is actually used anywhere downstream. Fields nobody can justify are usually leftovers from a process that changed years ago. Where you are unsure, hide it first and see whether anyone notices before deleting.
What if different departments need different things?
Show each role only what it needs rather than showing everyone everything. Most complexity in shared internal tools comes from every user seeing the union of all requirements, when role based views would give each person a much simpler interface over the same underlying data.
Should we rebuild or improve what we have?
Improve first, since deletion and consolidation are far cheaper than rebuilding and often deliver most of the benefit. Rebuild when the underlying data model no longer matches how the business works, because interface changes cannot fix a structure that represents the wrong things.
How long should onboarding realistically take?
For routine tasks, a competent new hire should be working unsupervised within days rather than weeks. Genuine domain expertise reasonably takes longer, and learning which of eleven fields to fill in is not domain expertise, it is friction you built and can remove.
Our team says the current system is fine. Why change it?
Experienced users adapt and stop noticing, so their view is real and incomplete. Ask people who joined in the last six months instead, and look at the informal cheat sheets circulating. Both reveal problems that long serving staff have stopped seeing because they solved them personally years ago.
Where do we start if we only have limited time?
Collect the informal documentation your team already wrote and fix whatever it explains. Those notes are a free, accurate list of exactly where the software fails, prioritised by the people who hit the problems daily, and most items on it are small changes rather than projects.
Talk to our team if onboarding cost is hiding in your internal systems.