What Should a Website Timeline Include?

Every web design proposal has a timeline in it. Most of them are fiction — not because designers lie, but because the number is written before the work that would justify it has even been scoped. "Four to six weeks" in a proposal usually means "we'll find out together."

This isn't an argument for designers to pad their estimates. It's an argument for timelines that specify real things. A timeline is only useful if it tells you what happens, when, and what breaks the schedule. Here's what a real one includes.

The three things every timeline should specify

Milestones with dates. Not "design phase" but "first design review: two weeks after content delivery." A milestone is only real if it has two things: a date, and a name on who's responsible for it. Most projects have five or six of them — kickoff, content delivered, design approved, build complete, review, launch. If you can't list your project's milestones off the top of your head, nobody can.

Client-input deadlines. This is the part that's usually missing, and it's the part that matters most. A huge share of "the designer is slow" complaints are actually "the client was slow and the designer didn't flag it" complaints. Your project's schedule includes your homework: photos, page copy, decisions about services and hours, feedback on mockups. A real timeline assigns those dates to you, the same way it assigns design dates to the designer. The schedule is a shared document or it's a hope.

A launch definition. "Done" is not a milestone. Launch is: the site is live, the forms are tested, the redirects from the old site work, and you've been trained on how to update it. A timeline that ends at "site built" ends before the part where things go wrong.

What "a few weeks depending" actually means

You'll hear this phrase, or its cousins — "it really depends," "typically a couple months." It's not a lie; scope genuinely varies. But as a commitment it's worthless, and you should treat it as the start of the conversation rather than an answer.

The questions that turn a vague estimate into a real one:

A useful comparison point: agencies and established freelancers commonly quote six to twelve weeks for a small-business site, and actual delivery frequently runs longer. Whatever number you hear, ask whether it's the sales number or the delivery number. Good designers know the difference and will tell you. One more useful check is whether the timeline is realistic in the other direction: a timeline that promises a serious website in a weekend isn't confident, it's a template.

What legitimately extends a timeline

When projects run long, it's usually one of five things. None of them are scandals; all of them are foreseeable:

Content. The most common delay in small-business projects, by a wide margin. The site is ready; the words aren't. If you're writing your own copy, budget real calendar time for it — writing five pages of your own website while running your business takes weeks of stolen hours, not an evening. We cover the full client-side workload in what your web designer needs from you.

Feedback latency. A project has maybe six moments where it stops and waits for a human decision. Every day between "mockup sent" and "client replied" is a day the schedule absorbs. Fast, consolidated feedback — one batch of comments, not eleven emails across a week — is the single biggest thing a client does for their own timeline.

Scope additions. "While you're in there, could it also..." — every one of those is a real change to the work, and a real change to the schedule. A quoted change-order process (changes priced before work starts) keeps the timeline honest; see deposits and milestone payments for how that structure works.

Custom functionality. Booking systems, ordering, portals — anything with integrations and edge cases. A five-page brochure site and a site with live availability are different engineering problems, and should be scheduled differently.

Seasonal reality. If your business has a busy season, schedule the build for the slow one — you'll be a faster client, and your designer will be a faster designer. Local tourism businesses already know this logic from their search traffic patterns; it applies to the build schedule too.

What a slip should look like

Projects slip. What separates a professional from a problem is the notification. A good slip sounds like: "The booking integration is taking longer than scoped. New launch date is the 14th; here's what's already done." You get the news proactively, with a revised date, while you still have leverage because a payment is tied to something that hasn't happened yet.

A bad slip sounds like silence that you eventually notice. If the first time you learn the project is late is because you asked, the timeline was never being managed — it was being survived. And if the silence has stretched past a week of missed check-ins, you're not in a schedule conversation anymore; the ghosting playbook is the relevant reading.

The client's side of the schedule

Since half the milestones are yours: deliver content on the date you agreed to, batch your feedback, and when you don't know an answer, say so the same day instead of going quiet for a week to think about it. "I don't know yet, can we decide by Friday" is a schedule-honoring answer. Silence is not.

The clients who are told "you were our fastest project" are never the ones with the biggest budgets. They're the ones who replied the same day.

Before you sign a timeline

Ask for the milestone list, with dates and owners. If the proposal's timeline is one sentence long, ask for the sentence to become a table. Any designer can produce one in twenty minutes, and the exercise of producing it is worth more than the document — it's the moment the estimate becomes a plan.

Questions about how long your project would take? We scope before we quote, and we answer every enquiry personally, within one business day.