Most people comparing software quotes are comparing the only thing the documents have in common, which is the price. That is understandable and it is close to useless, because two quotes for “a customer portal” can differ by a factor of four and both be honest.
Here is what to read instead. This is the checklist we would want someone to bring to us, which is the only reason it is worth publishing — a checklist that only made our own proposals look good would not be a checklist.
1. Is the scope written down, or described?
“A customer portal with reporting” is a description. “Six screens, three user roles, CSV and PDF export, SSO against your existing identity provider, one integration with the billing system” is a scope. The second can be argued about in week two. The first can only be argued about in month five, when arguing is expensive.
If the quote is a number attached to a description, the risk has not gone anywhere. It has just been moved onto you without being priced.
2. What is explicitly excluded?
A proposal with no exclusions section is not a generous proposal, it is an incomplete one. The things that are usually out and should be named: content and copywriting, photography, data migration from the old system, third-party licence costs, accessibility remediation of material you supply, and training.
Data migration is the one that bites hardest. It is routinely assumed to be included, it is routinely not, and it is routinely the single largest unplanned line item on a replatform.
3. What does a change cost?
You will change your mind. Every project does. The question is whether the mechanism for that is written down before it happens or invented afterwards during a difficult conversation.
Look for a change process with a rate and a turnaround. Ours is that changes get scoped and priced when they come up and you decide then — the point is that nothing accumulates silently into a dispute in the final week.
4. Who owns the code, and when?
Read the intellectual property clause. There are three common shapes: you own it outright, you own it on final payment, or you get a licence to use software the vendor continues to own.
All three are legitimate and they are not remotely equivalent. The third means you cannot take the work to another firm. If a proposal is quiet on this, that is the question to ask before the one about price.
5. Whose name is on the cloud account?
If the vendor’s, you have a dependency that has nothing to do with the quality of their work. Leaving stops being a commercial decision and becomes a migration project. We think the account should be in the client’s name from day one, and we run infrastructure we do not own for exactly that reason.
6. Is there a run cost, and is it in the quote?
Software has an ongoing cost whether or not the proposal mentions one. Hosting, monitoring, dependency and security patching, the platform upgrades you did not choose. A quote with no run cost is not cheaper; it has left a recurring number off the page.
Ask for the monthly figure alongside the build figure. Ours are published: $100 to $3,000 a month for managed hosting depending on traffic and environments, on top of the cloud bill, which stays in your name.
7. Who is actually doing the work?
Ask directly, and ask where they are. Ask whether the people in the pitch are the people who will write the code. Subcontracting is not automatically wrong, but undisclosed subcontracting means the quality you assessed and the quality you get are two different things.
8. What happens when something breaks after launch?
Ask for the defect period in writing. If a bug is found three weeks after launch, is fixing it included, or is it billable? Both answers are workable; not knowing which one you have is not.
Then ask the harder version: who decides whether something is a defect or a change? A vendor who defines that unilaterally has an incentive you can predict. The usual sensible answer is that anything not matching the written scope is a defect, which is another reason the scope has to be written down rather than described.
Two things that should make you slow down
- A fixed price with no discovery. A firm number produced before anyone has read your data model is a guess with a decimal point in it. It is usually padded, and when it is not, the shortfall gets recovered through change orders.
- An estimate with no assumptions. Every real estimate rests on assumptions. Written down, they are a shared understanding. Unwritten, they are the vendor’s defence in a later argument.
Why we publish ours
Because the alternative wastes everybody’s time. If your budget is $2,000 and the work is a $90,000 build, both of us want to know that in the first thirty seconds rather than after three meetings and a proposal. It costs us leads we would otherwise have talked to, and it saves us the ones that were never going anywhere.
Our ranges and three worked examples are on the pricing page, and how an engagement actually runs is on the process page. Take the checklist above to us and to everyone else. If a vendor is annoyed by the questions, that is information too.
