How much should a software project cost?

There is no reference price per project type: two proposals for the same system can differ threefold and both be reasonable, because they are quoting different scopes. What you can evaluate is the internal coherence of a proposal — whether the estimated hours match the described scope, whether the proposed team can deliver them in the offered timeline, and whether the assumptions are written down.

Is it a bad sign when one quote is far cheaper than the others?

Not always, but it forces a question. The three usual reasons are: the vendor understood a smaller scope, the vendor is buying the contract and will recover margin through change requests, or there is genuine underestimation from inexperience in that domain. The first is fixed by aligning scope; the other two end up costing more than the expensive proposal.

What's the difference between fixed price and time and materials?

Fixed price transfers estimation risk to the vendor, which is why it carries a contingency margin; it works when scope is closed. Time and materials leaves that risk with the client and works when scope will change. The expensive mistake is signing fixed price against a scope still being discovered: every finding becomes a billed change.

How to evaluate a software development quote

A development quote is not evaluated by comparing one total against another. It is evaluated by what the proposal doesn’t say: what assumptions the vendor made to reach that number, what was left out of scope, and who pays when reality and assumption disagree.

This is the review we run before a client signs. It works just as well if you run it yourself.

The four numbers to always ask for

A total is not information. Ask for the proposal to be broken open along four dimensions, because each one exposes a different kind of risk:

Hours by role and by phase. Not “400 development hours”, but how many for architecture, implementation, testing and deployment. If testing is under 20% of the total, the vendor is either doing it in their head or not doing it.
Estimated monthly infrastructure cost. Separate from development. A system can cost $80k to build and $12k a year to keep running, and that second figure almost never appears in the proposal.
The cost of change. The hourly rate for a new requirement once the project is underway. If it isn’t written down, it gets negotiated at the point where you no longer have leverage.
The cost of exit. What happens if the relationship ends in month six: who keeps the code, which repository it lives in, who holds the production credentials.

The fourth is the most frequently omitted and the most expensive to discover late.

Scope is read in the exclusions

In a well-built proposal, the exclusions section is as long as the deliverables section. When that section is missing, it doesn’t mean everything is included — it means the discussion was deferred.

Check specifically whether these are in or out:

Migration of the data that already exists (almost always underestimated; typically 15–30% of a replacement project).
Third-party integrations, including waiting time for credentials and someone else’s test environments.
User training and operational documentation.
Defect fixes after go-live, and for how long.
Environments: does the proposal cover development, staging and production, or production only?

Signs the price is going to move

Sign in the proposal	What it usually means
Estimates in round numbers (100, 200, 500 hours)	The work was never decomposed; the number is an intuition
No written assumptions	Every finding will become a billable change
The team is described by profiles, not people	Nobody is assigned yet; availability is a promise
The timeline is exactly the one you asked for	The estimate was fitted to the wish, not to the work
“Agile methodology” with no defined cadence or per-sprint deliverables	Agile as an excuse not to commit to scope
A single payment milestone at the end	Sounds good for you, but it means the vendor is financing the project: either the price includes that, or cash flow will squeeze it

None of these invalidates a proposal on its own. Three or more together does: it means the number isn’t backed by analysis, and a number without analysis moves.

The questions that change the conversation

These four questions, asked in writing, reorder any negotiation:

“What assumptions did you make to reach this estimate?” Forces the implicit into the open. Answers that begin with “we assumed you would…” are the ones to review with your internal team, because they are commitments of yours you didn’t know you had made.

“Which part of this scope carries the most uncertainty?” An experienced vendor answers in ten seconds and with precision. One who answers “it’s all clear” either hasn’t analysed the problem or doesn’t want to tell you where the risk is.

“If you had to deliver in half the time, what would you drop?” The answer shows what the vendor considers essential and what they consider padding. Sometimes you discover 40% of the scope was padding to justify the price.

“Who specifically will work on this, and what else is that person on?” The difference between a dedicated team and a shared one is weeks of calendar that nobody puts in the proposal.

What to do with the answers

If the vendor answers all four precisely and in writing, the proposal is probably well built even if the price is high — and a high price with analysis behind it is cheaper than a low price that is going to move.

If they dodge two or more, the problem isn’t the price: there is no analysis underneath, and you would be signing an intention.

What we never recommend is negotiating the total down without changing the scope. The vendor will accept and recover the difference somewhere: less testing, a more junior profile, or the first change request. The price dropped on paper and the risk went up in reality.

If you have a proposal on the table and want a second reading before you sign, get in touch. We don’t do development work, so we have no project to sell you instead.