How much does custom software cost? What really drives the price

Custom software cost is often the first thing business leaders ask about, and the topic that gets the vaguest answers. Two providers can send back very different quotes for what looks like the same need. That is not necessarily bad faith: in many cases, they have not estimated the same software.

You will not find a price list here: before scoping, only a rough ballpark is possible, and a firm price would be meaningless. Instead, this article explains what drives custom software development cost for a complete application, how a provider estimates it, where you can reasonably save and what happens after go-live.

The focus is on tools that run every day: business software, client portals, SaaS platforms. The first version of a product follows a different logic, covered in our article on what an MVP really costs.

What your money pays for

Custom software is not bought like a licence. What you mainly fund is skilled time: understanding your business, designing the user journeys, writing the code, testing it, putting it live, then keeping it running.

The cost comes in two parts. First the upfront investment, from scoping to go-live. Then the running costs, made up of hosting, third-party services, maintenance and new features. Budget only for the first, and the surprises will come from the second.

Do not judge the cost by the number of screens. A three-field form and a form that triggers calculations, checks and data exchanges with other tools look alike, but not on the invoice.

The visible factors: scope, business rules and design

Functional scope

How many features, for how many types of user. Each one needs design, development and testing, then maintenance for the whole life of the software. A feature added along the way generally costs more than it would have if planned from the start, because it has to fit around what already exists.

Business complexity

The rules of your business often weigh more than the features themselves. Take a haulage company. “Book a collection” sounds simple. But with rates that vary by zone and weight, limited slots per vehicle and sign-off above a certain volume, every case has to be handled in the code, then tested. The exceptions are what drive the cost.

Design and user experience

A back office used by a handful of trained staff does not have the same requirements as a client portal, which needs tested user journeys and a layout that works well on mobile. A plain interface built from reusable components costs less than one designed screen by screen.

The less visible factors that explain the gap

The difference between two quotes rarely comes from the screens. It comes from what happens behind them.

Integrations with your existing tools

ERP, CRM, accounting software, payment provider: each connection is a small project in its own right. The team has to understand the tool's API, handle errors, and deal with duplicates and data that does not match. With a well-documented API, the work goes quickly. An older tool with no API sometimes means exchanging files instead, which takes longer to build and to monitor.

Roles, permissions and data separation

A consulting firm that wants each consultant to see only their own files, partners to see everything and clients to have a limited area is already defining three permission levels. If the software serves several client companies from a single shared platform, as most SaaS products do, this is known as a multi-tenant architecture, and each company's data must be strictly isolated. That isolation is designed in from the start; adding it later costs far more.

Data volume and migration

Bringing across years of history from spreadsheets or an old system is never a simple copy and paste. The data has to be analysed, cleaned and de-duplicated, decisions have to be made about incomplete records, and the result has to be checked with your teams. Volume matters in production too: a search that is instant on a few thousand rows can slow down on several million, a problem covered in our article on PostgreSQL indexes and slow queries.

Security requirements

Customer, financial or confidential data calls for more safeguards: stronger authentication, encryption, individual accounts with logged access, tested backups, vulnerability reviews. These cost far less when planned at the design stage than when added after an incident.

Quality and testing

Automated tests check, with every change, that the behaviour they cover still works. They take real effort during development. Without them, every change becomes risky and the bill shifts to maintenance. On top of this comes user acceptance testing, where your teams validate the software against real cases.

Hosting and operations

In production, you need servers, a staging environment, monitoring and backups. Some services are billed by usage: sending emails or text messages, storage, calls to an AI model. These recurring costs belong in the budget from day one.

How a provider estimates custom software cost

A serious estimate usually follows four steps.

1. Understand the need: your business, the problem to solve, the tools already in place, the users, your deadlines.
2. Break the software down into features, then into tasks small enough to be estimated one by one.
3. Write down the assumptions, for example “the ERP has a documented API”. A written assumption does not prevent overruns, but it prevents misunderstandings: if it proves wrong, everyone can see why the estimate has moved.
4. Isolate the uncertainties: an integration nobody has tested yet or a rule that is still unclear justifies a margin, or a short discovery phase.

Before scoping, an estimate is therefore a range, which narrows as the scope becomes clearer. A precise quote delivered without a single question about your exceptions, your data and your tools should be a warning sign: what has not been examined has not been costed.

Fixed price or time and materials: who carries the risk

On a fixed-price contract, the price is set for a defined scope and the provider carries the risk of overruns. They will therefore scope tightly and price every change. On time and materials, you pay for the time spent: more flexibility, but closer oversight on your side.

What a quote should spell out

• the scope included, and what is explicitly excluded
• the assumptions made, especially about integrations and data migration
• the deliverables: code, documentation, access, environments
• who owns the source code and how it is handed over
• what happens after go-live

Cutting the budget without sacrificing what matters

You can reduce a budget by doing less, or by doing things less well. The first option is healthy. The second is paid for later.

• Deliver in stages. Start with the process that wastes the most time today. User feedback then shapes what comes next, and some features that seemed essential turn out to be secondary.
• Keep custom development for what sets you apart. Invoicing, messaging and online payments are well covered by off-the-shelf solutions, which your software can connect to. This reasoning is set out in more detail in our article on custom software versus off-the-shelf SaaS.
• Simplify before you automate. Every exception written into the code costs money to build, then to maintain. Check that each one is still genuinely needed.
• Prepare your side of the work. Data cleaned in advance and a point of contact available to make quick decisions reduce the time spent. Every decision that drags on lengthens the project without improving anything.

What you should not cut: security, tested backups, tests on the critical parts and adequate documentation. Their absence does not show at delivery. It shows at the first incident, or the first time you change provider.

Hidden costs: what happens after go-live

Software is never finished: it evolves at the pace of your business.

• Updates and corrective maintenance. Libraries evolve and vulnerabilities are discovered. Software that is never updated becomes fragile, then expensive to bring back up to standard.
• New features. A new sales channel, an internal reorganisation: the software has to keep up.
• User support. Questions, onboarding new staff, small day-to-day incidents: someone has to handle them.

Technical debt

Technical debt refers to the shortcuts taken during development: code written too quickly, missing tests, an architecture designed for a smaller need. It saves time in the moment and charges interest afterwards: every change takes longer, and fixing one problem can create others. A little debt is acceptable, provided it is known and paid down before it blocks the project.

The last hidden cost is dependency: undocumented code, or code whose ownership is unclear, ties you to whoever wrote it.

These costs can be planned for. An application maintenance and support arrangement lets you schedule them rather than handle them as emergencies.

Frequently asked questions

Can you get a price for custom software without a detailed specification?

A ballpark figure, yes. A reliable price, no. For a first conversation, it is enough to describe your business, the problem to solve, your current tools, the key features and your timeline. The precise estimate comes with scoping.

How do you compare two custom software quotes?

Compare what they cover before comparing their totals: the scope included and excluded, the assumptions about integrations and data migration, testing, documentation and what happens after go-live. A lower quote that leaves out data migration or testing does not remove those costs: it defers them.

Should you budget for software maintenance costs from the start?

Yes. Security updates, fixes and small improvements are inevitable. The right level depends on how critical the tool is and how quickly you want it to evolve.

Who owns the source code of custom software?

That depends on the contract. At Nuvaris, intellectual property and the handover of the code are set out in the commercial proposal and the contract before work begins, so that no ambiguity remains.

A budget is built, not guessed

Custom software cost depends less on the number of screens than on your business rules, your integrations, your data and your security requirements. A sound budget covers both building the software and running it. A sound quote makes its assumptions and exclusions visible.

For a rough idea of where your project stands, our project estimator gives an indicative ballpark in a few clicks. The precise estimate then comes from scoping: you can tell us about your project for a no-obligation first conversation.