Introduction
A software quote is often treated as a price document. In reality it is a responsibility document.
The price matters. But the assumptions behind the price matter more.
A software project rarely goes wrong because of the number on the quote. It goes wrong because expectations, ownership and responsibilities were never clearly defined.
What it solves
What a careful quote review surfaces
-
Hidden cost lines
Hosting, monitoring, third-party services and maintenance are routinely excluded. A careful review names them before they appear as separate invoices.
-
Ownership of code and accounts
Source code, design files, hosting accounts, domain registrations and analytics, the document either assigns them or it does not.
-
Scope boundaries
A scope written as features is testable. A scope written as work packages is negotiable forever.
-
Change-request economics
How additions to scope are priced is more important than the headline price. A review surfaces the rate, the approval path and the typical cycle.
-
Post-launch responsibilities
Who fixes bugs, who responds to incidents, who applies security updates. A quote that does not say is a quote that does not include.
What it does not solve
What a quote review will not fix
-
An unclear product brief
If you do not know what you are building, no review of any quote will rescue the project. Clarity sits with you, not with the vendor.
-
A weak vendor relationship
A pristine quote with the wrong people produces the wrong outcome on schedule and within budget.
-
Demand validation
Reviewing a quote is not the same as validating that anyone wants the product. Sign nothing until that question has its own answer.
-
Internal capacity to direct the work
Even the best vendor needs decisions, reviews and feedback. A quote does not buy you out of being available.
-
Strategic clarity
Quotes evaluate a single project. They do not evaluate whether the project is the right one for your stage.
Decision tree
Ten questions for every quote
Read every quote through these questions. The vendor's answer to each is more useful than the price.
- Question 01
Is the scope clearly defined as concrete features?
No → Send it back. A scope of 'platform development' or 'app build' will produce months of change requests.Yes → Continue. Compare scopes between vendors on these specific feature lines, not totals. - Question 02
Is ownership of the source code specified?
No → Ask explicitly. Assume the worst-case interpretation; vendors often retain ownership by default.Yes → Confirm in the contract, not just the quote. - Question 03
Are acceptance criteria documented for the main features?
No → Add them before signing. Without them, 'done' is whatever the vendor says it is.Yes → Check whether they describe behaviour, not just screens. - Question 04
Is hosting included or excluded?
No → Ask for the monthly hosting cost and who manages the account. Both matter.Yes → Confirm what the cost includes, domain, SSL, backups, monitoring, and what is extra. - Question 05
Is maintenance included or excluded?
No → Request a separate maintenance proposal with response times and scope.Yes → Confirm what 'maintenance' means, bug fixes, security updates, dependency upgrades, or all three. - Question 06
Who is responsible for third-party integrations?
No → Name every integration and assign owners, including API keys, billing, and renewals.Yes → Confirm the vendor has tested the specific versions they will deliver against. - Question 07
What happens when requirements change?
No → Ask for the hourly rate, the approval path and how priority is decided.Yes → Compare the rate to the project rate; large gaps are a sign of the real margin. - Question 08
What assumptions is the vendor making?
No → Request the assumptions in writing. Anything assumed becomes anything billed later.Yes → Test the assumptions against your reality before signing. - Question 09
What happens after delivery?
No → A handover without a plan is not a handover. Ask for the documentation, accounts and code transfer in writing.Yes → Confirm the date, the artifacts and the support window after delivery. - Question 10
What is explicitly not included?
No → Ask. The exclusions are often the largest unbudgeted lines.Yes → Verify each exclusion has either a budget elsewhere or an explicit owner.
Common mistakes
Five common mistakes founders make
- 01
Comparing vendors only on price
The cheapest quote often achieves it by leaving the hardest work outside the scope. Compare what is included, then compare what is missing.
- 02
Assuming 'included' means the same thing everywhere
One vendor's 'hosting included' is one year of a shared instance. Another's is three years on dedicated infrastructure with monitoring. The word is the same; the cost is not.
- 03
Ignoring post-launch costs
Maintenance, hosting, monitoring, security updates, and feature backlog after launch, these recurring costs are often larger than the build itself within 18 months.
- 04
Accepting vague requirements
A scope written in adjectives ('modern dashboard', 'flexible admin', 'scalable backend') produces a build written in change requests. Vague in equals expensive out.
- 05
Not defining ownership
Source code, design files, hosting accounts, domain ownership and analytics access, every one of them must be named. Default assumption: nothing is yours until the contract says it is.
Alternatives
How to structure the review
Four practical patterns that get you to a fair, comparable evaluation.
-
Score each vendor against the same ten questions
Convert qualitative quotes into a comparable matrix. The point is not to pick the highest score, the point is to make the gaps visible to the vendor and to you.
-
Ask for the assumptions list separately
Most vendors will share a written assumption list if asked. Comparing assumption lists tells you who has thought the project through.
-
Request a fixed-price phase for the first delivery
If the full build is hard to price, ask for a fixed-price discovery phase that produces a tighter quote. This separates 'planning the work' from 'doing the work'.
-
Talk to two of their previous clients
Five minutes with a past client tells you more about change-request behaviour than ten pages of quote text. Vendors who hesitate to share references are telling you something.
Ronald's rule of thumb
The most expensive surprises are usually hidden in the assumptions, not the price.
A price is a number you can compare. An assumption is a sentence that nobody compares, until the invoice arrives. Read the assumptions, list the exclusions, and the project becomes predictable before the work starts.
, Ronald · YourStartup.Expert
Summary
Summary
The number on a software quote is the smallest source of risk in a software project. The biggest source of risk is everything that is not on the quote: assumptions, ownership, exclusions, change-request economics and what happens after delivery.
Read every quote through the ten questions above. Whichever vendor answers them most clearly is usually the vendor who will execute the project most clearly. Whichever vendor refuses to answer them is telling you something the price never will.
Common questions
Reviewing a software quote, answered.
The questions founders ask before they pick a vendor.
- How do I compare software quotes?
- Compare the assumptions first, the scope second, the exclusions third, and the price last. Build a matrix with the ten questions in this framework as rows and the vendors as columns. The cheapest quote often hides the most expensive omissions, so a like-for-like comparison only becomes possible once every quote has answered the same questions.
- Should I always choose the cheapest quote?
- Rarely. The cheapest quote usually achieves the price by excluding the hardest work, hosting, integrations, post-launch support, complex flows, or by making assumptions that quietly become change requests. A fair comparison normalises for scope. After that, choose the vendor whose written answers and references give you the most confidence, not the lowest number.
- What should be included in a software quote?
- A defined scope written in concrete features, acceptance criteria for the main flows, a list of assumptions, a list of exclusions, an explicit statement on ownership of code and accounts, a change-request rate and process, hosting and maintenance arrangements, and a description of what happens after delivery. Anything missing from the document is missing from the contract.
- Who should own the source code?
- You should, unless there is a specific reason otherwise. Default assumption: the code, design files, hosting accounts, domain registrations and analytics belong to your company from day one. Confirm this in the contract, not the quote, and ask for the handover artifacts at delivery, including credentials, repository access and documentation.
- How detailed should a quote be?
- Detailed enough that two engineers reading it would build broadly the same thing. That usually means concrete features with acceptance criteria, named integrations with versions, a stated hosting environment, and explicit assumptions. A one-page quote at €60,000 is not detailed enough; a fifteen-page quote with no assumptions is detailed in the wrong direction.