Blog
Key takeaways:
Every article about software development costs opens with a range, and every range is so wide it tells you nothing. Somewhere between fifty thousand and a quarter of a million dollars. Thanks.
The problem is not that those ranges are wrong. They are accurate descriptions of a market where a marketing site and a claims-processing platform are both called "custom software." The problem is that a range is not an estimate, and you cannot take a range to a board meeting.
So this guide does something different. It shows you the labor math that sits underneath every quote you will receive, gives you a worksheet to build your own number from your own scope, and names the costs that reliably go missing from a first budget.
By the end you should be able to produce a figure you can defend, and to tell within about ten minutes whether a quote you have been handed was built or guessed.
A quote arrives as a single number with a scope document attached. That format hides the three things you actually need to know.
Each one sits behind the total, where you cannot check it.
It hides the assumptions. A number built on "we will use your existing design system" and a number built on "we will design this from scratch" can differ by 40% and look identical on the page.
It hides the uncertainty. A single figure implies a precision nobody has at the start of a project. Real estimates are ranges that narrow as you learn.
And it hides the role mix. Engineering is rarely more than two thirds of a build. If a quote does not show design, project management and QA separately, either they are not properly accounted for, or they are and you cannot check.
None of that means providers are being dishonest. It means the standard format of a software quote is bad at communicating the one thing you need, which is what would have to be true for the number to hold.
Six things move custom software development costs more than anything else. Everything else is noise by comparison.
| Driver | Low end | High end | Why it moves the number |
|---|---|---|---|
| Number of distinct user roles | 1 | 4+ | Each role multiplies screens, permissions and test paths |
| Integrations with other systems | 0 to 1 | 5+ | Third-party APIs bring their own failure modes and edge cases |
| Data complexity | Simple records | Migration plus reporting | Migrating live data is often the single riskiest task |
| Regulatory exposure | None | HIPAA, PCI, SOC 2 | Compliance adds engineering, audit and documentation work |
| Platforms | One web app | Web plus iOS plus Android | Each platform is a build and a release process |
| Design maturity | Existing system | Brand and UI from zero | Design is a real line item, not a rounding error |
Notice what is absent from that list: the programming language, the framework, and the developer's country. Those affect rate and hiring pool. They do not change how much work exists.
The two rows that surprise people most are data migration and user roles. A second user type does not add a second set of screens, it adds a permissions model and a combinatorial set of states to test. This is why an estimate that grew by half after discovery is usually a sign discovery worked, not a sign someone padded the number.
Software is people. Once you understand what the people cost, every quote becomes readable.
The US Bureau of Labor Statistics reports that the median annual wage for software developers was $133,080 in May 2024. For the wider group of software developers, quality assurance analysts and testers, median pay was $131,450 a year, or $63.20 an hour. BLS projects that group to grow 15% between 2024 and 2034, much faster than average, with about 129,200 openings a year.
Now do the employer arithmetic. Take $133,080 in salary, add payroll taxes, benefits, equipment, software licenses and recruiting, and a fully loaded cost of roughly 1.25 to 1.4 times salary is a normal planning assumption. That puts a single mid-level US developer somewhere near $166,000 to $186,000 a year before they have written anything, and before you have paid for a designer, a product manager or a QA engineer.
Laid on one scale, the salary line stops well short of the total.
Set that against agency pricing. Clutch records our own average at $150 to $199 an hour, with engagements starting near $10,000, a band typical of US-based custom product work.
That looks like a large premium over $63 an hour, and it is, until you account for what it includes: no recruiting cycle, no benefits, no idle time between projects, a team rather than a person, and the ability to stop.
The honest summary is that agencies are not cheaper per hour and rarely claim to be. They are cheaper per outcome when the work is bounded, and more expensive when the work is continuous. Our guide to outsourcing software development works through exactly where that crossover sits.
The calculator is a worksheet you run by hand, with a spreadsheet and about twenty minutes. It will not give you a quote. It will give you a defensible planning number and, more usefully, a structure you can argue with.
The ranges below are the planning heuristics we use to size work at VAULT. They are our own, not an industry standard, and your provider's may differ. That is fine and worth discussing.
List every distinct thing a user can do, not every screen. "Reset a password" is a feature. "The settings page" is not. Aim for 15 to 40 items on a first product.
Then grade each one:
| Grade | What it looks like | Engineering weeks |
|---|---|---|
| Simple | A form, a list, a static view, standard auth | 0.5 to 1 |
| Standard | Business logic, state, permissions, one integration | 1 to 3 |
| Complex | Payments, migrations, real-time, offline sync, ML | 3 to 8 |
Grade honestly and grade alone before you show anyone. The instinct to call everything Simple is the single biggest source of budget failure, and it costs nothing to correct on a spreadsheet.
Multiply and add. A reasonably complete B2B product might come to 6 Simple at 0.75 weeks, 14 Standard at 2 weeks, and 3 Complex at 5 weeks, which totals 4.5 plus 28 plus 15, or 47.5 engineering weeks.
That number is not your project length. It is the amount of engineering labor required, which two engineers would work through in roughly 24 calendar weeks.
A first release is usually far smaller. Cut the same product to 6 Simple and 6 Standard, drop the complex work to a single item, and you are at 4.5 plus 12 plus 5, or 21.5 engineering weeks. We will carry both through the remaining steps, because the gap between them is the entire argument of this guide.
Engineering is not the whole build. On a typical product engagement, engineering runs about 55% to 65% of total effort, with design at roughly 15%, and product management plus QA making up the remainder.
Dividing your engineering weeks by 0.6 gives total team weeks. The full product at 47.5 becomes about 79 total team weeks; the first release at 21.5 becomes about 36.
Multiply total team weeks by a 40-hour week and your blended hourly rate. At the $150 to $199 band Clutch records for US firms, the two versions land a long way apart.
| Version | Engineering weeks | Team weeks | Hours | At $150/hr | At $199/hr |
|---|---|---|---|---|---|
| First release | 21.5 | 36 | 1,440 | $216,000 | $286,560 |
| Full product | 47.5 | 79 | 3,160 | $474,000 | $628,840 |
Two things are worth noticing. The first is that cutting eleven features roughly halved the cost, which no negotiation over hourly rate could ever do. The second is that even the smaller figure sits above the $50,000 to $199,999 band Clutch reports as the most common project size in this market.
The rate is identical on both sides; only the feature list changed.
That is not a contradiction, it is how the market actually works. Most quoted engagements are a phase, not a whole product: a discovery, a first release, a defined module. If your worksheet total is well above what firms seem to charge, you are pricing more scope than a typical engagement contains, and the fix is to phase the work rather than to hunt for a cheaper rate.
A single number is a false promise. Apply a band based on how well you understand the problem: plus or minus 15% if you have a validated spec and have built something like this before, plus 50% and minus 20% if you are working from a concept.
Then carry the range, not the midpoint, into your planning. The most useful thing this worksheet produces is not the figure. It is the ability to say which assumption you would have to change to move it.
There is an actual standard for this, and almost nobody in software applies it.
The US Government Accountability Office publishes the Cost Estimating and Assessment Guide, a 476-page document defining how federal programs are supposed to estimate cost. It sets out 12 steps and 18 best practices, and it states that a reliable cost estimate is one that is comprehensive, well documented, accurate, and credible.
Those four words are a usable test for any quote sitting in your inbox:
Run those four against the last quote you received. If you cannot find the assumptions written down anywhere, the estimate is not well documented, which means you cannot check it, which means you are being asked to trust a number rather than evaluate one.
The build is the part people budget for. It is frequently not the majority of three-year cost.
Ongoing engineering is the big one. Software is not finished at launch; plan 15% to 25% of the original build cost per year for maintenance, dependency updates, security patches and small improvements, and more if you are actively growing.
Then come the operating lines: cloud hosting, monitoring, error tracking, email and SMS delivery, and the per-seat tools your team needs. Individually small, collectively a real monthly number.
And then the ones that surprise people:
That last one deserves emphasis, because it is where do-it-yourself cost comparisons fall apart. One founder described on Reddit porting an iOS app to Android himself in two and a half weeks, for an $85 tool upgrade, rather than paying the $10,000 to $12,000 he had been quoted.
The sharpest reply pointed out that calling it $85 ignores the expensive part of software development, which is time. That is one person's opinion rather than a study, but the accounting instinct is right, and it applies to your own hours as much as to a contractor's.
The pricing model changes who carries the risk, and neither option removes it.
| Fixed price | Time and materials | |
|---|---|---|
| Who carries scope risk | The provider | You |
| Typical premium | 15% to 30% built into the price | None explicit |
| Behavior it encourages | Tight scope control, change orders | Flexibility, and drift if unmanaged |
| Works well for | Well-defined, previously-solved work | Discovery, evolving products |
| Fails when | Requirements are still moving | Nobody is tracking burn against value |
Fixed price is not the safe option people assume. A provider quoting a fixed price on a vague scope has priced their risk into the number, and will manage the difference through change orders, which is where relationships break down.
The practical middle ground is to buy a small, well-defined discovery phase at a fixed price, then use what it produces to pin down the build. You are not choosing between the two models so much as choosing when you know enough to use each one.
There are only four honest levers, and one of them does most of the work.
Every other lever is a rounding error next to this one. Halving your feature count halves your build. Ask of each feature: if we launched without this, would a single customer refuse to pay? Most features fail that test, and the discipline of applying it is worth more than any negotiation over hourly rates. Our guide on validating an app idea covers how to decide that before you build.
Build the parts that let you charge money first, even if the product looks unfinished. A product earning revenue at month four funds itself; the same product launched complete at month nine has to be funded entirely from your balance sheet. This is the argument we make in avoiding overthinking a build.
Authentication, payments, email, search and analytics are solved. Paying a vendor $200 a month beats spending $40,000 building a worse version. Reserve custom engineering for the part of the product that is genuinely yours, a distinction we work through in building versus optimizing.
Fixed headcount is expensive when demand is uneven. Variable capacity costs more per hour and less per year when work comes in waves, which is the case we lay out in variable cost structures and in our look at startup burn rate.
The cheapest work in any software project is the work you decide not to do, and the only reliable way to find it is a proper discovery phase.
There is a good illustration of this in another Reddit thread, where a founder described paying $3,750 to a development company to work out the technology, storyboard the product and produce a true cost of development.
The answer came back at roughly $65,000, more than the business could carry, so the idea was reshaped into something buildable. Anecdotal, but a clean example of the pattern: $3,750 bought the information that prevented a $65,000 mistake.
Drawn to the same scale, the two amounts barely belong on one chart.
We saw the same effect on a larger scale with iCopy, a medical records retrieval business. Before building the full platform, we produced a clickable prototype, which did double duty as the foundation for development and as a sales asset the company could put in front of customers.
That sequencing matters for cost. Validating demand with a prototype is dramatically cheaper than validating it with a finished product, and it meant the build that followed was aimed at something already known to work. iCopy's client volume subsequently rose 300%, and revenue grew tenfold within two years of launch.
The general lesson is not that prototypes are nice to have. It is that discovery is the one phase where a small amount of money changes a large number, because it is the only point at which cutting the wrong feature costs a conversation instead of a quarter. You can see how we structure that work on our product strategy page, or read the full iCopy project.
The single most common budgeting error is treating the build as the cost and launch as the finish line.
A more realistic frame: year one is the build plus a few months of operation. Years two and three are maintenance at 15% to 25% of build cost annually, plus hosting and tooling, plus whatever the roadmap demands once real users start telling you what is missing. Add it up and the three-year figure is often close to double the build quote.
Laid across three years, the quoted figure covers only the first of them.
Budgeting that way changes decisions in a useful direction. It makes a slightly more expensive build with better foundations look sensible, and it makes the cheapest possible build look like what it usually is, which is a loan against year two.
Calculating software development costs this way takes twenty minutes: run the worksheet, carry the range rather than the midpoint, and write your assumptions where someone else can read them. Then use the four GAO tests on any quote you receive, and ask specifically what is excluded rather than what is included, because the exclusions are where the surprises live.
If the number that comes out is bigger than your budget, the productive response is to cut scope and sequence for revenue, not to shop for a lower hourly rate. Cheaper hours on the same scope is the one adjustment that reliably costs more in the end.
If you want a second opinion on a scope or an estimate you already have, contact us. We will tell you where we think the number is soft, whether or not we end up building it. And if you are choosing between local firms, our roundup of Chicago app developers shows the going rates in one market.
There is no useful average, because the category spans a marketing site and a hospital scheduling system. What is portable is the method: labor is essentially the entire cost, so total the engineering weeks your scope requires, divide by about 0.6 to account for design, QA and project management, and multiply by a blended rate.
US firms commonly bill $150 to $199 an hour. A focused first release needing around 20 engineering weeks lands near $216,000 to $287,000, while a complete product at 47 engineering weeks reaches $474,000 to $629,000. Change the scope and that moves; change the rate and it barely does.
Estimate the range rather than the number, and be explicit that it is wide. Grade a rough feature list into simple, standard and complex, apply week ranges to each, then carry a band of plus 50% and minus 20% because you are working from a concept.
Then spend a small, fixed amount on discovery to narrow it. A paid scoping phase that costs low single-digit thousands routinely changes a six-figure decision, which makes it the best-value money in the project.
Fixed price transfers scope risk to the provider, which is not the same as removing it. Fixed-price quotes on vague requirements carry a risk premium of roughly 15% to 30% and are managed through change orders, so disputes move from the invoice to the scope document.
Fixed price works well when the work is genuinely well defined and someone has built something similar before. For anything exploratory, fix the price of discovery and use its output to fix the price of the build.
Cut scope, sequence for revenue, and buy the commodity parts instead of building them. Those three account for nearly all achievable savings. Test each feature against whether a paying customer would refuse to buy without it, ship the parts that let you charge money first, and use existing services for authentication, payments and search.
The lever to avoid is buying cheaper hours for the same scope. Work that takes longer, needs more supervision, or has to be rebuilt was never cheaper, it was just invoiced differently.
Ongoing engineering at 15% to 25% of build cost per year, cloud hosting and monitoring, third-party services that scale with usage, developer program fees for the app stores, and any compliance work your customers will require.
Include your own team's hours as well. Reviews, testing and decisions are real costs that never appear on an invoice, and leaving them out is the most common reason a budget that looked fine at signature feels tight by month three.
