Last month, a friend sent me three quotes for the same project. She runs a small physical therapy clinic and wanted an online booking system. Same idea. Same short email describing what she wanted. Three proposals came back: one for $9,000, one for $24,000, and one for $52,000.
She asked me the question I hear more than any other: "Which one is right?"
Here is the honest answer. None of those numbers mean anything on their own. A price only makes sense next to the list of what it buys. And that is the real skill you need when a proposal lands in your inbox. Not judging the number. Reading the document behind it.
I have read hundreds of these proposals, from both sides of the table. Here is how to read one like someone who has seen a hundred of them, even if you have never written a line of code.
Why "The Same Project" Gets Three Different Prices
When her three quotes came in, I asked to see all three side by side. The cheapest one covered a basic calendar where patients could pick a time slot. That's it. No text reminders, no online payment, no connection to her existing patient records.
The middle quote added text and email reminders, plus a payment option. The most expensive quote included all of that, plus a login for each staff member, plus extra security work, because health information carries stricter privacy rules than most business data.
Three companies did not disagree about price. They disagreed about what "an online booking system" means. Vendors were not pricing the same job. They were pricing three different jobs that happen to share a name. That is exactly why the document matters more than the number at the bottom of it.
The Five Parts of a Proposal That Actually Matter
A solid proposal, whether it is two pages or twenty, should answer five questions. Once you know to look for these five things, everything else on the page becomes easier to ignore.
Scope. This is the actual list of what gets built: which screens, which features, which systems it connects to. Not a vague description. A list you could hand to someone else and say, "build exactly this." If a proposal describes an outcome ("a website that grows your business") instead of a list of deliverables, that is a gap, not a style choice.
Phases. Most projects get broken into chunks, often called phases or sprints. Each phase should produce something you can actually see or use, not just "more progress." Think of phases like the rooms in a home renovation: you don't sign one contract for "renovate the house." You get a plan for the kitchen, then the bathroom, then the basement, each with its own timeline.
Assumptions. This section states what the developer is taking on faith so the price holds. Common examples: "we assume you will provide product photos," or "we assume one round of feedback per phase." Assumptions protect both sides. If reality doesn't match an assumption, that is when a fair conversation about extra cost happens, instead of a surprise.
Exclusions. This is the single most valuable section in the whole document, and the one most owners skip. It spells out what is not included. Content writing, ongoing maintenance, training your staff, translating the app into another language, these often sit outside the core build. A good vendor tells you this upfront. A vague vendor lets you find out later.
Payment milestones. Payments should tie to finished, checkable work, not just to dates on a calendar. A common pattern: a deposit to start, one or two payments tied to finished phases, and a final payment at launch. If a proposal asks for most of the money upfront with little work delivered in between, that is worth a direct question.
Five Vague Phrases That Should Make You Pause
Some wording sounds reassuring but actually commits to nothing. Here are the phrases I see most often, and what to ask instead.
- "Ongoing support included." Included for how long? How many hours a month? What counts as support versus a new feature? Ask for a number and a definition.
- "All features discussed in our meeting." This means the list of what you get lives in someone's notes, not in writing. Ask for the itemized list, in the document, before you sign.
- "Standard integrations." Standard to whom? Ask which specific tools it connects to, by name.
- "Flexible timeline." Flexible is fine for a hobby project. For a business decision, ask for a start date, an end date, and what happens if either side causes a delay.
- "Final price may vary based on complexity." This tells you the number in front of you is not really the number. Ask what would trigger a change, and by roughly how much.
None of these questions require any technical knowledge. They just require refusing to accept a sentence that sounds nice but promises nothing specific.
How to Compare Two Proposals Fairly
You cannot compare two quotes honestly until you compare the same job. Here is a simple way to do it without any technical background.
First, list every feature mentioned in either proposal on one page. Then mark, feature by feature, whether each vendor included it, excluded it, or didn't mention it at all. Silence is not the same as inclusion. If one quote is $15,000 cheaper but is also silent on five features the other quote covers, you are not looking at a discount. You are looking at a different, smaller project.
Second, ask both vendors the same three questions in writing: What exactly is excluded? What do you assume about my involvement during the project? What happens if I need something changed halfway through? The quality and specificity of the answers tells you more than the price does.
Third, price out your must-haves separately from your nice-to-haves. A vendor who is expensive on the full wish list might be very competitive once you strip the project down to what you actually need for launch.
This is also the point where a short, paid discovery phase earns its cost. It forces vague ideas into a specific plan before anyone commits to a large number. I wrote about how that works in more detail in the discovery phase of a software project.
Back to the Three Quotes
My friend went back to all three vendors with one question: "Can you send me an itemized list of exactly what's included and what's not?" One answered within a day, with a clear document. One took a week and sent something vague. One never itemized it at all.
She didn't pick the cheapest quote or the most expensive one. She picked the vendor who could explain, in plain language, exactly what she was buying. That is usually the right way to decide, once the document in front of you actually says something.
If a proposal in your inbox still feels like it's written in a language you don't speak, you don't have to figure it out alone. And if you haven't picked a vendor yet, it's worth reading how to choose a software development partner before you request quotes at all — it changes what you should expect to see in the proposals that come back.