Try SpecBot free — keep your assumptions in your offers, reused in every proposal.
The assumptions section is one of the most overlooked parts of a freelance proposal. Many freelancers skip it entirely — and then discover mid-project that something they took for granted isn’t actually true, causing delays, scope disputes, or uncompensated extra work.
A clear assumptions section makes implicit expectations explicit. Here’s what to include and why it matters.
What an assumptions section does
An assumption is a condition you’re counting on being true for your scope, timeline, and price to hold. It’s the answer to: “What am I relying on to deliver this project as proposed?”
When you list your assumptions:
- Both parties know what they’re agreeing to
- Scope disputes have a clear reference point
- Timeline slippage caused by missed assumptions can be discussed professionally
- Surprises (that aren’t really surprises) are handled before they become conflicts
The assumptions section isn’t defensive or adversarial — it’s collaborative. It shows you’ve thought through the project and are being transparent about what’s needed from both sides.
Categories of assumptions to include
Client-provided inputs
What does the client need to provide for the project to proceed as scoped?
Common examples:
- Copy/text: “Client will provide finalized copy for all pages prior to design starting. Copy revisions after design is underway may affect timeline and pricing.”
- Assets: “Client will provide high-resolution logos, photography, and brand assets. Stock photography is not included in this scope.”
- Feedback windows: “Client will provide consolidated feedback within 5 business days of each deliverable. Delays beyond this window may shift the final delivery date.”
- Access and credentials: “Client will provide access to [CMS, analytics, domain registrar, hosting] within 3 business days of project kickoff.”
- Subject matter input: “Client will be available for a 30-minute review call per article to provide technical accuracy input.”
These assumptions shift responsibility clearly — the project moves at the client’s speed, within the scope you defined.
Technical and platform assumptions
What’s being assumed about the technical environment?
Common examples:
- “This proposal assumes the current WordPress installation is on a supported version (5.x or later). Significant technical debt or outdated plugins may require additional remediation work.”
- “This scope assumes a standard Shopify plan. Additional functionality requiring Shopify Plus is out of scope.”
- “Development is scoped for modern browsers (current versions of Chrome, Firefox, Safari, and Edge). Legacy browser support is not included.”
- “Server and hosting setup is assumed to be handled by the client or their hosting provider. Deployment assistance is included, but provisioning infrastructure is not.”
Scope boundaries
What’s included vs. adjacent to the scope?
Common examples:
- “This proposal covers the redesign of the 7 pages identified in the discovery call. Additional pages discovered during the project will be scoped separately.”
- “Content migration of existing posts is not included. The new CMS structure will be built to receive content; migration is a separate engagement.”
- “Photography and illustration are not included. We’ll use [client-provided assets / stock imagery within X budget].”
Timeline assumptions
What conditions need to be met for the timeline to hold?
Common examples:
- “Timeline assumes a [date] start. If the project starts after [date + 2 weeks], the delivery timeline will be adjusted accordingly.”
- “Timeline assumes client feedback is received within the windows specified in the project plan. Extended feedback windows push the final delivery date by an equivalent duration.”
- “Timeline is based on current workload. Changes in project scope may affect delivery dates.”
How to write assumptions that actually protect you
Be specific, not vague
Weak assumption: “Client will provide necessary materials.” Strong assumption: “Client will provide final, approved copy for all 7 pages by [date]. Copy changes after design completion may require a revision fee of $[X].”
Specificity means both parties understand exactly what the assumption requires.
Name the consequence of a missed assumption
If an assumption isn’t met, what happens? Naming this makes the protection real:
- “…may affect timeline” (delivery date can be extended)
- “…may require a change order” (additional cost)
- “…will be treated as out of scope” (not included)
Without naming the consequence, an assumption is just a note. With the consequence, it’s a scope protection.
Include only material assumptions
Not every assumption needs to be listed. Focus on the ones that, if they turned out to be wrong, would materially affect your scope, timeline, or pricing. Listing 15 minor assumptions dilutes the section and makes it look like you’re trying to avoid accountability for everything.
A good assumptions list typically covers:
- Client-provided inputs that are required to start or complete work
- Timeline dependencies that are outside your control
- Technical conditions that affect scope
- Scope boundaries that are adjacent to the main deliverables
Presenting assumptions professionally
The assumptions section should be framed as collaborative, not defensive:
“The following assumptions are built into this proposal. If any of these conditions differ from what we’ve discussed, I’d like to know before starting so we can adjust the scope or approach accordingly.”
This framing makes assumptions a two-way communication tool. You’re not building in escape clauses — you’re being transparent about what you need to deliver what you’ve promised.
When to reference assumptions during the project
When a project hits a snag traceable to a missed assumption, refer back to the proposal professionally:
“Based on the assumptions in our proposal, I expected [X]. Since [Y] is the situation instead, here’s how I’d like to handle it: [change order / timeline adjustment / scope discussion].”
The assumptions section gives you a starting point for this conversation that’s grounded in the original agreement, not in memory or interpretation.
Start free on SpecBot — SpecBot turns your offers into proposals clients accept in one click, with a signed PDF for both sides. Free is 3 proposals a month with every feature; Pro is unlimited proposals at €12/month, or €9/month billed yearly. Write them in the web app, by voice, or inside ChatGPT and Claude.