A freelance developer quotes a client $6,000 for an e-commerce build. Three months later, she delivers the site and invoices $9,200 because the actual work required 53 hours more than expected. The client refuses to pay the difference: “You quoted me $6,000.” She argues it was an estimate, not a fixed price. There’s nothing in the document that says either way. This dispute ends in a partial payment, a lost client, and a lesson she didn’t need to learn expensively. The document she sent was ambiguous. This post makes sure yours isn’t.
Most freelancers use “quote” and “estimate” interchangeably. They’re not. The difference isn’t just vocabulary, it’s a legal and practical commitment that determines who bears the risk when a project takes longer than expected.
What a quote actually means
A quote is a fixed-price commitment. When you quote $8,500 for a website, you are saying: this work, as defined, for this price, period. If it takes you 30 hours, you made a great margin. If it takes you 90 hours, that’s your problem.
Quote signals in language:
- “This quote covers the following scope for a fixed fee of $8,500.”
- “Total: $8,500 (fixed price, inclusive of all described deliverables)”
- “The project will be completed for $8,500, regardless of hours required.”
A quote accepted by the client is a binding agreement to deliver at that price. Your only recourse if the project expands is a change order, a written amendment covering out-of-scope work at an additional fee.
When to send a quote:
- Scope is clear and defined (you’ve had a discovery call, reviewed specs, asked the right questions)
- You’ve priced similar work before and have reliable time estimates
- The deliverables are concrete and countable (5 pages, 3 videos, 1 brand identity)
- You’re confident you’re not missing any significant hidden complexity
What an estimate actually means
An estimate is an approximation. The final price may be higher or lower. It’s appropriate when you can’t fully know the scope until you’re inside the work.
Estimate signals in language:
- “This estimate reflects expected scope. Final billing will be at $150/hour based on actual time logged.”
- “Estimated investment: $8,000–$12,000. Actual cost may vary based on revision rounds and final scope.”
- “This is a budget estimate only, a fixed quote can be provided after a discovery session.”
An estimate that comes in under the high end pleases the client. An estimate that comes in significantly over it needs to be managed, not because it’s wrong, but because the client may have been anchoring to the bottom of your range.
When to send an estimate:
- Scope is genuinely uncertain (software with undefined requirements, research projects, open-ended consulting)
- You’re bidding on work before a proper discovery call
- The client has asked “roughly what would something like this cost?” before any briefing
- Significant third-party variables exist (client needs to supply assets, approvals depend on third parties)
The riskiest document in freelancing is an estimate with no stated range and no billing-method language. It reads like a quote to the client, but you intended it as an approximation. Ambiguity always resolves in whoever has the most leverage, and after the work is done, that’s the client. Be explicit about which document you’re sending.
The exact language to use for each
You don’t need legal training to protect yourself. You need one sentence at the top of the document.
For a quote:
“This is a fixed-price quote. The total investment for the scope described below is $X. Scope changes will be covered by a separate change order.”
For an estimate:
“This is a budget estimate based on expected scope. Final cost will be billed at $[rate]/hour based on actual time logged, not to exceed $[ceiling] without written client approval.”
The “not to exceed” clause is powerful for estimates, it gives the client a ceiling without locking you into a fixed price. You’re saying: I won’t guess my way into a loss, but I’ll cap your exposure at a number you can budget for.
What happens when scope expands on each type
The type of document you sent determines who owns the overrun.
If you sent a quote and scope expands: You’re protected, but only for work that falls outside the quote’s defined scope. Issue a change order before doing the additional work. A change order is a simple document: “Change Order #1, This adds [deliverable] to Quote QT-047. Additional fee: $1,200. Client approval required before work begins.” If the client refuses the change order and still expects the additional work, you have grounds to stop work and enforce the original quote scope.
If you sent an estimate and the project runs over: You need to communicate proactively. Don’t wait until the invoice to reveal the overrun. At 75% of the estimated budget, notify the client: “We’re approaching the high end of the original estimate. Current hours: 61 of approximately 75 estimated. I wanted to flag this before we complete the remaining sections so we can discuss how to proceed.” This is not a surprise. A surprise invoice overrun is the version that causes disputes.
If you sent an ambiguous document and the project runs over: You negotiate from weakness. The client has a reasonable expectation that they won’t pay significantly more than what the document suggested. This is the situation the developer in the opening scenario was in, and it’s entirely preventable.
The two-line rule
Before sending any pricing document, look at it and answer two questions:
- Does the document explicitly say whether it’s a fixed price or an approximation?
- Does the document clearly state what is and isn’t included in the scope?
If either answer is no, you’re sending an ambiguous document. Add two sentences and both answers become yes. The cost of that clarity is 30 seconds. The cost of ambiguity is a disputed invoice that ends client relationships and unpaid work.
Ready to send stronger proposals?
Build, send, and track proposals in one place so follow-up is easier.
Start your free trial →
