TL;DR
- The average custom software project costs $132,480 and takes about 13 months (Clutch, 2026). Most small and mid-sized builds land between $30,000 and $100,000, large ones between $100,000 and $200,000, and enterprise systems above $200,000 (GoodFirms 2026, survey of 100+ software companies).
- Hourly rates run roughly $25 to $60 in South Asia and $125 to $250 in the United States. GoodFirms found 56.3% of surveyed software companies charge between $20 and $50 an hour.
- Two vendors quoting the identical project can differ by 200%, and the usual reason is the contract type, not the team. A fixed-price quote carries a risk premium a time-and-materials quote does not.
- A widely cited software research finding puts the share of custom software features that are never used at around 45%. On the average project that is roughly $60,000 of software nobody opens.
- Seat count, not feature count, decides whether a build was worth it. The same software can pay for itself in 14 months at 400 users and never pay for itself at 40.
If what you are building is a phone app rather than a business system, the arithmetic is different and feature count matters more than seat count. Our guide to app development cost runs that version.
How much does custom software development cost?
Between roughly $30,000 and $200,000 for most business systems, with the average project at $132,480 across about 13 months according to Clutch's 2026 data. GoodFirms' 2026 survey of more than 100 software companies puts small and medium projects at $30,000 to $100,000, large projects at $100,000 to $200,000, and enterprise systems above $200,000.
$132,480 over 13 months: the average custom software project (Clutch, 2026)
Two things to know before you treat that as your number.
First, "custom software" covers everything from a single internal tool that replaces a spreadsheet to a platform your entire business runs on. The range is wide because the category is wide, not because pricing is mysterious.
Second, and more useful: the price of any build is hours multiplied by hourly rate. Rates run roughly $25 to $60 an hour in South Asia and $125 to $250 in the United States. GoodFirms found 56.3% of the software companies it surveyed charge between $20 and $50 an hour. If a quote surprises you, one of those two numbers is different from what you assumed, and it is almost always the hours.
A few plain-English terms that will come up in any quote:
- Off-the-shelf or SaaS means software somebody else already built, which you rent monthly. Think of the tools you already pay for.
- Per-seat licence means you pay per person who uses it. Add a person, pay again, every month, forever.
- MVP stands for minimum viable product. The smallest version a real user would genuinely use, not a demo.
- Total cost of ownership means the build plus everything you spend keeping it alive afterwards.
What does custom software development cost by project size?
Custom software development cost splits into three tiers. Figures are 2026 US dollars, built from published rate bands, and assume design, development, testing and launch but not ongoing maintenance.
| Small internal tool | Mid-sized business system | Enterprise platform | |
|---|---|---|---|
| What it is | Replaces a spreadsheet or a manual process for one team | A system a department runs on, with integrations and user accounts | A platform the business runs on, with compliance and scale requirements |
| Users | Under 25 | 25 to 250 | 250+ |
| Integrations | 0 to 2 | 3 to 8 | 8+ |
| Rough hours | 400 to 900 | 1,200 to 3,000 | 4,000+ |
| Cost, South Asia team | $18,000 to $40,000 | $54,000 to $135,000 | $180,000+ |
| Cost, US team | $60,000 to $135,000 | $180,000 to $450,000 | $600,000+ |
| Typical timeline | 2 to 4 months | 6 to 13 months | 12 months+ |
| Off-the-shelf usually exists? | Almost always | Sometimes, partially | Rarely for the whole thing |
That last row is the one to read twice. For a small internal tool, something already exists that does 80% of the job for a monthly fee. That does not automatically make buying the right answer, but it does mean building should be a decision, not a default.
Why do two quotes for the same project differ by 200%?
Usually because of the contract type, not the team. The three common ways of buying software work are priced on completely different assumptions, and a fixed price carries a risk premium that an hourly arrangement does not.
| Fixed price | Time and materials | Dedicated team | |
|---|---|---|---|
| How it works | Agreed scope, agreed price | You pay for hours worked | You pay monthly for a team's time |
| Who carries the risk of it taking longer | The vendor | You | You |
| Typical price effect | 20% to 40% higher, because the vendor prices the risk | Lowest headline rate | Predictable monthly cost |
| Changing your mind | Expensive, requires a change order | Straightforward | Straightforward |
| Best for | Well-defined, small projects | Projects where the scope will move | Long-running work |
| Worst for | Anything you are still figuring out | Buyers who need budget certainty | Short projects |
So a fixed-price quote and a time-and-materials quote for the same brief will differ significantly, and neither vendor is being dishonest. Ask every vendor which model they have quoted before comparing two numbers. If they have quoted different models, you are not comparing prices, you are comparing risk positions.
The other reason for a wide spread is that vendors interpret vague briefs differently. A brief that says "a reporting dashboard" can mean four screens or forty. That gap is your responsibility, not theirs.
Should you build at all, or buy something off the shelf?
Buy, unless one of four things is true. This is the question a CFO will ask and the one most cost guides skip.
Build when the process is your advantage. If the way you do something is genuinely better than how competitors do it, off-the-shelf software will force you to work like everybody else. That is a real cost and it is worth paying to avoid.
Build when per-seat licences outgrow the build. Subscription software charges per person per month, forever, and the price usually rises annually. Past a certain number of users, buying costs more than building. The sum is in the next section.
Build when nothing exists that does the job. Some workflows are genuinely unusual. If you have looked properly and nothing fits, that settles it.
Build when you need to own the data or the connections. If a regulator, a client contract, or a data residency requirement means the information cannot sit on somebody else's servers, that narrows the options quickly.
Buy in every other case, and specifically:
- When your team is under 25 people and the tool is a common business function such as invoicing, support ticketing or scheduling.
- When you need it working in weeks rather than months.
- When nobody in the company will own the software after launch.
- When you cannot yet describe the process precisely enough to write it down. Automating a process you cannot describe produces expensive software that encodes the confusion.
A decision framework for this specific question is set out in custom software vs off-the-shelf.
The break-even calculation, run twice
This is the sum that decides it, and it takes about five minutes. It is deliberately unflattering to building in the first case and clearly favourable in the second, because both outcomes are real.
The method
- Find the closest off-the-shelf product and its per-user monthly price.
- Multiply by your user count, then by 12. That is your annual buy cost.
- Add 8% a year for licence price rises, which is a planning assumption, not a published rate.
- Against that, put the build cost plus 18% of the build per year for maintenance and hosting.
- Find the year the running totals cross.
Case one: a 40-person company
Off-the-shelf tool at $50 per user per month. Custom build quoted at $132,480, the Clutch 2026 average.
| Year | Buy, running total | Build, running total |
|---|---|---|
| 1 | $24,000 | $156,326 |
| 3 | $77,914 | $204,019 |
| 5 | $140,798 | $251,712 |
| 8 | $255,279 | $323,251 |
| 11 | $399,492 | $394,790 |
They do not cross until year 11, by which point the software would have been rebuilt at least once. For a 40-person company on a common business function, buying wins and it is not close.
The crossover moves fast with headcount, which is the whole point. On the same $50 seat price and the same build:
| Users | Crossover year |
|---|---|
| 40 | 11 |
| 60 | 7 |
| 80 | 5 |
| 100 | 4 |
Nothing about the software changed between those four rows. Only the number of people using it.
Case two: a 400-person company
Same build, same $132,480. Off-the-shelf tool at $80 per user per month, because enterprise tiers cost more per seat.
| Year | Buy, running total | Build, running total |
|---|---|---|
| 1 | $384,000 | $156,326 |
| 2 | $798,720 | $180,173 |
The build pays for itself inside the first year, and by year two buying costs more than four times as much.
Same software. Same invoice. Opposite answer. That is why seat count, not feature count, is the number that decides a custom software build.
Run this before you brief anyone. If the crossover is beyond year four, you are probably buying a preference rather than an investment, and you should be able to say out loud which of the four build reasons above applies.
Why is 45% of what you pay for never used?
Because scope is set by asking people what they want rather than by watching what they do. A widely cited software research finding puts the share of custom software features that are never used at roughly 45%. On a $132,480 average project, that is about $60,000 spent on software nobody opens.
~45%: the share of custom software features reported as never used (widely cited software industry research, originally published by the Standish Group; verify the current figure before quoting)
The mechanism is predictable. Requirements get gathered by asking every stakeholder what they need. Nobody says "nothing". Every request becomes a line in the specification, the specification becomes the quote, and the quote becomes the invoice. Nine months later, most of those lines are screens nobody visits.
Three ways to avoid paying for it:
- Ship the smallest version first. Build what 80% of users need every day, put it in front of them, and let real usage decide what comes next. This is the single biggest cost lever available to you, and it is larger than any discount you can negotiate.
- Make every feature name its user. If nobody can say which named person will use a feature weekly, it goes in a later phase.
- Measure usage after launch. Most teams never look. Software you can see nobody using is software you can stop maintaining.
Cutting scope by 30% saves 30% of the build cost and roughly 30% of maintenance every year afterwards. Negotiating 10% off an hourly rate does neither.
How do you cut the cost without cutting the software?
Four levers reduce custom software development cost, in order of how much they move the number.
1. Cut scope, not rate. Covered above. This is the biggest lever by a wide margin.
2. Phase it. Split the build into a first release you can use and a second phase you fund after the first proves useful. This also converts a large capital decision into two smaller ones, which is usually easier to approve.
3. Change where the team sits. Rates swing roughly five times between regions. That is real money, with two honest cautions: a lower rate multiplied by more hours is not a saving, and a large timezone gap slows down projects that are still deciding what they are.
4. Pick the right contract type. A fixed price on a well-defined small project is worth the premium for the certainty. A fixed price on something you are still figuring out means paying a risk premium and then paying again through change orders.
What does not meaningfully reduce cost: choosing a trendier technology, skipping the discovery phase, or skipping testing. The last two move cost from the build into the year after it, usually with interest.
What are the costs that appear after launch?
Custom software development cost does not stop at launch. Software is not a purchase, it is a subscription you pay yourself. Budget these from day one.
| Cost | Typical figure | Notes |
|---|---|---|
| Maintenance | 15% to 20% of build cost per year | Bug fixes, dependency updates, security patches |
| Hosting and infrastructure | $100 to $2,000+ per month | Scales with users and data |
| Third-party services | Varies | Payment processing, email, mapping, monitoring |
| Support for your own users | Staff time | Somebody has to answer "it is not working" |
| Technical debt | Invisible until it is not | Shortcuts taken during the build that make later changes slower and more expensive |
| Eventual rebuild | Every 5 to 8 years | Frameworks age, requirements change |
Technical debt is worth understanding because it is the cost that never appears in a quote. It means the shortcuts a team takes to hit a deadline, each of which makes the next change slightly harder. Enough of them and a change that should take two days takes two weeks. You do not see it on an invoice. You see it in every invoice afterwards.
Over five years, running costs commonly add 75% to 100% of the original build price. A plan that stops at launch is roughly half a plan.
What most teams get wrong about software budgets
Comparing quotes without comparing contract types. A 200% spread usually means someone quoted fixed price and someone quoted hourly. Ask first.
Approving the build without running the buy comparison. If nobody has done the break-even sum, nobody knows whether this was an investment or a preference.
Writing the brief in adjectives. "Modern", "intuitive" and "scalable" cost nothing to write and are impossible to quote. Screens, users, integrations and rules are quotable. Vague briefs produce wide quotes and then produce arguments.
Assuming the quote is the budget. Scope changes on every project, because seeing working software changes what you want from it. Hold 20% to 30% back rather than spending it in the first version.
Nobody owning it after launch. Custom software with no named owner degrades quietly. Dependencies go out of date, security patches get skipped, and the first real signal is an incident. The person who pays for this is whoever approved the original budget, because the fix arrives unplanned and priced accordingly.
Building because buying felt like giving up. This is a real and expensive motive, and it is worth naming. Off-the-shelf software is not a compromise. It is other people having already paid for your development.
How Euracle scopes and prices a build
The break-even sum above runs before the quote, not after it. That ordering is the method.
The Eureka Method, Euracle's discovery sprint, runs four phases.
Discover turns the brief into counted screens, named integrations and a user number, and runs the build-versus-buy comparison in writing.
Design decides the contract type on the evidence, recommending fixed price only where the scope is genuinely settled.
Deploy ships the smallest useful version first rather than the full specification.
Scale measures which features are actually used and retires the ones that are not, which is where the 45% problem gets addressed rather than discussed.
The stack is deliberately conventional: Next.js and TypeScript on the front, PostgreSQL for data, AWS and Docker for infrastructure, and connections into whatever already exists such as HubSpot or Salesforce. Conventional choices are cheaper to maintain and easier to hand to somebody else, which matters more over five years than anything novel does.
Two structural commitments come from how Euracle is set up. Senior practitioners only: the people in the pitch do the work, with no junior layer and no subcontracting, which matters most on the estimating conversation where inexperience shows up as hours on your invoice. And one contract across six disciplines, so a discovery finding that the real answer is an off-the-shelf tool plus some automation does not require starting again with a different vendor. Across 50+ projects shipped for 100+ B2B teams in 12 countries, Euracle targets under 90 days from kickoff to first measurable result, and has held 98% client retention over 3 years.
If you want the break-even run and the scope counted before anyone quotes you, that is Euracle's web and software development service. The build-versus-buy question is sharpest for B2B SaaS companies, where the internal tooling decision competes directly with the product roadmap for the same engineers.
FAQ
Conclusion
You can now do the two calculations that matter: hours multiplied by rate to sanity-check any quote, and the build-versus-buy crossover to decide whether the quote is worth accepting at all. If the crossover lands beyond year four, be able to name which of the four build reasons applies, because otherwise you are buying a preference. And before signing anything, ask every vendor which contract type they quoted, since that alone explains most of a 200% spread. If you want the break-even run and the scope counted before anyone quotes you, talk to Euracle about custom software development.
Sources
- Clutch, Software Development Company Pricing Guide, updated April 2026. Average project cost of $132,480 over approximately 13 months; hourly rates $25 to $149 by region.
- GoodFirms, 2026 research covering more than 100 software companies. Project bands of $30,000 to $100,000, $100,000 to $200,000 and $200,000+; 56.3% of surveyed companies charging $20 to $50 per hour.
- Regional senior developer rate bands, 2026: United States $125 to $250, United Kingdom $100 to $180, Central and Eastern Europe $40 to $95, South Asia $25 to $60.
- US Bureau of Labor Statistics, median annual wage for software developers of $133,080, giving roughly $64 an hour in fully loaded in-house cost.
- Standish Group, finding that approximately 45% of features in custom software are never used.
