What custom software really costs, and where the money goes

The most uncomfortable thing about buying software is that you cannot inspect it before it exists. You are asked to commit a significant sum based on a document and a conversation, and the difference between a good supplier and a poor one only becomes visible much later.

Why quotes vary so wildly

When a business sends the same brief to four companies and receives figures that differ by a factor of five, the natural conclusion is that somebody is overcharging. Usually the real explanation is that they are quoting for different things.

The cheapest quote often assumes a template with your content dropped into it, or a junior developer working alone, or an offshore team you will manage yourself. It may exclude hosting, security, testing on real devices, data migration, training and any support after launch. It probably assumes your requirements are exactly as described in one paragraph, which they never are.

The most expensive quote might include a formal discovery phase, several people, a documented architecture, a testing process, deployment infrastructure and a year of support. Or it might include an agency overhead structure that has nothing to do with your project. Both are possible and the document rarely tells you which.

The useful response is not to pick the middle number. It is to ask four questions of every supplier. What is excluded from this price. Who exactly writes the code and where are they. What does the second year cost. What happens if we need an urgent change six months from now. Those answers separate proposals far more reliably than the headline figure.

Where the money actually goes

People assume most of a software budget is spent writing code. In practice, on a well run project, coding is perhaps half. The rest goes into understanding the problem, designing the data, testing, deploying, migrating existing information, training and fixing the things that only appear once real people use it.

The stage that produces the most value for the least money is the specification. A written document describing every screen, rule and report costs a small fraction of the build and routinely prevents months of rework. Projects that skip it do not save the money, they simply spend it later at a worse exchange rate, because changing a built system costs far more than changing a document.

The stage most commonly underestimated is data migration. Moving records out of spreadsheets or an older system sounds trivial and never is, because real data contains duplicates, inconsistent spellings, three date formats and notes typed into the wrong column. Any quote that does not mention migration when you have existing data has either overlooked it or is planning to raise it as a change request later.

The decisions that save the most money

The single largest saving available is building less. Most first specifications contain a substantial proportion of features that sound essential in a meeting and are never used. Cutting the first version back to the workflow that genuinely matters, putting it into real use and then deciding what to add based on evidence, consistently produces better software for less money.

The second largest saving is prompt decisions. Projects rarely slow down because the work is technically hard. They slow down because a question sits unanswered for eleven days while it waits for somebody who is travelling. Appointing one person with authority to decide is worth more to a schedule than any technical choice.

The third is being honest about your process during discovery, including the awkward exceptions. Every exception discovered after the data model is built is expensive. Every exception mentioned in week one is free.

The fourth, and the one clients find hardest, is not buying custom software at all when an established product would do. If a product covers most of your requirements for a fraction of the cost, buying it and configuring it properly is the better decision. Any supplier who never recommends this is not advising you.

The costs that appear afterwards

Software has a running cost and it is frequently omitted from the comparison entirely. Hosting. Domain renewal. Payment provider fees. Email and message delivery services. Developer account fees if there are mobile applications. Maintenance covering security updates, backups and small changes. Support when something breaks.

None of these is large individually, and together they matter. A supplier who cannot tell you what year two costs has probably not thought about your system beyond launch day, which is itself useful information about how the relationship will go.

A realistic sense of scale

Without knowing your requirements, nobody can give you a figure honestly. What we can offer is the shape of the ranges. A business website is a matter of weeks. A content managed site with many sections is longer. A web application with accounts, permissions, workflow and reporting is a few months of work and priced accordingly. A platform with a web system and two native mobile applications is a substantially larger undertaking, typically six to ten months.

The pattern worth understanding is that cost scales with rules rather than with screens. Ten simple pages are cheap. One screen with fourteen conditional rules, three user roles and an audit requirement is not. When you are describing your project, the complexity lives in the rules.

What we do about it

We quote in stages, each described in plain language and priced separately, with assumptions and exclusions stated explicitly. That lets you start smaller, see something working, and decide whether to continue rather than committing an entire budget to a document. It also makes the expensive parts visible, which almost always produces a better conversation about what is genuinely needed.