How Much Does Custom Software Development Cost? A Quote, Line by Line

The question I get asked first is how much custom software development costs, and the answer that helps is not a range. It is a list. A quote is a stack of line items — discovery, design, build, integrations, testing, deployment — and then a period after launch that most quotes never mention. The total you are shown is the sum of a set of assumptions about each of those lines. Change one assumption and the number moves a long way, which is why the same brief comes back from two suppliers looking like two different projects.

I have spent ten years on both sides of that document: writing the code, running the delivery, and then producing the estimate and watching it either hold or miss. What follows is the anatomy of a quote, and where the misses actually come from.

What decides how much custom software development costs

Not the hourly rate. Rate is the most visible variable and the least explanatory one. What decides the total is how much of the work is written down before anyone prices it, and how much has been left as an assumption for somebody to discover later.

A quote is an answer to a question. If the question is vague, the supplier has two choices: price the vagueness in, or price the optimistic reading and renegotiate later. Both happen. Only one is declared.

This is also why arriving with something working sharpens an estimate more than any brief does. A prototype settles arguments a document cannot. Just be clear with yourself about what you have: a prototype is a specification, not a foundation, and pricing it as though it were most of the product is its own expensive mistake.

Discovery

Discovery is the work of turning a brief into something estimable. Not wireframes — the process. Who does what today, what the exceptions are, which of the things described as rules are actually rules, and what happens on the days the process breaks.

It is the line clients most want to cut, and cutting it does not remove the work. It relocates it into the build, where it costs more, because by then somebody has already made a decision the discovery would have prevented. When we built the invoicing platform in the HisaabKar case study, the part that needed settling first was not the invoice template. It was how a single payment should clear several outstanding invoices, and what happens to the remainder. That is a discovery question. Get it wrong and the data model is wrong.

Design

Design covers two different things that get quoted as one. There is interface design — screens, states, the empty state, the error state, the state where somebody has 400 rows instead of four. And there is the design of the thing itself: the data model, the permissions, what an "account" means when a company has five users and two of them are contractors.

The second is the expensive one and it rarely appears as a line. When a quote shows design as a small number next to a large build, ask which of the two it refers to.

Build

The line everyone looks at, and the one that behaves most predictably, because it is the part suppliers have the most experience estimating. Even here, the variance between quotes is rarely speed. It is what "build" was taken to include.

Does it include the admin side, or only what the end user sees? Does it include the second role, the one mentioned in a sentence halfway down the brief? Does it include the reporting that everybody assumes is a view over data that already exists, and which is usually its own small project?

Integrations

Every integration is a negotiation with something you do not control. The accounting system, the payment provider, the courier's tracking API, the client's existing CRM. The code to call an API is not the cost. The cost is the discovery that the sandbox behaves differently from production, that the field you need is only populated on some records, that access requires an account somebody in another department has to authorise, and that the vendor's support queue answers on their schedule.

This is the single most common reason an estimate that was honest on the day stops being honest.

Quality assurance

QA is not a phase where someone clicks around at the end. It is test coverage on the logic that would be expensive to get wrong, a pass on the interface in the browsers your users actually have, and an accessibility check if any part of the audience needs one.

A quote with no QA line has not saved you QA. It has moved it to your staff, after launch, for free, in the form of them finding the bugs.

Deployment and handover

Getting software onto a server is quick. Getting it onto a server in a way that can be redeployed safely next week is not. That is environments, a deployment pipeline, secrets management, backups that have actually been restored once, monitoring that tells someone when it breaks, and documentation that lets a different developer pick it up.

Handover is also where ownership gets decided. Whose accounts are the hosting, domain and third-party services in? If the answer is the supplier's, you have bought software you cannot move.

The twelve months after launch that nobody quotes

Launch is the middle of a project, not the end. In the year afterwards there is hosting and the services the application depends on, security patching, upgrades to the language runtime and libraries, support for the people using the thing, and the changes they will ask for as soon as they do. Some of that is optional for a while. Runtime upgrades are not: platforms publish end-of-life dates in advance, and Node.js, for one, publishes its release and support schedule openly, so a version you deploy on has a known date where security fixes stop.

The pattern I would push back on hardest is "we will just fix it when it breaks". That is a real strategy with a real price: everything is an emergency, nothing is scheduled, and the work happens at whatever rate emergency work commands. The same logic applies to sites, which is why the cost to maintain a website per year is a line item rather than a contingency.

If a quote ends at handover, the year after has not been removed from the project. Only from the page.

Why two agencies quote the same brief so differently

Assume good faith and the differences still make sense. Here is where they come from.

Different assumed scope. The brief said "users can export their data". One supplier read that as a CSV download. The other read it as a scheduled export, with filters, in three formats, emailed. Both read it honestly.

Different definitions of done. For one supplier, done means it works on their machine and the demo goes well. For another, it means tested, deployed through a pipeline, monitored, documented and handed over. These are not the same product and they should not cost the same.

Different quality floors. Accessibility, browser support, load behaviour, audit logging — the requirements nobody writes in the brief because they assume them. Suppliers vary enormously in what they assume by default.

Different risk ownership. A fixed price for an unsettled scope is an insurance policy, and the premium is inside the number. A lower time-and-materials estimate is not necessarily cheaper; it has simply left the risk with you.

Different team composition. Onshore, offshore, blended, a senior lead with juniors underneath, or one very experienced person alone. The blended rate is a real difference between suppliers, and it is the one people fixate on, but it is rarely the biggest term in the equation. The same dynamic plays out sharply in app work, which I have written about in why app development quotes vary.

Different appetite for the work. Some suppliers price a project they do not want. That number is information about their pipeline, not about your project.

The surprises: what pushes a number up

Three things account for most of the overruns I have seen, and none of them are the code.

Systems you do not control

Anything that depends on a third party depends on that third party's timelines. Credentials that take weeks to be issued. An API whose documented behaviour and actual behaviour disagree. A vendor who deprecates an endpoint mid-project. You can plan around this by starting the integration early rather than last, but you cannot estimate it away.

Data migration

Everybody underestimates this, including me, repeatedly. The reason is that data migration is not a technical problem. It is an archaeology problem. The old system has records that violate its own rules, fields that were repurposed, duplicates that two departments each consider authoritative, and a date format that changed at some point nobody documented. Writing the import script is a day. Deciding what to do with the rows that fail it is not.

The rule I use now: ask for a full export in week one, not week ten. What comes back tells you more about the project than the brief did.

Approval cycles

Calendar time is cost. If every design decision waits for a committee that meets fortnightly, the project is bounded by the committee, not by the development team. Two suppliers can assume very different decision-making speeds and produce very different numbers for the same work.

Before you sign anything, name the one person who can approve a decision without a meeting. If that person does not exist, the estimate needs to say so.

A worked example, with your numbers not mine

I am not going to publish a rate card dressed up as an industry average, because that number would be fiction and you would budget against it. Do this instead, with the quotes actually in front of you.

Take every quote and rewrite it into the same seven rows. Leave the figures exactly as each supplier wrote them, and put a dash where a supplier has no such line.

Now do the arithmetic that matters. If supplier A's total is lower than supplier B's, and A has a dash in the integrations and first-year rows, the difference between them is not a discount. It is those two rows, and you will pay for them either way — to A later at a rate you have not agreed, or to your own staff in time nobody counted.

That is the whole trick. A cheaper quote is only cheaper if it is the same quote.

How to read a number before you agree to it

A few questions that have consistently told me more than anything on the cover page:

• "What are the three biggest risks to this estimate, and what would you do if each one happened?" A supplier who cannot name three has not thought about it, or is not telling you.
• "Which parts of this number are you least confident about?" The honest answer is usually integrations and migration. An answer of "none" is the concerning one.
• "What happens to the price if we cut this feature?" If the total does not move, the feature was not costed.
• "Who owns the code and the accounts at the end?" This should be a one-sentence answer in the contract, not a conversation.
• "What does month thirteen look like?" You are listening for whether they have thought past handover at all.

The decision rule

Build custom when the process you are paying to encode is the thing that makes you different, and when no product on the market fits it without you bending your business to the tool. Otherwise buy the tool, and put the money into the one part of your process that genuinely is yours — the reasoning I set out in custom software versus off the shelf.

When you do build, judge the quote by what it admits rather than by its total. The supplier who writes down what they do not yet know is not the risky one. The estimate that has no unknowns in it has not looked hard enough, and someone is going to pay for the gap. It is very rarely the person who produced it.

If you want a second read on a quote you have been given, that is a conversation we are happy to have — it is the same thinking we apply before we price custom software or a full product build ourselves.