What custom software costs, and what moves the number

A software estimate is a statement about scope, standard and speed. Change any one of the three and the number moves, often by more than people expect. Understanding which of the three a quote assumes is what turns a confusing spread of proposals into a decision you can defend.

The figures below are ranges we see across our own engagements and the wider market for senior European delivery in 2026. They are here to give you a frame for a first conversation, and every one of them moves with the specifics of the work.

What actually sits inside an estimate

A build is usually quoted as a single number, and inside it are five very different kinds of work. When two quotes diverge sharply, the difference is nearly always in the last three.

A quote that comes in at a third of another one is often quoting only the middle row. That can be the right choice for a prototype whose job is to win a funding round. It is an expensive choice for a product that will carry customer data next year, because the remaining rows arrive later at full price and with the work already built around their absence.

Ranges by project shape

These are end-to-end figures for a senior team delivering production software: design, build, test, deploy, and a working handover.

Two of our own engagements give the ends of that spread some texture. A consumer SaaS platform we took from an empty repository to mass adoption represented a single build over $166,000, spread across web, native mobile, an AR experience and more than ten social integrations. At the other end, a finance ERP automation reduced the manual work in a department by around 80% and paid for itself inside a year.

The five decisions that move the number most

1. How much of the product is genuinely new

Authentication, billing, notifications, admin panels, file handling and search are solved problems with mature building blocks. The distinctive part of your product is the part that costs. A good vendor will tell you which of your requirements fall into which category on the first call, and that conversation alone often moves an estimate by 20%.

2. The systems you are connecting to

An integration with a modern, documented API is a known quantity. An integration with a fifteen-year-old ERP whose documentation is a person is a discovery exercise with a build attached. When we quote work touching an existing system, the honest structure is a short paid discovery first and a firm number after it — anyone quoting a fixed price for an unexamined integration is pricing in a large risk premium, and you are paying for it either way.

3. The standard you need

A tool used by eleven people inside your company and a platform holding banking data are different disciplines. Audit trails, encryption at rest, penetration testing, role models, data residency and formal review all cost real money. For the UAE bank onboarding flow we built, that layer was a substantial share of the work — and it was the reason the work was possible at all.

4. How fast you want it

Compression has a price. Adding people to a project adds coordination, and past a certain point the fourth engineer produces less than the third. The efficient way to buy speed is to reduce the scope of the first release rather than to enlarge the team, and a vendor who suggests that unprompted is worth listening to.

5. What happens after launch

Software that is used is software that changes. A realistic annual figure for keeping a live product healthy — dependency updates, infrastructure, monitoring, small improvements, the occasional fix — is 15–25% of the original build. Budgeting it from the start is what keeps the second year from feeling like a surprise.

Where AI leverage changes the arithmetic

Used with discipline, AI tooling compresses the parts of engineering that are mechanical: scaffolding, test writing, migrations, documentation, reading unfamiliar code. It leaves untouched the parts that are judgment: architecture, data modelling, security, and deciding what to build.

The clearest measurement we have is a rewrite of a fourteen-year-old Go backend into Node.js, delivered in six months by one senior engineer where the conventional estimate was around two years. The saving came from the reading and translation work, not from lowering the standard — every change went through specification, review, security checks and tests exactly as it would have otherwise.

What this means for a budget is straightforward: for work with a large mechanical component — modernisation, migrations, broad test coverage, documentation of an inherited system — expect a materially lower number from a team using these tools well. For work that is mostly new product thinking, expect the number to look much as it always did.

Comparing two quotes that differ by a factor of three

Ask each vendor for four things. The comparison usually resolves itself in an afternoon.

1. The assumption list. What is included, what is excluded, and what has been assumed about the systems they will connect to.
2. The split. The five components above, with a number against each. A vendor who cannot split their own estimate has not built one.
3. The first milestone. What is running, on a URL, and by when.
4. The year-two figure. What keeping this alive costs after launch.

A cheaper quote that includes all four is genuinely cheaper. A cheaper quote that includes one of them is a smaller scope wearing the same name.

Ways to spend less without lowering the standard

• Cut the first release, keep the architecture. Build the full shape of the system and ship a narrow slice of it. The expensive mistake is the reverse: a wide feature set on foundations that need replacing in a year.
• Buy the commodity parts. Payments, authentication, email, search and analytics all have mature services behind them. Custom versions of these rarely repay their cost.
• Start with a paid diagnostic. Where an existing system is involved, a fixed-price code and developer audit replaces a large unknown with a written plan, and every subsequent estimate gets tighter.
• Keep one team for longer. Handover between vendors is the most reliably wasted money in this industry. Many of our clients have stayed with the same engineers for seven years and more, and the compounding familiarity shows up directly in delivery speed.
• Decide quickly on small things. A blocked decision costs a team more than most people imagine. A named decision-maker with a two-day turnaround is worth several per cent of the budget.

A note on hourly rates

Rates are the least useful number in a comparison, because they say nothing about how many hours the work will take. A senior European team at a higher rate that delivers in four months is cheaper than a junior team at half the rate that delivers in nine and hands over a system needing rework. Compare total cost of the outcome, the standard included in it, and the year-two figure. The hourly rate is an input, and not the one that decides the total.