Custom software development cost: why 46 companies disagreed on one brief

One brief, 46 companies

There is an experiment anyone buying custom software should read before opening a quote. Researchers at the Simula Research Laboratory in Norway paid 46 outsourcing companies in Eastern Europe and East Asia to estimate the effort for the same five software projects. The companies worked from the same written requirements, and the researchers published the spread of every estimate.

(opens full size in a new tab)

Read the right-hand column first. With the outliers set aside, the middle half of the companies still disagreed by a factor of about two on every system. The middle column shows the full range. For each system, the highest estimate was between fourteen and sixty-four times the lowest, for identical written requirements.

The paper states two caveats. First, the table pools companies that received the original specification with companies that received a lightly altered one. For four of the five systems, the specification was either unaltered or the change made little measurable difference. Second, the companies were told they would be judged on the quality of their estimation, not on price. The authors expect that made them steadier than bidders in a real tender, so a real procurement is unlikely to be tidier.

When quotes for one system come back far apart, buyers usually assume the high bidders are padding and the low one is hungry. The experiment points to a duller cause.

Each vendor reads the same brief and fills its gaps differently. One assumes the data migration is clean and another assumes it is not. One prices three integrations as simple file exports. Another prices them as fragile boundaries that someone else owns and may change. Each quote is a price for that vendor’s picture of your system.

This is why custom software has no market price. The price belongs to a scope: which workflows, for which people, connected to which systems, carrying which data, held to which security and uptime standards. Change one of those and the number moves. Two briefs written in the same words can differ in all of them.

We are a custom software development company, so we send quotes like these ourselves. We do not publish our own prices. The figures below are other people’s published data. The evidence about quotes comes from independent research, not from our projects.

What custom software development costs in 2026

By Clutch’s 2026 data, the typical custom software project costs 10,000 to 49,000 US dollars and the average costs 132,480 US dollars. Those figures cover projects of every size, so neither one is a budget for yours. Clutch, the review platform, publishes that pricing from the software projects its clients review, in a guide updated on September 21, 2026.

The average project in that guide ran for about 13 months, which Clutch gives as roughly 10,209 dollars a month.

Look at the gap between the typical band and the average. The average is nearly three times the top of the typical band, which means a small number of very large projects is pulling it up. Most reviewed projects are small.

These figures have two limits. They come from projects that clients chose to review, which tilts them toward smaller work. And a band of project costs tells you what other people bought. It cannot tell you what your scope needs.

We use Clutch’s figures and not the ranges vendors publish, and Google’s first page for “custom software development cost” shows why. On October 10, 2026 it held nine pages, and seven of them opened. Six of the seven were published by companies that sell software development. The seventh was Clutch’s own pricing guide, the data used above.

Six of the seven published project cost figures, from 10,000 US dollars to more than 2 million on one vendor page, a factor of 200. Of the five vendor pages with figures, three quoted Clutch’s average, and two named no source beyond their own experience or an assumed hourly rate. None of the seven cited research on why quotes for the same brief differ, which is the question buyers bring.

What moves a system above the typical band is its scope, and scope grows with the number of people who depend on the system. Vendors charging large clients more is not the reason. The reason is what a system has to do once more than a handful of people depend on it.

Sign-in runs through the company’s single sign-on, not a password table. The system exchanges data with an ERP, a CRM, a finance package and an identity provider, each owned by a different team. Years of records have to move across from whatever ran before. Auditors want to know who changed what and when. There are several kinds of user with different permissions, and an administration side for whoever operates the system. Someone has to be on call to meet the uptime expectation.

None of that shows on the screens in the brief. Every line of it is design, build and testing. A small project fits the typical band because it has almost none of this. Count how much of it yours has.

Before you budget for any of it, check whether you should build at all. If a mature product already covers the process, configure it and pay nothing for custom software. The build vs buy guide covers where the line between the two usually falls, and what both sides tend to forget. If the process is still changing, wait. Building it now fixes the wrong shape in code, and you pay a second time to change it.

Developer hourly rates, and why they decide less than you think

Software development companies charge 25 to 49 US dollars an hour on average, by Clutch’s 2026 data. That rate decides less of your total than the size of the team and the number of weeks.

Clutch’s table by country shows how far the rate moves. It gives 25 to 49 dollars in India, the Philippines, Ukraine, Spain and Mexico. The United States and Poland sit at 50 to 99, and Canada and Australia at 100 to 149. It publishes no figure for the United Kingdom. These are market data, not our prices.

Building in house has its own price. The US Bureau of Labor Statistics put the median pay for software developers at 135,980 US dollars a year in May 2025. For developers, quality assurance analysts and testers combined, the median was 64.44 dollars an hour. Both are before benefits, equipment, management and the time it takes to hire.

Underneath, a quote is people multiplied by weeks multiplied by a rate. Here is a worked example, for illustration only. Five people for nine months at 40 dollars an hour is about 5 × 39 weeks × 40 hours × 40 dollars, or roughly 312,000 US dollars. Cut the team in half and the number halves. Double the rate and it doubles. Add three months because the data migration was messier than anyone assumed, and it grows by a third.

The rate is the easiest number to compare, and it matters least. Fred Brooks put coding in proportion in 1975. His rule of thumb for scheduling a software task gave one third of the time to planning, one sixth to coding and half to testing. Tools have changed those ratios since. Comparing vendors on the price of an engineering hour still compares the smallest part of the work.

The total moves with the number of people and the number of weeks. Both are decided by the scope each vendor thinks it is pricing.

What actually decides the cost

A handful of scope decisions decide the cost of custom software development. They are users and workflows, integrations, data migration, security and uptime, platforms, what is out of scope, and who runs the system after launch. Most of them are invisible in a brief that describes screens. The table below lists the lines where we see quotes for the same system split. It also says what to write in your brief so every vendor prices the same thing.

Give integration and data the most scrutiny. Their real size is the hardest to know when a quote is written, so they are the two lines most easily priced as a vague allowance, and the two most likely to grow once the build starts. The reasons are set out in the two lines that decide whether an ERP number holds. They behave the same way in any custom build.

How you pay is one more decision that belongs here. A fixed price is only as safe as the scope behind it. On a vague brief it moves the risk into change requests. On a scoped boundary, with exclusions and change pricing in writing, it is a fair way to buy.

Time and materials fits work that is still changing. It needs a clear backlog, regular demos and a person on your side who sets the order of work. A common arrangement is a fixed price for discovery, then time and materials once the scope is settled.

That person matters more than the payment model. A brief needs someone authorized to decide what is in it. If no one on your side can own the scope, no quote will hold.

Your brief is already moving the number

A budget, a deadline or even the word simple in your brief pulls estimates toward it without changing the work. Estimators anchor, and most do not notice. Magne Jørgensen’s 2014 review of the estimation research names the strongest influence. When the people estimating know the client’s budget, expectations or available time, their estimates drift toward those numbers.

Loaded wording does it too. Describing the work as a small and simple project pulls estimates down.

The experiment with the 46 companies measured one of these effects. Half of the companies estimating one system were told the client expected it built in three weeks. That should have raised their estimates, because squeezing a schedule adds coordination and removes no work. Their median came in about a third lower instead. The four companies that had built that system before had used more effort than most of the estimates.

Two other anchors were tested in the field: a shorter version of the same specification, and a note about the client’s low cost expectations. Both moved the median the same way, but by less than laboratory studies had found. The deadline was the one effect that held its full strength outside the lab.

Three habits follow from that, and none of them costs you anything. First, ask for estimates before you share a budget. Once each vendor has priced the work, use the budget to discuss what to build first.

Second, state your deadline as the date the business needs something, and ask each vendor what they would leave out to meet it. That stops the deadline shrinking the estimate unseen. Third, take loaded words out of the brief. Describe what the system must do, and leave out how small it should feel.

The lowest quote needs the most explanation

The lowest quote is the one most likely to be an underestimate, because bidding rewards optimism. Across the research on software estimation, projects overrun their effort estimates by around 30 percent on average. Jørgensen’s review also found that accuracy had barely changed since the 1980s, despite decades of work on estimation models.

The same review says where the optimism gathers. Underestimation is particularly present in price-competitive situations such as bidding rounds. In-house teams estimating their own work show no such tendency.

That is uncomfortable if you are running a tender. When a buyer chooses on price, the proposals most likely to win are the ones that underestimated the work. Jørgensen names it the winner’s curse, and names two consequences, cost overruns and lower software quality. The price you signed then becomes the opening position in a negotiation.

The overrun tends to arrive in familiar ways. Change requests appear for things that were never in the vendor’s picture. The quality bar is lowered to protect the margin. The team is rotated toward better-paying work. The ERP cost article shows what the largest overruns look like, and the mechanism in a custom build is the same.

None of this makes the highest quote right. The lowest one needs the most explanation before you believe it. Price is also only one of the three tests that separate vendors, and it is not the most telling one.

A project where the scope was settled one step at a time

On one of our projects, the scope was narrowed in stages, and each stage was cheaper to change than the one after it. A consulting firm in Munich was opening a business conference and event venue and needed web services to present the venue and to manage it. It was a modest project, far from the systems this article is mostly about. That makes every step easy to see.

The work began with three mockups, so the firm could choose a direction by comparing them. A prototype came next. In short one-to-one sessions the firm then added its ideas to the prototype, before any of them was in code. Only after that did the five developers on the project move to responsive optimization.

The order mattered. New ideas arrive on every project. Here they arrived while adding one took a conversation and no change request. The review does not describe the budget, so we claim nothing about it. It does say that the firm was a repeat client, that an earlier project with us had gone well, and that a business partner had recommended us. We have published the project as the conference venue website case study.

Our other reviews show the same pattern. On October 9, 2026 we counted across the 15 reviews clients have left us on Clutch. Three describe how the work was scoped, and all three had the scope and the cost settled in discovery before the build. Three describe the brief changing across review rounds. Six of the 15 include a criticism, and none of the six is about price.

One asks for more frequent updates, a clearer timeline per stage and more explanation of design decisions. The others ask for a validation step at milestones, more early sketches, more creativity and, in two reviews, closer attention to detail. Every criticism is about how the work was run.

A system for a large organization has far more to settle, including the integrations, the data, the roles and the audit trail. The principle is the same at any size. A decision made on paper does not have to be made again in code. It also leaves one fewer place for 46 companies, or five, to imagine different systems.

The questions that explain the gap between two quotes

When two quotes for the same brief are far apart, look for the difference in seven places. Put all seven questions to every vendor in writing, and lay the answers side by side.

1. What did you assume is out of scope? Ask for the exclusions as a list. A lower quote often leaves out something the higher one included.
2. Which integrations did you price, and how? System by system, named, with the assumption behind each: a file export, an API, or a boundary someone else owns and may change.
3. What did you assume about our data? Clean or not, how much of it, and who fixes it when it turns out not to be.
4. How much contingency is in the number, and where? A quote with no stated contingency has either hidden it or left it out. Find out which before you sign.
5. Who is on the team, at what seniority, and for how long? Named roles and their time on the project. Two quotes can price the same hours for very different people.
6. What happens to the price when the scope changes? How a change is priced tells you whether change requests are an exception or the business model.
7. What is included after launch? Warranty, support, hosting, and the handover of code and documentation. Quotes differ most on what they leave out here.

Two of these, contingency and change pricing, are the quickest way to spot the winner’s curse before you sign. An optimistic bidder has either no contingency at all or a change clause that expects to recover it.

Treat “assumed to exist already” as an answer in its own right. When a vendor assumes your systems expose clean APIs, or that someone else will move the data, that work has not been priced lower. It is missing from the quote.

Here is how that looks on one line of a quote, as an illustration and not a client’s project. Two vendors price the same integration with your CRM. The first assumes the CRM hands over clean customer records, and prices the connection alone. The second has asked to see a sample export. Its price includes matching duplicate customers, a trial migration and a reconciliation report showing that the counts agree on both sides.

The second quote is higher on that line, and the difference is work and not rate. Before you decide which is cheaper, ask the first vendor to price the same work, or to say in writing who does it.

If you already have quotes that sit far apart, send us the brief together with the quotes. Give the engineers who would build the system 30 minutes on a call. They will tell you which of the seven questions each quote leaves open, and what they would want settled before giving a number of their own. You get that answer even if you never ask us for a quote.