How to use the Software Development Quote Checker
This checker takes the price and hours from a software quote and works out the hourly rate hidden inside it. It divides price by hours, places the rate in one of four market bands, and compares the hours with a typical range for the kind of project. Use it when a vendor's quote arrives and you want a quick sense of whether the rate and the effort fit together.
Step by step
-
Enter the quoted price
Type the total fixed price or budget from the quote into Quoted price, in US dollars. The default is $50,000 and the box steps by $500.
-
Enter the hours
Type the total build hours into Hours in the quote. The default is 800. If the quote only gives a team and a timeline, multiply them out, for example 3 developers for 4 months at about 160 hours a month is 1,920 hours. Hours are rounded to whole numbers and anything under 1 counts as 1.
-
Pick the project type
Under What are they building?, choose Website, Web app, Mobile app, SaaS or Enterprise. The small text on each button is the typical hour range the checker uses for it, from 120 to 500 hours for a website up to 2,000 to 6,000 for an enterprise system. Web app is selected to start.
-
Read the verdict
The results panel updates as you type. Read the headline rate, the verdict box and the three cards, then compare the hour bars at the bottom.
Reading the result
- The headline is the implied hourly rate: quoted price divided by quoted hours, rounded to whole dollars. With the defaults it is $50,000 / 800 hrs, which shows as $63/hr.
- Implied team tier places that rate in a band: Offshore team under $45/hr, Nearshore / blended team from $45 to $85, US mid-market agency from $85 to $150, and US senior / premium above $150. The band is read from the rate alone, not from where the vendor is based.
- Hours vs typical reads Looks light below the range for your project type, Looks heavy above it, or In range inside it. The default 800 hours is In range for a web app, whose range is 600 to 1,500.
- The verdict box turns green with This quote is in a normal range when the rate is between $45 and $150 and the hours are in range. It turns amber when the rate is below $45 or above $150, and gray when the rate is fine but the hours fall outside the range.
- The two bars compare your quoted hours with the typical range, drawn at its midpoint.
Tips and common mistakes
- Treat Looks light as a reason to ask questions. A fair hourly rate on too few hours can turn into change orders later, so ask what the hours cover: QA, revisions, edge cases and deployment.
- A low rate is not wrong by itself and a high rate is not a rip-off by itself. Check that the seniority you are paying for matches the work.
- Use the total hours for the build, not hours per month or per person, or the rate will come out far too high.
- The hour ranges are broad defaults. A small web app with three screens can sit under the range and still be fair, so read the result against your own feature list.
Privacy and limits
The math runs in your browser as you type. The price and hours you enter are not sent anywhere or saved, and reloading the page restores the defaults. The rate bands and hour ranges are fixed in the tool and assume US dollar pricing.
How it works
Almost every software quote boils down to two numbers: a price and an amount of effort. The fastest way to tell whether a quote is fair is to divide one by the other and look at the implied hourly rate. That single number tells you far more than the headline price does, because it reveals which kind of team you are actually paying for.
This checker takes the price and the total build hours from your quote and computes the implied rate, then maps it to a market tier: under $45/hr usually means an offshore team, $45-$85/hr points to a nearshore or blended team, $85-$150/hr is typical US mid-market agency work, and above $150/hr is senior or premium US engineering. None of those bands is "wrong" on its own - a low rate can be excellent value and a high rate can be justified by hard, specialised work. What matters is that the rate and the hours make sense together.
That is why the tool also checks the quoted hours against a typical range for the kind of app you are building. A price can look fair on a per-hour basis while hiding too few hours to actually finish the job - the classic setup for change-order surprises later. If the hours look light or heavy, treat it as a prompt to pressure-test the estimate against your real feature list before you sign.
implied rate = quoted price / quoted hours
Remember that a fair price ultimately depends on scope, not just the rate. To sanity-check the hours themselves, run your feature list through our software development cost calculator, and if you are still deciding whether to commission a custom build at all, weigh it with the build-vs-buy calculator.
FAQs
What is a fair hourly rate for software development?
It depends on where the team sits. Offshore teams typically bill under $45/hr, nearshore or blended teams roughly $45-$85/hr, US mid-market agencies $85-$150/hr, and senior US or premium specialists above $150/hr. A rate is fair when it matches the seniority and location you actually need - a low rate is not automatically a bargain if the work needs senior engineers, and a high rate is not automatically a rip-off if the problem is genuinely hard.
My quote doesn't list hours - can I still use this?
Yes. If the quote gives a team size and a timeline, multiply them out: for example, 3 developers over 4 months at roughly 160 working hours each per month is about 1,920 hours. Enter that total. Even a rough estimate of the hours is enough to reveal the implied rate and whether the scope looks light or heavy for your kind of project.
The rate looks fine but the tool says the hours look light - should I worry?
It is worth a closer look. A reasonable rate on too few hours is one of the most common ways a quote ends up costing more than expected, because missing scope reappears later as change orders. Ask the vendor exactly what the hours include - QA, revisions, edge cases, deployment - and compare the number against a fresh estimate of your real feature list before committing.
