Launch in Days, Not Weeks
Professional one-page website. Only a few slots left this month
“It’ll save us time” isn’t a business case. To get budget approved for a custom internal tool, you need to quantify the current cost of manual work, project the compounding returns of automation, and account for the less obvious gains — fewer errors, faster scaling, better decisions from cleaner data. Here’s the framework we use with clients building that case.
The ROI Formula for Internal Tools
At its simplest:
ROI = (time saved × hourly cost + errors avoided × cost per error + revenue enabled) ÷ total investment
Each term deserves unpacking, because the mistakes people make building this case are almost always in how they calculate the inputs, not the formula itself.
- Time saved — hours per week the manual process currently consumes, multiplied by the fully loaded hourly cost of the people doing it (salary plus overhead, not just base pay).
- Errors avoided — how often the manual process produces mistakes, and what each mistake actually costs to fix or costs you in damaged trust.
- Revenue enabled — work the tool makes possible that wasn’t possible before: faster client onboarding, capacity to take on more accounts, faster turnaround that wins deals.
- Total investment — the build cost plus a realistic maintenance allowance, not just the initial invoice.
Quantifying Current Costs
Before you can project a return, you need an honest baseline, and most businesses have never actually measured it.
Time tracking the manual process. Ask the people doing the work to log hours for two weeks, not from memory. Memory consistently underestimates admin-heavy tasks because they don’t feel like “real work” the way client-facing tasks do.
Counting errors. Go back through the last month or two of the process and count actual mistakes — wrong figures, missed steps, duplicate entries. If nobody’s tracking this already, that itself is worth noting in the business case.
Measuring bottleneck delays. Where does the manual process create a queue? A report that takes three days because it depends on one person’s availability is a cost even when nothing goes wrong — that’s exactly the kind of bottleneck we unpack in our piece on the hidden costs of manual work.
Projecting Returns
This is where most ROI calculations fall short — they model a single, flat saving instead of the way returns actually compound.
Linear vs compound savings. A simple model assumes the tool saves the same fixed number of hours every month. In practice, well-adopted tools save more over time as the team gets faster with them and edge cases get handled.
Scaling effects. A manual process that takes five hours a week at your current size might take fifteen hours a week once you’ve doubled your client base — the manual cost scales with growth, but a tool’s operating cost usually doesn’t. This is one of the strongest arguments for building before you’re forced to.
Second-order benefits. Better data quality from a properly built tool means better decisions downstream — pricing, staffing, prioritisation. These are real but harder to quantify, so include them as a qualitative point in your business case rather than forcing a number onto them.
Building the Business Case
Keep it to one page. Stakeholders and boards respond to a case that’s easy to scan, not one that demonstrates how much analysis went into it.
Payback period. How many months until cumulative savings exceed the total investment? This is usually the single number decision-makers care about most.
12-month projection. Month-by-month or quarter-by-quarter savings, showing the point where the tool pays for itself and what it returns after that.
Risk factors. Be upfront about what could go wrong — lower-than-expected adoption, scope creep during the build, a process that changes before launch. A business case that acknowledges risk is more credible than one that doesn’t.
Alternatives considered. Show that off-the-shelf options were genuinely evaluated, not dismissed by default. This is also where our piece on when your business actually needs a custom app is worth referencing directly in the case itself.
Worked Example
Take a 5-person team spending 10 hours a week combined on a manual process — chasing data across systems, reconciling a spreadsheet, compiling a report by hand. At a blended fully-loaded hourly cost, that’s a meaningful chunk of salary spent on admin every single week, before counting a single error.
A custom tool that removes 80% of that manual time pays back the build cost within a handful of months once you account for time saved alone — and that’s before factoring in fewer errors or the capacity freed up for higher-value work. The exact payback period depends entirely on your team’s hourly cost and the scope of the build, which is why the framework matters more than any single example number: run your own inputs through it rather than borrowing someone else’s.
Compare that against a SaaS subscription covering the same ground: subscription costs typically scale with usage and seats, so the gap between the two options often narrows or reverses over a multi-year horizon, particularly if your team is growing. Neither option is automatically cheaper — it depends on your growth trajectory and how well the SaaS tool actually fits your process, which loops back to the build-vs-buy decision covered in the article linked above.
Common Mistakes
Overestimating adoption. A tool nobody actually uses saves nothing, no matter how good the build is. Model a realistic adoption curve, not day-one full usage.
Ignoring maintenance costs. Custom software isn’t a one-time cost. Budget for ongoing updates, or the ROI case looks better on paper than it performs in year two.
Forgetting training time. Even an intuitive tool takes time away from productive work while people learn it. Build this into your payback timeline, not around it.
Not measuring post-launch. The business case that got the build approved should be revisited after launch. If the actual time savings differ from the projection, that’s valuable information for the next tool you build — and for internal tool ROI discussions with stakeholders going forward.
Getting the Numbers Right Before You Ask for Budget
The strongest business cases we’ve seen come from teams who tracked their current process properly before writing a single line of the proposal. Guessing at time savings is the fastest way to lose credibility with a board or a finance director who’s seen inflated automation pitches before.
Need help building a defensible business case? Talk to us about building your ROI case through our advisory service, or see how we approach the build side through AI systems.