Every organisation has that one internal tool.

You know the one. The expense reporting system that requires you to log in, then log in again because it timed out, then upload each receipt individually as a JPEG smaller than 2MB, then select from a dropdown of expense categories that nobody designed with actual expenses in mind (“Miscellaneous” is doing a lot of work in there), then submit for approval, which sends an email to a manager who also has to log in, and then three days later asks you to re-upload the receipt because the format was wrong.

All to report a $47 lunch.

I have done my time in terrible internal software. And I have watched smart, capable teams route around tools that were supposed to help them, because the tools were built as afterthoughts, implemented as requirements, and never actually tested by a real human being doing a real job.

Why internal tools are usually terrible

The honest answer is that internal tools are rarely anyone’s priority.

Customer-facing products get attention. The website gets polished. The client portal gets refined based on feedback. The marketing site gets A/B tested.

Internal tools get built once, deployed, and then quietly resented forever.

Often they were purchased, not built. Off-the-shelf software that covers 70 percent of the use case, with the other 30 percent addressed by a process document nobody reads and a workaround that has become so embedded in daily routine that new hires assume it is the intended workflow.

Sometimes they were built internally, years ago, by someone who has since left. The codebase is a mystery. Nobody wants to touch it. Requests for changes go into a backlog that exists purely to give people somewhere to put their frustration.

And sometimes they were built by an external developer who did their best, but the brief was “build something like X, but for us” — which was not specific enough to produce something that actually fit, but was specific enough to cost a lot of money.

The result, in all three cases, is the same. A tool your team tolerates rather than uses. A tool they quietly route around when they can. A tool that is technically in use but practically adding friction to every interaction.

What “good” actually looks like

I have a simple test for whether an internal tool is working.

Do people use it without being told to? Not “do they use it because they have to” — that is compliance, not adoption. But genuinely: do they open it because it makes their job easier?

Good internal tools have a few things in common.

They are fast. Not fast in a “it only takes 30 seconds” way. Fast in a way where the tool gets out of the way and lets you do the thing you came to do. No loading spinners on every page transition. No re-authentication every 20 minutes.

They show you what you need, not everything available. The worst internal dashboards are the ones that show every metric, every filter, and every possible view because the designer could not decide what mattered. The best ones show you the three things you actually check, immediately, without clicking.

They fit how you actually work. Not how someone theorised you work based on a requirements document. How you actually, physically do your job. The fields that matter to you are prominent. The steps that are optional are clearly optional. The workflow matches your real-world process, not a sanitised version of it.

They work on mobile. This feels like a basic expectation and somehow still fails all the time. If your field team, your sales team, or anyone who is not sitting at a desk uses a tool, it needs to work on a phone. Not “technically loads on a phone.” Actually works.

What AI-assisted development actually changes here

For a long time, the gap between “the tool we have” and “the tool we want” was bridged by nothing, because building the tool we wanted was too expensive and too slow.

That calculation has changed significantly.

We can now build a functional internal tool in a matter of days. Not a prototype. Not a mockup. A real tool, running in production, with your data, your user roles, your integrations. The development timeline compression from AI-assisted tooling is real and it is significant.

I have written about this in the context of custom app development, but internal tools are actually an even better fit for this approach than external-facing products. The requirements are clearer. The user base is smaller and accessible for feedback. The stakes are lower in the sense that you are not launching to thousands of external users. And the iteration cycle is faster because you can sit with the team on Day 3 of the build and watch them use it.

That last part matters more than people realise. Watching a real user try to do a real task with your tool for five minutes tells you more than a month of requirements gathering. And when you can deploy a change in an afternoon, the feedback loop is tight enough to actually use.

Tools we have built that people genuinely like using

Let me give you some real examples from work we have done through Omni Apps.

A job dispatch board for a trade services business. Previously managed in a shared spreadsheet and a WhatsApp group. Now a single screen where jobs come in, get assigned to field staff, update automatically when work is completed, and trigger invoices in the accounting system. The operations manager told us it was the first piece of software in five years she did not want to throw out a window.

An approval workflow tool for a professional services firm. Their old process involved email threads, PDFs attached to more emails, and a shared drive that was always out of date. Now there is a simple interface where requests come in, route to the right approver, track the decision, and log everything automatically. The whole thing is two screens.

A reporting dashboard for a multi-location retail business. Five systems used to feed five separate reports. Someone spent a day each week pulling them together into a master spreadsheet. Now it is one screen, updated daily, with the three metrics that actually drive decisions front and centre. The day-per-week manual process is gone.

None of these are complex in terms of their requirements. They are simple, targeted, and built exactly for the way that team works. That is why they get used.

The ROI of tools people actually use

Here is the number that does not get talked about enough.

What is the cost of a tool your team works around instead of with?

Not the subscription cost. Not the implementation cost. The daily friction cost. The five minutes per person per day spent on workarounds, manual steps, or information that has to be found somewhere else because the tool does not have it. Multiplied by your headcount. Multiplied by 250 working days per year.

It adds up faster than you expect.

And the other side of that calculation: what does it look like when a tool genuinely saves time? When the field team can mark a job complete from their phone in 30 seconds and the invoice generates automatically? When the operations manager has the information she needs in one screen instead of three systems? When reporting is automatic instead of a day-long manual process?

The ROI on internal tools that actually work is not hypothetical. It is concrete, it compounds, and it starts from day one.

The tool you are putting up with right now

If you are reading this, you probably have a specific tool in mind.

The one that your team has complained about. The one that you have mentally flagged as “something to sort out eventually.” The one where the workaround has become so normal that it does not register as a problem anymore, even though it costs time every day.

That tool can be replaced. Or built from scratch. In less time and at a lower cost than you probably think.

We do a free discovery call where we look at the specific tool or workflow you have in mind and give you an honest picture of what it would take to build something better. Sometimes the answer is straightforward. Sometimes we find that a configuration change or a different off-the-shelf option solves it. Sometimes we build it in a week.

Either way, “put up with it” is not your only option.

---

Tell us about the internal tool you wish existed. Book a call with the Omni Apps team and let’s talk about what it would take to build something your team genuinely wants to use.

Also worth reading: Why Off-the-Shelf Software Will Never Fit Your Business and 5 Signs Your Business Has Outgrown Its Tech Stack.