The honest answer to how much custom software costs is that nobody can tell you from a description, and anybody who does has priced something other than your project. That is not evasion. It is the reason the same brief, sent to three companies, comes back at twelve thousand, forty thousand and a hundred and ten thousand. All three read the same document. All three numbers can be defensible. What varies is what each one assumed, and none of them wrote the assumptions down.
So rather than a range that would be useless, here is what the number is actually made of, and how to get one you can rely on.
The six things that move the price
Almost all of the spread between quotes comes from these.
How many kinds of user there are. One type of user is a product. Four types with different permissions, an admin view and a client who must see only their own records is a different product that sounds identical in a brief. Every additional role multiplies screens, rules and testing.
What it has to connect to. Integrations are where estimates die. The phrase"it has an API" covers everything from an afternoon to two months, depending on whether the documentation is accurate, whether there is a test environment, and whether the other side has a support contact who answers. Accounting systems, payment providers, government portals and anything internal built before 2015should all be assumed to be worse than described until somebody has looked.
Where the data is coming from. If the information lives in spreadsheets, inboxes and one person's memory, the migration is a real piece of work with areal cost. It is also the part most often left out of a quote, because it is invisible in a brief that describes screens.
What happens when it is wrong. A tool used internally by six people and a system that touches money, patient records or a regulator are not the same build, even when the interfaces look the same. Consequence drives how much testing, review and audit trail the thing needs, and that is not optional padding.
Whether it replaces something. Replacing an existing system almost always costs more than starting clean, because the old behaviour has to keep working while the new one arrives, and because nobody has a complete list of what the old one does.
Who is responsible after launch. A price for delivery and a price for a working system that somebody maintains are different purchases. They look identical on a one page PDF.
If a quote arrived without anybody asking about most of that list, the number was not calculated. It was recalled from a project that sounded similar.
Why the cheapest quote is often the most expensive
A low number usually encodes one of three things.
Work left out, which returns as change requests once an upfront has cleared and the leverage has moved. Quality left out, which returns as defects, usually in the month after launch when attention has already moved on. Or an assumption that the gap will not be noticed until it is too late to change supplier.
This is not always true. Sometimes a small team with a genuinely narrower scope is the right answer and the expensive quote is a large firm staffing a bench.The way to tell them apart is not to negotiate the price. It is to establish whether the cheap quote got cheaper because the scope was smaller or because the scope was vaguer.
A smaller scope is a real saving. A vaguer scope is a deferred bill.
The most valuable page in any proposal
It is the one listing what is not included, and most proposals do not have it.
Almost every software project that ends badly started with a price agreed before anyone understood what was being built, and finished with two parties arguing about whether something was in scope. Nobody is lying in that argument. Both sides agreed to different things and did not find out for four months.
An explicit exclusions list is uncomfortable to read. That discomfort is the point: it happens now, in a document, rather than later, in an invoice dispute.
Five questions that make different quotes comparable
Ask every vendor the same five. The numbers stop looking arbitrary almost immediately.
1.What did you assume to produce this figure? A real answer names specific assumptions about users, integrations and data volumes.
2.What is explicitly not included? If nothing is, everything is negotiable later, and the renegotiation will not happen at a convenient moment.
3.What happens if the scope turns out to be bigger than both of us thought? Ask who absorbs it, and ask before signing, because the answer changes once money has changed hands.
4.What do I own at the end? Code, infrastructure, accounts, domains and documentation. If any of those stay with the supplier, the system is rented, and the exit price is whatever they decide on the day you want to leave.
5.Who is accountable for quality after launch, and for how long?
A one page brief you can send to everybody
The fastest way to a reliable price is to make the work cheaper to understand.An afternoon spent on the following turns every quote from a guess into anestimate, and it costs nothing. Copy the headings, fill in what is known, andsend the identical document to each vendor.
1. The problem, in numbers. What this costs today in hours, errors, lostsales or staff time. One line. If there is no number, that is worth knowing before spending anything.
2. Who uses it. List every type of user and what each one is allowed to see and do. Include the administrator and anybody external. Four roles rather than one is the single biggest driver of the difference between quotes.
3. What it connects to. Name each system, and for each one say whether there is documentation, a test environment and a person who answers questions.Write "unknown" where it is unknown. Unknown is useful information; silence is not.
4. Where the data lives now. Spreadsheets, an old system, a mailbox, one person's head. Roughly how many records, and whether anyone can say which version is authoritative.
5. What happens when it is wrong. Who notices, how quickly, and what it costs. This determines how much testing and review the build needs, and it is the line most often missing.
6. What it replaces, and what has to keep running. Anything the old process does that cannot stop on the day this launches.
7. The date and why. A real constraint, such as a contract ending or a season, changes the plan. A date with no reason behind it just raises the price.
8. What is deliberately out of scope for version one. Writing this yourself is the strongest signal available that the project is thought through.
Anything unknown stays as "unknown". A brief with five honest gaps produces better quotes than one with five confident guesses, because the gaps get asked about and the guesses get priced.
Comparing the quotes when they come back
Put the responses side by side and normalise them before looking at any totals.For each quote, write down:
- The number, and whether it is fixed, capped or an estimate that can move
- What it excludes, quoted from their document, not summarised
- Whether design, testing, data migration, training and documentation are inside or outside that number
- Who owns the code, infrastructure and accounts at the end
- What happens after launch, for how long, and at what cost
- The named people doing the work, and whether they are the ones in the meetings
- How scope changes get priced, in writing
Two quotes that looked forty thousand apart are frequently the same price once migration, testing and the first year of support are on the same side of the line. Occasionally the expensive one is genuinely cheaper. That comparison is impossible without the list above and straightforward with it.
What no quote can tell you
However carefully written, a proposal is a forecast made by people you have known for a fortnight. What is really being bought is their judgement in all the situations the document does not cover, and there will be many.
So read the number, then notice something else. Did anybody in the process say something you did not want to hear. Did anyone question a feature, suggest a cheaper route, or say that a part of it was not worth building. A supplier who has agreed with everything so far is not being easy to work with. They are being expensive later.