Buyer guide · Commercials

How Custom Software Is Priced

This guide explains how software prices are constructed and what moves them. It publishes no rates, ours or anyone else's, because a rate detached from scope, seniority and written assumptions is not information. What you can take from it is the ability to read an estimate, see what a supplier has assumed, and compare two proposals that arrived in different shapes.

Explore our software development services

By Anjula Paulus, Founder and software engineer · Published 16 October 2026 · 9 min read

Key takeaways

Price is effort multiplied by rate, plus whatever the supplier is charging for risk.
Integrations, data migration and non-functional requirements move cost more than feature count.
The pricing model decides who carries scope risk; it does not change the work.
An estimate without written assumptions and exclusions cannot be compared with anything.
Decision speed on the buyer's side is a real and frequently underestimated cost driver.

Terms used in this guide

Commercial conversations go wrong when the two sides use the same words differently. Fix the vocabulary before discussing numbers.

Estimate — a supplier's forecast of effort, correct only against the assumptions attached to it.
Quote — a price the supplier is willing to be held to, which therefore contains contingency.
Budget — what you can spend, which is yours to state and should shape scope rather than be guessed at.
Day rate — the price of one person for one day; meaningless without the seniority and the role it covers.
Blended rate — one averaged rate across a mixed team, which hides who actually does the work.
Contingency — money added for the parts nobody can see yet; present in every fixed price whether or not it is shown.
Discovery — a short paid phase that converts unknowns into a scope worth pricing.
Change request — a priced amendment to a fixed scope, the mechanism that keeps a fixed price honest.
Non-functional requirements — uptime, performance, security, accessibility and recovery targets, which are work even though no user sees them as features.

What you are actually buying

Every price in this market is effort multiplied by a rate, plus a risk premium. Effort is engineering hours, plus the design, testing, review, deployment, documentation and project work that comes with them. The rate reflects seniority, location and the supplier's own costs. The risk premium is the part suppliers rarely itemise: the less certain the scope, the larger it is, and in a fixed price it is invisible.

This is why two quotes for the same brief can differ by a multiple without either being dishonest. One may have assumed your data is clean, one integration is enough and you will supply content on time. The other may have assumed none of those things. The difference is in the assumptions, not in the arithmetic.

The cost drivers, in rough order of weight

Buyers usually expect feature count to dominate. In practice it rarely does. The drivers below reorder most estimates, and the first four are responsible for most of the surprises.

Integrations — each external system adds a contract, failure handling, credentials, reconciliation and a dependency on somebody else's release schedule.
Data migration — legacy data is almost never as clean as reported, and the cleaning, mapping and rehearsal is often larger than the feature it feeds.
Non-functional requirements — high uptime, audit trails, encryption, performance targets and accessibility obligations are engineering work, not settings.
Existing code quality — building inside an undocumented system with no tests costs more than building the same thing fresh.
Roles and permissions — every additional user type multiplies the paths that must be built, tested and secured.
Platform count — web, iOS and Android are three delivery surfaces, with three sets of testing and release work.
Design novelty — a system built from an existing component library costs less than one designed screen by screen.
Regulatory and review steps — approvals, audits and formal documentation add elapsed time and effort regardless of difficulty.
Decision latency on your side — a team waiting four days for an answer is still being paid; slow approvals are one of the most expensive habits a buyer has.
Environments, deployment and monitoring — real systems need staging, pipelines, backups and alerts, and these are commonly missing from a cheap quote.
Support after launch — the warranty window, response times and who fixes defects is a priced commitment, not goodwill.

The pricing models side by side

Five models cover almost everything you will be offered. Each line gives who carries scope risk, where the model fits, how change is handled and what to watch for.

Fixed price — supplier carries scope risk; fits genuinely bounded work with written acceptance conditions; change goes through a priced change request; watch for hidden contingency and a long exclusions list.
Time and materials — buyer carries scope risk; fits work whose direction will change; change is simply the next priority; watch for an open-ended total and thin reporting.
Capped time and materials — risk is shared above the cap; fits mostly-clear scope with some unknowns; change is reprioritised under the cap; watch for the cap quietly becoming the target.
Monthly retainer or dedicated team — buyer carries scope risk, supplier carries staffing risk; fits continuous product work; change is handled in the backlog; watch for paying for capacity you are not keeping busy.
Milestone or outcome-based — risk follows whoever controls the outcome; fits measurable results inside the supplier's control; change is renegotiated per milestone; watch for outcomes that actually depend on your users, your data or your marketing.

How an honest estimate is built

A usable estimate is built bottom-up from a list of work items, not top-down from a number the buyer mentioned. It carries a range rather than a point, and the range narrows as unknowns are closed. It names its assumptions, states what is excluded, and says which questions would change it most.

A supplier who identifies the three riskiest unknowns and proposes a short paid investigation is usually safer than one who prices unclear work to the day. Confidence is not accuracy, and an estimate presented without a range is a marketing document.

A work breakdown you can read, not a single figure
A range, with the reason the range is that wide
Explicit assumptions about data, content, integrations and approvals
An exclusions list, including what happens after launch
The acceptance conditions that define done
What the supplier would need to know to tighten the number

Comparing two quotes that look different

Normalise before comparing. Put both proposals against the same scope and the same list of assumptions, and most of the apparent difference will turn out to be items one supplier included and the other left out.

Is discovery priced in, priced separately or absent?
Does the number include design, testing, deployment and documentation?
Is data migration in scope, and whose job is the cleaning?
Which integrations are included, and at what level of failure handling?
What is the warranty period and what counts as a defect within it?
Who pays for third-party services, licences and infrastructure?
What is the change-request process and how is it priced?
What is assumed about your availability for decisions and content?

A decision rule for choosing the model

Apply these in order and stop at the first that matches.

Rule 1: if you cannot write the acceptance conditions today, buy a short paid discovery first and price the build afterwards.
Rule 2: if scope and acceptance are written, bounded and unlikely to move, use fixed price.
Rule 3: if the scope is mostly clear but two or three unknowns remain, use capped time and materials and spend the cap on the unknowns first.
Rule 4: if the product will keep changing because you are learning from users, use time and materials or a monthly team, with visible priorities and burn reporting.
Rule 5: if the work is continuous and indefinite, use a retainer sized to the work you can actually feed it, not to the team you would like to have.
Rule 6: only accept outcome-based pricing when the outcome is measurable, attributable and inside the supplier's control; otherwise it becomes a dispute.

What should never be in a price

A few charges indicate a supplier whose commercial model depends on you being unable to leave. Treat each of them as a reason to renegotiate before signing.

A fee to receive the source code of software you paid to have built
A licence back to you for your own commissioned work
A charge for access to the repository, cloud account or pipeline
Handover priced as a separate project at the end of the relationship
Mandatory hosting with the supplier as a condition of ownership

Questions

Common questions about how custom software is priced

How much does custom software cost?

There is no useful single figure, which is why this guide gives none. The same brief can differ by a multiple depending on integrations, data migration, uptime and security requirements, platform count and the state of any existing code. Ask two suppliers to price the same written scope with assumptions attached, and compare those.

Why will a supplier not give a price on the first call?

Because a number given before the integrations, data and acceptance conditions are known is either padded heavily or will be revised later. A supplier who proposes a short paid discovery is converting unknowns into something that can be priced honestly.

Is a fixed price cheaper than time and materials?

Usually not. A fixed price includes contingency for risk the supplier cannot see, and you pay that contingency whether or not the risk occurs. Fixed price buys budget certainty, not a lower total.

Should I tell a supplier my budget?

Yes, if you have one. A budget is a constraint that shapes scope, and withholding it usually produces a proposal you cannot buy. It is not an invitation to spend it all; a credible supplier will tell you what fits and what does not.

Related software guides

All resources