"How long will it take?" is one of the first questions in any web project conversation, and it's also the one where expectations go wrong most often.

The developer says six weeks. The client hears six weeks. Eleven weeks later, everyone is frustrated. The developer thinks the client kept changing requirements. The client thinks the developer was slow. Both are partially right, and both missed the real issue: scope creep, feedback cycles, and content delays are predictable — they just never got built into the estimate.

Here's an honest breakdown of where the time actually goes.

The estimate is usually for the work, not the project

When a developer gives you a timeline, they're typically estimating the active development time — the hours they'll spend writing code. What they're often not counting is everything else:

  • The back-and-forth to clarify requirements that weren't fully defined
  • Waiting for content, photos, and copy that the client is providing
  • Revision cycles after the client sees the first design
  • The gap between "functionally complete" and "polished enough to launch"
  • Testing across devices and browsers
  • Final tweaks and fixes that always emerge during QA

That stuff is real time. On a project scoped at four weeks of development, those things can easily add another two to four weeks to the actual calendar.

Content is usually the longest delay

This is the one nobody wants to say directly, but it's consistently true: clients are the most common source of delays on web projects.

Not because clients are difficult. Because they're busy. And because "writing the copy for your new website" is the kind of task that's easy to defer when you have a business to run.

A project that's waiting on your headshots, your service descriptions, your team bios, and your case study text is a project that's not moving. The developer can't design around content that doesn't exist. The launch can't happen if the pages aren't written.

If a developer doesn't nail down a content deadline upfront, both parties are setting themselves up for a delay that's uncomfortable to attribute to either side.

Scope creep is rarely obvious in the moment

Scope creep doesn't usually show up as a big new request. It shows up as a series of small ones.

"Can we add a pop-up for newsletter signups?" "Can the team page have bios that expand when you click?" "Can we add a filter to the portfolio?" "Can the contact form send a confirmation email?"

Each of these is individually reasonable. Together, they can add a week or two to the project without anyone flagging that the scope has changed. By the time everyone notices the timeline has slipped, there's been so much incremental addition that it's hard to point to any single cause.

The fix is a formal change process — anything outside the original scope gets scoped separately with a timeline and cost estimate before it's added. Developers who don't do this are doing you a disservice, even if it feels more flexible in the moment.

Feedback cycles add up fast

On a typical six-week project, there might be three major review points: wireframes, design, and pre-launch review. If each of those takes a week to get feedback — because the client is busy, because stakeholders need to align, because feedback goes through one more round of internal revision — that's three weeks added to the calendar.

Some of this is unavoidable. But setting clear feedback windows upfront ("we'll need your design feedback within three business days of sharing") moves projects along significantly. Without that expectation set, "I'll look at it this week" often means "I'll look at it when I get to it."

What a realistic timeline actually looks like

For a small business website of moderate complexity — five to eight pages, custom design, content management — I typically scope eight to twelve weeks from kickoff to launch. That includes:

  • One to two weeks of discovery and content gathering
  • Two to three weeks of design
  • Three to four weeks of development
  • One to two weeks of review, revisions, and QA

Some projects move faster. Some take longer. The variables are almost always the same: how defined the requirements are upfront, how quickly content is provided, and how fast feedback comes back.

What you can do to keep a project on track

If you're about to start a web project:

Get your content ready before the project starts. Write the copy, collect the photos, finalize the messaging. The more of this you can hand over at kickoff, the faster things move.

Set aside time in your calendar for feedback. Treat design review like a meeting, not an open-ended task.

Separate "must have for launch" from "would be nice." Scope discipline from the client side is just as important as scope discipline from the developer side.

And ask the developer upfront: "What typically causes projects to run over, and how do you handle that?" The answer tells you a lot. There's a longer list of questions worth asking before you hire anyone — this one should be on it.

If you want to talk through a project and get a realistic read on timeline and scope, reach out. I'd rather give you an accurate picture upfront than a comfortable one that doesn't hold.