A software quote is usually the first real document you get from a development team, and often the last one anybody reads closely. It sets the price, the scope and, quietly, who carries the risk when something turns out to be bigger than expected.
You do not need to read code to check one. You need to know what a good quote looks like, and what is missing from a weak one. These seven questions will get you most of the way.
1. Could someone else build from this?
Read the quote as if you were handing it to a different team. Could they tell what to build? A good quote describes the product in terms you recognise: the screens, what each user can do, what happens to their data. A weak one lists technologies (“React Native, Node, Postgres”) and a total.
If the scope only makes sense to the people who wrote it, you cannot hold them to it.
2. What is out of scope?
The most useful line in any quote is the one that says what is not included. Admin tools, app store submission, email, payments, hosting, analytics, accessibility and ongoing support are the usual surprises. If they are not mentioned either way, ask. Silence now becomes a change request later.
3. How will you know each part is done?
“Build the login” is a task. “A user can sign up with email, verify it, and sign in on iOS and Android” is something you can check. Ask for every major item to end on a test you could run yourself, or at least watch. When “done” is defined up front, nobody argues about it at the end.
4. Who owns what?
Your code, your domain, your app store listings and your cloud accounts should be in your name from the first day. Ask directly: whose account will the app be published under, and who holds the keys? If the answer is “ours, for now”, that is a conversation to have before you sign, not after.
5. How is change handled?
Every project changes. The question is how. Look for a simple rule: what counts as a change, how it is priced, and that you agree to it before the work is done rather than after. “Billed at our hourly rate” with no estimate attached is not a rule.
6. How is AI being used, and who benefits?
Many teams now use AI tools to write and test code. That is a good thing when it is done well: it can make work faster and more thorough. But it changes the economics. If a task that used to take a day now takes an hour, an hourly quote and a fixed-scope quote can tell very different stories. Ask how the team uses AI, how they check its output, and whether the price reflects the work or the hours.
7. What happens after launch?
Software needs looking after: security updates, operating system changes, store policy changes. Ask what is included after launch, for how long, and what it costs if you want more. Also ask what you would need to take the work elsewhere: documentation, access, and a clean handover.
A quick way to use this list
Go through the quote with these seven questions and mark each one clear, vague or missing. You will not need a technical background to see the pattern. A quote that is clear on most of them is usually written by a team that has thought the project through. A quote that is vague on most of them is a price, not a plan.
None of this means the team is doing anything wrong. Most of the gaps we see come from teams that were never asked. Asking is your job; answering clearly is theirs.