The business case for internal AI tooling, in numbers
Stop pitching the tool and start costing the status quo. Nobody approves "we should build something." People approve "this process costs us $143,000 a year and the fix pays for itself in six weeks."
The calculator below produces that sentence for your workflow. The rest of this piece is about who to say it to, and in what order.
Why internal tooling proposals stall
The typical proposal argues that a tool would be good. It describes features, it mentions efficiency, and it asks for budget against a benefit nobody has quantified. It then joins a queue behind things that have numbers attached.
Meanwhile the manual process it would replace is already being funded, in full, every single week. It just does not appear on any line item, because it is buried inside salaries. This is the entire trick: the expensive option is the one you are currently running, and it is invisible.
Your job is to make it visible.
What the manual version costs you
a year, spent on this one workflow, already approved and already invisible
Assumes 46 working weeks and that the tool removes the manual work rather than reducing it. If you expect a partial saving, scale the hours down instead of arguing about the rate. Loaded cost means salary plus employment costs, not what lands in someone's bank account.
Taking this to the person who owns the budget? Get it as a clean one-pager with your numbers on it. We'll also send a copy to your inbox with one suggestion for what to build first.
That didn't go through. Check the email and try again.
The number people react to is rarely the annual one. It is the cost of waiting a quarter, because that is the decision actually on the table. Nobody is choosing between building and not building. They are choosing between building now and discussing it again in three months, and that second option has a price.
Who to convince, and in what order
The instinct is to take this to IT. Resist it. Not because IT is obstructive, but because a single-team workflow tool is the worst possible fit for a central platform backlog: too small to prioritise against the systems of record, too specific to standardise, and too tied to one team's process to survive a committee.
Go to the person whose budget is already absorbing the cost. The operations lead, the revenue leader, the head of the team doing the work. They are paying the $143,000, and they are the only person who can approve stopping.
| Who | What they need to hear | What kills it |
|---|---|---|
| The operator doing the work | This removes the Thursday afternoon you hate | Being told it will "free them up", which they hear as a headcount conversation |
| The budget owner | Annual cost, payback in weeks, cost of a quarter's delay | Feature lists, and any sentence containing the word platform |
| IT and security | Where the data sits, who can see it, that the code is owned and exportable | Finding out after the fact. Bring them in early as reviewers, not approvers |
| The executive sponsor | One number and one working screen | A twenty-page proposal for a five-figure decision |
Show, do not propose
The single highest-leverage change to how these get approved: walk in with a working version instead of a document.
This used to be impossible, which is why the proposal culture exists. Getting to a demo meant scoping, then engineering time, then a month, all of which required the approval you were trying to obtain. The chicken and egg problem was real.
It is not real any more. A rough but functioning version of a single-workflow tool, with the team's own data in it, is now days of work rather than a quarter. That inverts the entire conversation. You are no longer asking someone to imagine a benefit and fund a risk. You are showing them the thing, running on their numbers, and asking whether to finish it.
The bottleneck on internal tools was never the idea, it was the cost of finding out whether the idea was any good. When a prototype costs days, you stop needing permission to try, and start needing a decision to keep.
This is the practical argument for building on something like Lovable rather than starting from a repository. Not that the code is better, but that the first working screen arrives before the enthusiasm does, and the people who understand the workflow can drive it themselves. The engineering questions, permissions, integrations, and scale, arrive later and are answerable then.
Budget for the twelve weeks after launch
Most internal tools that fail do not fail technically. They launch, three people use them, and by month three everyone has drifted back to the spreadsheet. The build was fine. The rollout did not exist.
So put it in the proposal explicitly:
- A named owner on the business side, not the build side, for the first quarter.
- Usage instrumented from day one. If you cannot see who used it last week, you cannot tell adoption from politeness.
- A fix window in weeks two and three. There will be two small things that irritate people. Fixing them fast is the difference between a tool and an anecdote.
- One retirement decision. Name the spreadsheet or the report that this replaces, and actually switch it off. Running both is how adoption dies quietly.
If you want the same argument applied to whether you should build at all rather than buy a platform, that is a separate five-test framework. And if the hard part in your organisation is getting people to care rather than getting the money, run a hackathon instead of a pitch.
The one-paragraph version
Take the workflow that annoys your team most. Put its real numbers into the calculator above. Take the annual figure and the quarter-delay figure to the person whose budget already carries it, with a working screen open on your laptop. Ask for a decision, not a discussion.
That is the whole method. The numbers do the persuading, and they were always there.
Frequently asked questions
How do I build a business case for internal tooling?
Cost the status quo rather than the tool. Multiply the number of people doing the manual work by the hours it takes them each week, by their loaded hourly cost, by the working weeks in a year. That annual figure is the thing you are choosing to keep paying, and it is almost always larger than the build.
Who should approve an internal tooling project?
Whoever owns the budget the manual work is already consuming, which is usually the operational leader rather than IT. Internal tools that wait for a central platform team tend to die in a queue, because they are too small to prioritise and too specific to standardise.
What does an internal tool cost to build?
A single workflow tool with real data, authentication, and permissions typically lands in the low five figures and takes weeks rather than quarters. The comparison that matters is not the build cost against zero, it is the build cost against a year of the manual process.
Why do internal tools fail after launch?
Almost always adoption rather than software. Nobody owned the rollout, nobody watched usage in the first month, and the two things that annoyed people on day one never got fixed. Budget for the twelve weeks after launch, not just the build.
Got a number that surprised you?
Tell us the workflow behind it. Thirty minutes, and we will tell you honestly whether it is worth building, even if the answer is no.
Book a 30-minute call