How Much Does Custom Software Cost in 2026?

Price is the first question almost every buyer asks, and the one most vendors dodge. The honest answer depends on scope, but you can estimate a sensible range yourself before you speak to anyone. This guide gives you the arithmetic, the factors that move it, and the costs that tend to surprise people after the contract is signed.

The formula behind every quote

Strip away the proposal formatting and every software estimate reduces to three numbers: the people on the team, the weeks they work, and their rate.

A typical product team combines a product lead, a designer, two or three engineers and part-time quality assurance. Four people working for twelve weeks is 48 person-weeks. Multiply that by the blended weekly rate of the team you are considering and you have a first estimate.

Rates vary widely by country, seniority and company size, so compare person-weeks between proposals before you compare totals. A proposal with a low total and an implausibly small number of person-weeks is usually a proposal that has left something out.

Five factors that move the number

The same app idea can cost three times as much in one company as another. The difference nearly always comes from these five factors.

Integrations deserve extra attention. Connecting to a well-documented service such as Stripe takes days. Connecting to a twenty-year-old ERP with no API can take weeks, and you rarely discover the difference until someone opens the documentation.

Typical project shapes

Budgets in money date quickly and differ by market. Team size and duration travel better, so here are the shapes we see most often. Treat them as planning ranges, not quotes.

Apply your expected weekly rate to these shapes and you will know whether your budget matches your ambition. If it does not, reduce the scope rather than looking for a cheaper team to build the same scope. Cheap estimates for large scopes tend to grow once work begins.

The costs people forget

The build is the largest line, but a few smaller ones catch buyers out.

• Discovery. A week or two of workshops, research and technical planning before development starts. It saves far more than it costs, because it catches misunderstandings while they are still cheap to fix.
• Infrastructure. Hosting, databases, storage and monitoring. Modest at launch, and growing with usage.
• Third-party services. Maps, SMS, email delivery, AI model usage and payment fees carry their own pricing, often per transaction.
• App store accounts. Apple and Google both charge developer account fees, and Apple's renews every year.
• Data migration. Moving and cleaning records from spreadsheets or old systems takes planning and testing.
• Training. Your team needs time to learn the new system, and someone has to write the guides.
• Maintenance. A common planning figure is 15 to 20 per cent of the original build cost per year, covering updates, security patches and small improvements. Our guide to software maintenance after launch explains what that money buys.

Where projects overspend

Overspending rarely comes from one bad decision. It builds up from a handful of habits.

Building features nobody uses. Teams add "nice to have" features to the first release because they fear they will not get another chance. Launch with the core, measure what customers do, and fund the next release from evidence.

Changing direction without a change process. Changing requirements is normal. Changing them informally, in a hallway conversation, turns a fixed budget into an open one. Agree every scope change in writing, with its effect on time and cost, before the team starts on it.

Choosing the lowest bid. A proposal priced well below the others usually assumes less testing, less senior staff or a narrower reading of the scope. You pay the difference later, often twice.

Underestimating integrations and data. Ask for these to be investigated during discovery rather than estimated from a paragraph in a brief.

How to get an accurate estimate

You will get better estimates if you give vendors better information. Before your first conversation, write down:

1. The business outcome you want, in numbers where possible.
2. The people who will use the software, and the main task each of them needs to complete.
3. The systems it must connect to.
4. Any regulatory or data residency requirements.
5. Your deadline, and the reason behind it.
6. A budget range.

Sharing a budget range feels risky, but it helps a good partner propose the right scope instead of guessing. A partner who knows you have a budget for a focused first version will design one. Without a range, you receive proposals for three different products that you cannot compare.

Finally, look for a partner who suggests a short discovery phase before committing to a fixed price. An estimate made after a week of genuine investigation is worth far more than one produced from a two-page brief. If you are weighing up contract types, our comparison of fixed price and time and materials covers how each one shares the risk.

When you are ready for a real number, tell us about your project. We will reply with questions within one business day and send a written, fixed-price proposal after a short discovery call.