Most quotes for a small business internal tool land somewhere between ten thousand dollars and well over a hundred thousand, for what sounds like the exact same request. That spread isn't a sign someone's trying to take you for a ride. Two things explain almost all of it: where the developer sits, and how tightly the job was scoped before anyone wrote a number down. The part people actually want answered, whether the thing pays for itself, has an honest answer too, and it has nothing to do with revenue.
Look at the rate bands and the gap stops looking mysterious. Development shops charge anywhere from twenty four to forty nine dollars an hour offshore, and fifty to a hundred and forty nine dollars an hour for a team based in the US, Canada or Australia. Reviewed projects on Clutch, the industry's own pricing tracker, run ten to forty nine thousand dollars. The platform's own average project comes in near a hundred and thirty two thousand dollars, over about thirteen months. Put the same feature list in front of a twenty four dollar an hour team and a hundred and twenty five dollar an hour team and you already have most of the gap, before scope even enters the conversation.
Scope decides the final number, not the hourly rate. The pattern behind decades of custom software projects that blew their budgets is consistent: underestimated complexity, requirements that kept changing mid build, users nobody planned for. Queensland's public health payroll system is the extreme case, landing near two hundred times its original estimate, from six million dollars to one point two billion. Almost none of these failed because the developers couldn't code; they failed because nobody locked the requirements before work started. The same mechanism plays out at your scale, just with fewer zeros. "Track inventory" sounds simple until it needs permissions, an audit trail, and an edge case nobody wrote down, and the quote keeps climbing for the same reason a public agency's did, not because anyone lowballed you to get the job. The scoping work a studio does before a line of code gets written is what catches that early, not a cheaper rate.
Return on investment is the wrong question for an internal tool, and most of what gets published about it dodges that honestly. An internal tool has no revenue line, so there's no clean calculation to run. The real payback shows up somewhere else: hours a person no longer spends on a manual task, an error rate that drops, a subscription you stop paying every month. Anyone selling you a tidy ROI percentage for a piece of internal software invented the number.
Here's what that looks like when it actually works. Someone who built an internal password manager for their company described it afterward on a public forum: the build took four to six person months of developer time. A commercial equivalent licensed for five thousand seats would have cost more in a year than that one time build did, in salary alone. No revenue entered the calculation anywhere, and it still paid for itself within twelve months. The rule holds past that one example: build when the workflow has rules or handoffs no off the shelf tool covers, buy when the problem looks exactly like everyone else's.
None of this gets settled by comparing a single quote against your gut feeling about what it should cost. Write the scope down first, in enough detail that whoever prices it also has to live with what they built two years from now. Then compare quotes against that document, not against each other.