A project proposal timeline isn’t just a scheduling tool. It’s part of how the client evaluates your competence. A vague timeline signals you haven’t thought through the work. A realistic, phase-by-phase timeline signals that you’ve done this before, you know how it unfolds, and you’ve accounted for the parts that typically go wrong.
Why the timeline matters beyond scheduling
Clients read timelines with two questions in mind. First: does this feel realistic? Second: is this person telling me what I want to hear, or what’s actually true?
Freelancers who consistently win on value — not on price — tend to write timelines that answer both questions honestly. They don’t compress a 6-week project into 4 weeks to win the bid. They explain why 6 weeks produces better work, and they map the phases in a way that makes the time feel purposeful rather than padded.
A well-built timeline also shapes client behavior. When you note that “Phase 2 begins when client provides brand assets” or “revision turnaround assumes 3-business-day client response window,” you’re setting expectations that reduce mid-project friction.
Building the timeline: start with phases, not tasks
The most common mistake is trying to build a timeline bottom-up — listing every task and estimating hours. That produces a project plan, not a proposal timeline.
Instead, work top-down:
-
Identify the major phases of the project. For a website build: Discovery, Design, Development, QA, Launch. For a brand identity project: Research, Concepts, Refinement, Final Delivery. Name them descriptively, not generically.
-
Estimate duration per phase. Work from experience. How long does your discovery phase actually take? Build in realistic buffer — at least 20% per phase. Projects always encounter small surprises: the client’s assets are lower resolution than expected, a stakeholder has conflicting feedback, a third-party tool behaves differently than documented.
-
Identify client touchpoints. Where do you need something from the client? Asset delivery, feedback, approvals? Mark these explicitly. They’re the points where the timeline is most vulnerable.
-
Add up the total. The total project duration becomes your headline number in the timeline section.
The right level of detail
For a proposal, phases are the right level. Tasks are too granular — they’re noise to most clients, and they create the impression that you’ll be held to a minute-by-minute schedule.
A five-phase timeline:
| Phase | Description | Duration |
|---|---|---|
| 1. Discovery | Kickoff call, asset review, scope confirmation | 3 days |
| 2. Architecture | Sitemap, content structure, wireframes | 1 week |
| 3. Design | Visual design for all pages (desktop + mobile) | 2 weeks |
| 4. Revisions | Two rounds of client feedback incorporated | 1 week |
| 5. Delivery | Final files in all agreed formats | 2 days |
Total: approximately 5 weeks from project start
Note: Timeline assumes client feedback is returned within 3 business days of each deliverable. Delays in feedback will extend subsequent phases.
That last note is doing important work. It’s not aggressive or accusatory — it’s accurate. And it means you have a documented basis for timeline adjustments if the client is slow.
Calendar dates vs. relative durations
Proposals should use relative durations (“2 weeks”), not calendar dates (“June 3–14”).
Calendar dates create problems because:
- The contract might be signed later than expected
- The kickoff might shift due to client availability
- Any change in start date makes every subsequent date wrong
Relative durations stay accurate regardless of when the project actually starts. Calendar dates belong in the project contract, after the start date is confirmed.
The one exception: if the project has a hard external deadline (a product launch, a trade show, a regulatory date), put that deadline in the proposal with a note about what start date it requires. That conversation is better to have before the contract than after.
How to handle scope creep using your timeline
When a client requests work that wasn’t in the proposal, your timeline is your first line of defense.
Response formula: “That’s a good addition. It’s not in the scope we agreed to in the proposal — adding it would extend the timeline by approximately [X days/weeks] and add [fee]. Want me to draft a change order?”
This response is neutral, factual, and doesn’t make the client feel bad for asking. It points to the proposal timeline as the reference point. And it gives you a clear process for handling the change professionally rather than absorbing it silently and resenting it later.
Matching timeline detail to project size
| Project size | Phases | Format |
|---|---|---|
| Under $3K | 2–3 | Simple bullet list or 1-row table |
| $3K–$10K | 3–4 | Table with phase/description/duration |
| $10K–$30K | 4–6 | Table + client dependencies noted |
| Over $30K | 5–8 | Table or Gantt chart, milestone-based |
More complex projects don’t always need more phases — they need more precision about what each phase produces and what triggers the next one.
Tools like Waco let you attach timeline details directly in the proposal document, so the client sees the phase breakdown alongside the pricing. When they sign, the timeline is already part of the record.
Ready to send stronger proposals?
Build, send, and track proposals in one place so follow-up is easier.
Start your free trial →
