What drives the cost of custom software

“How much will this software cost?” is the question we are asked most often. The answer is not a single figure, and saying so sounds evasive. It is not. A figure given without knowing the items that drive the cost is either higher than it needs to be or will rise halfway through the project.

In this post I explain which items drive the cost of custom software and what to look for when reading a proposal. I don’t give figures, because every project is different. But seeing where the figure comes from makes comparing proposals much easier.

The number of screens is a misleading measure

Software cost is often thought of in terms of screens. A login screen, a list, a form, a report. But screens are the visible part of the cost.

Two forms that look the same can cost very different amounts. One writes the entered data to a table. The other validates the same data, shows it to different people depending on their permissions, sends it to another system and logs every change. The rules behind the screen drive the cost.

Integrations

Software rarely works on its own. An accounting system, authentication, payments, email, the organisation’s old systems or a public service. Every connection is a separate piece of work.

Connecting to a well-documented service with a solid interface can take a few days. Connecting to an old system with patchy documentation and no test environment can take weeks. Asking about the documentation and test access for each integration at the proposal stage clarifies the most uncertain part of the cost.

Data and migration

If the new software does not start with an empty database, data will have to be migrated from the old system. Most proposals cover this in a single line, and it becomes one of the places where projects most often overrun. We explain why in our post on data migration.

Security and regulation

Software that processes health data, student data or financial data needs more work than an internal tool that looks the same. Role-based access, access logs, encryption, enforcing retention periods, deletion and anonymisation. These are hard to add later. Bringing them into scope from the start is both cheaper and safer.

Uncertainty

Every project has unknowns. A good proposal lists them separately and says how they will be handled. A bad proposal either quietly adds the uncertainty to the price or does not account for it at all. The second is more dangerous, because the difference turns up halfway through the project as an extra invoice.

The best way to reduce uncertainty is to put a short discovery phase at the start of the project. In this phase the scope, integrations and data become clear. The main development is then priced with a more solid figure.

Testing and acceptance

Testing is the item most likely to be cut. When it is cut, it is also the item whose price is paid last. Automated tests, acceptance tests and trials with real users. If the effort set aside for testing is not visible in the proposal, that effort will either never be spent or will fall on your own team.

After delivery

The cost of software does not end on delivery day. Hosting, backups, security updates, upgrades to the libraries used and small improvements carry on. Seeing these items separately at the proposal stage means no surprises at the end of the first year.

When reading a proposal

When comparing several proposals, write down side by side what each one covers. Are integrations included, is data migration included, how much testing is there, how is maintenance priced, who keeps the source code? Most price differences show that the same work is not being priced.

In short

The cost of custom software is driven not by screens but by the rules behind them, integrations, data, security, testing and maintenance. A proposal that spells out these items, even if it looks higher, often turns out cheaper.