Website Project Timeline: Why Yours Will Take Longer Than Quoted

Why do website projects run late? After more than two hundred and fifty builds, the honest answer is that they almost never run late for the reason people expect. The development itself is rarely the problem. Projects run late because of four predictable causes that have little to do with how fast anyone can code: the content is not ready when the build needs it, the gaps between work and approval stretch out, genuine new scope is discovered halfway through, and the project ends up waiting on a third party nobody at the agency controls. Every one of those is foreseeable, and every one is missing from the optimistic week count on the proposal.

That gap between the quoted website project timeline and the real one is not usually dishonesty. It is the difference between estimating the work and estimating the project. The work is the design and the build, and a competent team can estimate that fairly well. The project is the work plus all the waiting around it, and the waiting is where the weeks disappear. This article walks through the four causes of website build delay, and then describes the habit that keeps a project honest once it starts: a fixed-format weekly report that makes slip visible the week it happens rather than the week the launch is missed.

The Quote Estimates the Work, Not the Project

Picture the timeline on a typical proposal. Discovery one week, design two weeks, development three weeks, quality assurance and launch one week. Seven weeks, clean and confident. Now picture the same project drawn as a Gantt chart of what actually happened, and the difference is not that any single bar got longer. The design bar is still two weeks of design. The difference is the white space between the bars. A four-day wait for feedback here, a week of stalled content there, a fortnight blocked on a payment gateway near the end. The work bars barely moved. The project doubled.

This is the single most useful thing to understand about a website project timeline. The estimate on the proposal is almost always an estimate of effort, and effort is the part the agency controls. The calendar duration of the project is effort plus latency, and the latency lives in the spaces the proposal does not draw. A team that hands you seven tidy weeks with no discussion of what happens in the gaps has either never measured its own delivery or is choosing not to mention it. The four causes below are what fills that white space.

Cause One: The Content Was Never Ready

Ask any agency for the single most reliable cause of a blown timeline and most will say content before you finish the question. The build progresses on schedule right up to the point where it needs real material. Real copy, real photography, real product data, real team bios with the right job titles. And the client has not produced it. So one of two things happens, and both cost weeks. Either the project stops and waits, the team gets reassigned, momentum evaporates, and restarting a cold project carries its own tax. Or placeholder text goes in, the design gets approved against words that do not exist, the real copy arrives at a completely different length, and the layout balanced around the placeholder now needs reworking. That rework was never in the quote, because nobody scoped a redesign.

The reason content slips so reliably is that clients consistently underestimate it. Writing twenty-five pages of clear, accurate, on-brand copy is a real project in its own right, competing for the attention of the same busy people who run the business. We have watched a five-page site for a veterinary practice run six weeks instead of three because the owner kept rewriting the about page. The fix is unglamorous. The content has a deadline, the deadline is written into the schedule and tied to a specific milestone, and there is a stated consequence if it is missed. The project either pauses, or proceeds on placeholders with the eventual swap treated as paid work, or the agency is hired to write the copy as a costed line item. What does not work is hoping. Content that is not scheduled is content that is late.

Cause Two: The Build Waits on Approval

The second cause is the one clients rarely see, because it does not look like delay while it is happening. It looks like a quiet week. The agency finishes the homepage design, sends it for review, and then waits. The review takes two days of actual reading and discussion, but it sits in an inbox for nine days because the founder is travelling, or the marketing lead wants the chief executive to weigh in and the chief executive is in back-to-back meetings, or there is a committee and the committee has not met. The work took two days. The phase took eleven. That nine-day gap is pure latency, and it never shows up as anyone being slow at their job.

Approval latency is dangerous because it compounds. A website project has several phase gates, and every gate is another chance for the same wait to recur. A four-day average approval delay across five sign-off points is nearly three weeks added to the timeline, and not one of those weeks was visible as a problem in the moment. The single strongest predictor we have of whether a project lands on time is not budget and not technical complexity. It is whether the client has one named decision-maker with genuine calendar availability and the authority to sign off without escalating. When feedback has to tour an organisation before it counts, the project moves at the speed of the slowest calendar in the building, and that speed is almost always slower than the quote assumed.

Cause Three: Scope Discovered Mid-Build

The third cause is the most legitimate of the four, and it deserves to be treated kindly rather than as a failure. Projects learn things. The founder sees the homepage rendered for the first time and realises the messaging is wrong, or that the site genuinely needs a member portal nobody mentioned at kickoff. This is not the client being difficult. It is the client doing exactly what looking at real work is supposed to make them do. A booking calendar that was never in the original plan can turn out to be the single feature that converts visitors, and refusing to build it on principle would produce a worse website delivered exactly on time.

The problem is not the discovery. The problem is that the discovery was never in the week count, and a member portal is not a free afternoon. It is a data model, authentication, access logic and a set of new templates. When that work is added without the timeline being redrawn, the project carries real effort the original schedule never accounted for, and it will overrun by roughly the size of the thing that was added. The honest response is not to forbid mid-build discovery. It is to make it visible. When something new is found, it gets written down as a change to scope, with its cost and its effect on the launch date stated alongside it. The client then makes a real decision with both numbers in front of them, including the valid choice to launch without it and add it later. A project that grows on purpose is fine. A project that grows by accident is how a website build delay arrives unannounced on the final invoice.

Cause Four: Waiting on Someone Else's Queue

The fourth cause is the one that frustrates everyone, because the agency is ready, the client is ready, and the project still cannot move. It is blocked on a third party that neither side controls. A payment gateway approving a merchant account on its own schedule. A DNS change sitting with the client's previous host, who is in no hurry to help a customer who is leaving. A niche software tool whose integration is misbehaving and whose support replies in business days. A legal review bolted onto the project at week eight because someone in the client's organisation has just remembered data protection rules exist. The work is finished. The project is parked in someone else's queue.

These waits are hard to estimate because their length is genuinely unknowable at the start, but they are not hard to predict in the abstract. We know with near certainty that at least one third-party dependency on any given project will go quiet at an inconvenient moment. The defence is to identify those dependencies during discovery and start the slow ones early rather than treating them as a launch-week formality. Merchant account applications get submitted in week one, not week six. DNS access gets requested and confirmed long before cutover. Integration credentials get tested the day they arrive. None of this removes the risk, because the third party still moves at its own pace, but it converts a launch-week emergency into a manageable wait the schedule saw coming.

The Fixed-Format Weekly Report That Keeps It Honest

Understanding the four causes does not stop them. What stops a quiet slip from becoming a launch-day shock is a reporting habit, and the habit we have settled on after enough projects is a weekly report in a fixed format that never changes. Same five lines, every Friday, no exceptions, whether the news is good or bad. The fixed format is the entire point. A free-text project update lets an agency wrap a slipping project in cheerful prose, and a client reading cheerful prose has no way to tell a healthy project from a sick one. A fixed line that must contain a specific answer removes that hiding place.

The five lines are these. Done this week, which states concretely what shipped, not what was worked on. Planned for next week, which states what will ship next. Blocked on you, which names the exact thing we need from the client and the date we need it, with the plain warning that a missed date moves the timeline. Blocked on others, which names every third-party dependency we are currently waiting on. And timeline status, stated as a number and only as a number: on track, or slipped by three days, or recovered two of the four days lost. The word "fine" is not permitted on that last line. Each of the four causes of delay has a line that exposes it. Late content and slow approvals show up under blocked on you. Third-party waits show up under blocked on others. Discovered scope shows up the week it is found, in the timeline number. A client who reads this report every Friday cannot be surprised at the end, because the slip was visible in week three, in writing, with a figure attached.

How WitsCode Runs the Timeline

We are the last-mile developer for vibe coders, which means a lot of our projects begin with a prototype, a deadline and a real business waiting on launch, and the deadline is usually the part under the most pressure. We do not protect it by quoting an optimistic week count and hoping. We protect it by scoping the project rather than just the work, naming the four likely sources of slip during discovery, and then sending the fixed-format weekly report every Friday so the timeline stays honest while the build runs. If it slips, you will know the week it slips and you will know by how many days, because that number is on the report whether we enjoy writing it or not.

If you have a quoted timeline on your desk and you are not sure whether it estimated the project or just the work, send it to us. We will give you an honest read on where the white space between the bars is hiding, and what it would take to land the launch you have actually been promised.