If you're weighing a custom tool for your business, the cost that catches people out isn't the build. It's the hours your own team has to put in — deciding how the work actually happens, testing the thing, and moving off whatever you're using now.
That time is real, it lands on your busiest people, and it's the single biggest reason small projects stall. Plan for it and a custom tool is a good investment. Ignore it and you end up paying for software nobody switched to.
Where the hours actually go
A developer can build a scheduling tool, a quoting form, or an internal dashboard without much of your involvement. What they can't do is decide what your business rules are. That part is yours, and it's the slow part.
Here's what usually needs someone from your side:
- Describing the current process honestly. Not the tidy version — the real one, including the exceptions. "Except for the two customers who get billed differently" is exactly the detail that breaks a build later.
- Deciding the edge cases. What happens when a job is cancelled after it's invoiced? Who can delete a record? These questions come up mid-build and need an answer from someone with authority.
- Testing with real data. Half an hour of a staff member clicking through their actual daily work finds more problems than a week of developer testing.
- Cleaning up what you're moving. Old spreadsheets have duplicates, blanks, and three spellings of the same supplier. Someone has to sort that before it moves.
- Learning the new way. Even a well-designed tool costs each person a few slower days.
None of these are large on their own. Together they're the project.
Who has to do it
The person who understands the process well enough to answer questions is almost always the person you can least spare. The office manager who knows why the billing works that way. The dispatcher who remembers every quirk.
So pick a single decision-maker before you start, and give them room. An hour a week, blocked off, for the length of the project. That's usually enough — but it has to be real time, not time they're expected to find on top of a full day.
And write things down as you go. If the only record of why a rule exists lives in one person's head, you'll rebuild that conversation every time the tool changes.
How to make it smaller
The most useful thing you can do is shrink the first version. Not the ambition — the first version.
Pick the one part of the process that hurts most and do only that. A single form that replaces an email chain. A dashboard that shows one number your team currently digs for. Something people can use in a fortnight, not a quarter.
Small first versions have a compounding advantage: your team learns what they actually want by using something. Nearly every list of requirements written before a build changes once people touch a working version. Better to discover that on a two-week build than a six-month one.
The honest test
Before you commission anything custom, ask yourself who is going to answer the questions, and whether they have the hours. If the answer is "we'll figure it out," the project isn't ready yet — and waiting a month costs you far less than a half-finished tool.
When the answer is a named person with time on their calendar, you're in good shape. That's the difference between a tool that gets used and one that gets quietly abandoned.
