A software quote often arrives as a PDF with a number at the bottom. That number is the least useful part. What matters is what it covers, who carries the risk if the estimate is wrong, and what is left out.
This post walks through how to read a quote, line by line, and how to compare two quotes that look nothing alike.
#Three pricing models and who carries the risk
Fixed price. The team commits to a price for a defined scope. If the work turns out harder than expected, the team absorbs the cost. The catch is that “defined scope” has to be written down, because anything outside it is a change. A fixed price with a vague scope is not fixed at all.
Time and materials. You pay for the hours worked. This is honest when the problem is unclear and needs exploration, but you carry the risk: if the work takes longer, you pay more. Ask for a regular report of hours spent against what was estimated, and agree on a point where you can stop or reassess.
A range. “Between X and Y” sits in the middle. It is useful if the quote explains what pushes the price toward the top or the bottom. A range with no explanation is just a wide guess.
None of these is wrong. What matters is that you know which one you are signing and what it means for you if the estimate is off.
#The line items to look for
A reasonable quote shows the work in stages, even if it gives one total. Look for:
- Discovery: workshops or interviews to understand your process before anything is built.
- Design: what the screens and flows look like, and your chance to approve them.
- Build: the main body of work. It should list the features, not just say “development.”
- Testing: who tests, and what happens when something fails.
- Deployment: getting it live, including setting up the servers or accounts it runs on.
- Documentation: written instructions for how the system works and how to operate it.
- Training: time spent teaching your team to use it.
- Support: what happens after launch, and for how long it is included.
If one of these is missing, ask whether it is free, included in another line, or simply not happening. “Not happening” is a common answer for documentation and training.
#What is commonly missing
Quotes tend to describe the build and go quiet on everything around it. Ask about:
- Hosting and third-party fees. The software may need servers, a database, email sending, SMS, payment processing, or paid APIs. These are usually billed by the vendors, and you should know what they are and roughly how they scale. Check each vendor’s current pricing page rather than trusting a number in a quote.
- Data migration. Moving existing records from spreadsheets or an old system is real work. If you have years of rows, see our post on moving years of rows.
- Ongoing support. Is it included, priced separately, or absent?
- The change process. How are requests handled once work starts?
- What counts as a change. Is a new field a change? A new report? A different approval step? Ask for examples on both sides of the line.
#Red flags
- One big number. With no breakdown, you cannot compare it or see what you would cut.
- No scope document. A price without a written scope is an opinion.
- “Unlimited revisions.” It sounds generous, but it usually means the scope is undefined, and it can lead to endless cycles that wear out both sides. A better promise is a clear review process with defined rounds and a way to handle larger changes.
- A price that is far below the others, with no explanation. Something has been left out or will be recovered later.
#Questions to ask
- What is not included in this price?
- What would make the price go up, and who decides?
- What do I pay for after launch, and what is covered?
- How do I approve a change, and how is it priced?
- Which third-party services will I pay for directly?
#Comparing two quotes fairly
Do not compare the totals first. Make a simple grid with one row for each line item above, and fill in each quote: included, extra, or not mentioned. Then add rows for hosting, migration, support, and the change process.
Where one quote is silent, ask. Then compare again. Often the cheaper quote becomes the more expensive one, or the reverse, once the same things are included in both. You can also give both teams the same short written brief, which makes quotes much easier to line up: our post on writing a brief a developer can quote shows how.
