How Much Does Custom Software Really Cost?

At some point in this process, you will receive a quote. It will arrive in a PDF, or a slide deck, or a follow-up email after a call that felt promising. It will look considered. And you will have almost no way to know whether it is right. That is not an accident. It is how software procurement is structured, and it systematically disadvantages the person who has not done this before.

Why do quotes for the same project vary so much?

You write a brief, find three agencies with good reviews, and send it out.

The proposals arrive. One comes in at $40,000. Another at $180,000. A third at $95,000. All three reference the same brief. None of them explain why the numbers are so different.

At this point, most buyers do one of two things. They pick the middle number because it feels safe. Or they pick the lowest because the budget is tight and the vendor seemed trustworthy on the call.

What they do not yet know is that each vendor scoped the project differently. One included a custom admin dashboard. One assumed you would use an off-the-shelf tool. One priced in three rounds of revisions. One priced in none. Those decisions are buried in assumptions nobody showed you, invisible in the final number.

The cheapest quote is usually cheapest because it contains the most unstated assumptions — not because the vendor is more efficient. You find out which assumptions were wrong when the change orders arrive, typically after kick-off, when walking away is no longer a real option.

Six months later, the $40,000 project cost $110,000 and still is not live. The cause is rarely technical. It is almost always scope that was assumed rather than defined, and a budget that reflected optimism more than analysis.

Why does the information gap between buyers and vendors persist?

The standard defence is that software is complex and every project is different. Both are true. Neither explains why buyers are routinely left with numbers they cannot interrogate.

The structural problem is this: pricing depends on scope, scope depends on requirements, and requirements are almost never fully defined when an estimate is produced. A vendor quoting you in week one is quoting against assumptions they have not shown you. When those assumptions turn out to be wrong, the contract does not protect you. It becomes the starting point for a conversation about what has changed.

We repeatedly see buyers discover this at the worst possible moment: after kick-off, after the first invoice, after the relationship has enough momentum that stopping feels more expensive than continuing. By then, the information asymmetry that existed before the contract was signed has become a budget problem that is entirely the buyer’s to absorb.

The vendor is not always acting in bad faith. They are often quoting from a one-hour call and a rough brief, filling gaps with optimism because that is what closes deals. You are reading the number as a commitment because that is what it looks like. Nobody corrects the mismatch until the money is already moving.

The incentive structure makes this worse. In a time-and-materials model, where you pay for developer hours regardless of what gets built, a project that runs long is not a failure for the vendor. It is more revenue. There is no financial pressure on their side to finish faster or scope more accurately. That pressure sits entirely on you.

What does custom software actually cost, and why?

Two projects can look identical in a brief and cost completely different amounts to build. That gap is not random. It follows from a small number of variables that vendors understand and most buyers do not.

The first is complexity, and it is almost always underestimated. Buyers think in outcomes. A healthcare operator describes a “patient intake form.” A developer hears role-based access, audit logging, HIPAA-compliant data storage, and a document management layer. Both descriptions are accurate. They describe the same thing from opposite ends of the build. The gap between those two perspectives is where scope quietly expands before anyone calls it a change order.

Integrations compound this. The moment your software needs to communicate with something else — a payment processor, an EHR system, an accounting tool, a logistics API — you have introduced a dependency on a third-party system you do not control. Each one adds coordination, testing, and debugging overhead that is genuinely hard to predict in advance. A project with three integrations is not three times harder than a project with one. It is often considerably more, because the failure modes multiply.

The single largest lever on total cost is often simpler: where your team is based. A US-based agency can cost three to four times more per hour than a comparable Eastern European team, and more still compared to South Asian teams. Rate is not a reliable signal of quality. But if you are comparing proposals without knowing where each team is located, you are not comparing the same thing.

What surprises most first-time buyers is that unclear requirements often cost more than any of the above. Not because ambiguity is expensive in principle, but because vendors quote optimistically into it. When a requirement that was assumed turns out to be more complex than the vendor priced, that is not a mistake. It is a change order. And change orders arrive after kick-off, after commitment, when the cost of stopping exceeds the cost of paying.

None of this accounts for what comes after launch. Maintenance, hosting, security updates, and future feature development are ongoing costs that rarely appear in an agency proposal. The build is the beginning of the spend, not the end of it. If you are also evaluating the cost of building an MVP first, the same scoping principles apply — the variables that drive cost are identical regardless of how you frame the initial scope.

How should you write your product brief before getting quotes?

Most first-time buyers treat the product brief as a formality. Something to send so the vendor has enough to go on. A few paragraphs about the idea, a rough feature list, a note about the industry. Then wait for the proposals.

The brief is actually the most important document in the entire project. Not the contract. Not the statement of work. The brief. Because every requirement you leave undefined is an assumption the vendor fills in on your behalf — and when their assumption differs from what you meant, that gap has a price.

The brief is also the only moment in procurement where you have full control and no cost. Once you have signed, ambiguity belongs to the vendor.

What the brief really forces you to answer is not “have I given them enough to quote against?” It is “do I actually know what I am building?” Vendors rarely help you answer that second question. Their incentive is to start, not to scope.

If you cannot define what “done” looks like for a core feature, you are not ready to receive a quote. Not because an estimator will not produce a number — it will — but because any quote built against a vague brief is a number the vendor invented. Filled with assumptions you have not seen, against requirements that do not fully exist. You have no way to evaluate it, because there is nothing solid to evaluate against.

What protects you once you are inside a vendor relationship?

Understanding cost ranges gets you to the table. It does not protect you once you are sitting at it.

The standard agency model is time-and-materials: you pay for developer hours regardless of what gets built. If the project runs long because a requirement was underestimated, or a third-party integration behaved unexpectedly, or scope shifted mid-build, you absorb the cost. The vendor’s margin is protected either way. There is no financial consequence for them when the project runs over. That consequence is entirely yours.

Outcome-based pricing works differently, and the difference matters before you sign anything. When cost is tied to defined, deliverable pieces of functionality rather than hours logged, the vendor’s margin depends on building efficiently. That financial pressure changes the dynamic. It also forces transparent scoping earlier, because you cannot price a deliverable that has not been defined. That front-loaded clarity is where a significant amount of budget protection comes from — not the contract language, not the project manager, but the definition of done that exists before kick-off.

This is worth asking about directly when you evaluate vendors. How do you price? What happens when a feature takes longer than estimated? What does a change order look like, and when does one get triggered? A vendor who can answer those questions clearly — before you have committed to anything — is a different proposition from one who cannot.

How can an independent estimate change the negotiation?

The Fraction estimator exists for the gap between “I have an idea” and “I am sitting across from a vendor who has already decided what it costs.”

Feed it your product brief and it returns a structured breakdown by feature area, with cost bands and assumption flags. It does not replace a vendor quote. It gives you an independent reference point before you negotiate one, so you are no longer evaluating a number in a vacuum. You are comparing it against a structure you built before anyone was trying to sell you anything.

Where it earns its keep is before you talk to anyone. A well-defined feature returns a useful cost band. A vague one returns a range so wide it is meaningless. That is not a flaw — it is the signal. It tells you exactly where a vendor will quote optimistically into your ambiguity, and where you will pay to find out later. Clearing that up before you enter any vendor conversation is the cheapest work you will do on this project.

The buyers who end up $100,000 over budget are not always the ones who received a bad quote. They are often the ones who had no way to recognise it. An independent estimate built on the same brief — before any vendor conversation — closes that gap. Understanding what AI development costs in 2026 follows the same logic: the same scoping discipline that protects you on a standard software build protects you when the project involves an AI layer too.

You do not need to become technical to buy software well. You need cost certainty before you commit, and a signal that was not produced by the person selling to you. That combination — a clear brief and an independent reference point — is what separates buyers who stay on budget from those who do not.

Frequently asked questions