When a website takes three months instead of one, the natural assumption is that the agency was slow. Sometimes that is true. But when we measured our own projects, a different picture emerged.
Across our website and landing page builds, 61% of the elapsed time between the first draft and go-live was time spent waiting on the client side: waiting for feedback, content, logins, approvals and decisions. The remaining time was our team working, preparing the next version or waiting on third parties.
This article is not about blame. Clients have businesses to run, and our side has its share of delays too. It is about understanding where the time goes, so both sides can plan better.
How we measured
Each project in our system is a chain of tasks: first draft, revision rounds, go-live. For each gap between tasks, we looked at who the project was waiting for. If we had sent a draft and were waiting for feedback, that gap counted as client waiting time. If feedback had arrived and we were implementing it, it counted as team time.
The typical project versus the total
For a typical WordPress project, the numbers look balanced: a median of 16.5 days of team time and 13.5 days of client waiting in the chain. For landing pages, 8 versus 5 days. For Shopify stores, 21 versus 14 days.
So why does client waiting add up to 61% overall? Because the long delays are almost all on the client side. In our WordPress projects, a quarter of projects waited on the client for more than 48.5 days in total, and the longest single pause in a typical project was 11.5 days. Team time varies much less. A handful of projects that paused for months shift the total enormously.
Where the waiting happens
From the chatter and feedback in our projects, client waiting falls into five groups:
1. Content
Texts, photos, videos, testimonials, team information. The most common and the longest. WordPress projects with missing content took a median of 74 days versus 26 days without.
2. Feedback
Reviewing a draft takes an hour or two, but finding that hour – and gathering colleagues' opinions – can take weeks.
3. Access
Hosting logins, domain registrar accounts, Google accounts, ad accounts, API keys. Often the person who has them is not the person running the project.
4. Decisions
Which languages? Which booking rules? Which shipping countries? Which return policy? Decisions that seem small block configuration.
5. Internal approvals
A partner, board or head office that must sign off. Often unplanned, and often during holidays.
Where our side causes delays
To be fair, not all delays are client-side. On our side we see:
- Clarifying questions that could have been asked earlier
- Busy periods when several launches happen at once
- Technical issues such as integrations or hosting problems that take investigation
We track these too, and they are part of the remaining share.
How to shorten client waiting time
| Waiting type | What helps |
|---|---|
| Content | Deliver before kickoff, or let us draft texts for your review |
| Feedback | Block review time in your calendar when the draft is due |
| Access | Collect all logins in the first week, even if needed only at launch |
| Decisions | Decide languages, features and rules at kickoff |
| Approvals | Involve the final approver in the kickoff |
What we do to reduce waiting
- Kickoff checklists listing every piece of content and access needed, with owners
- Review deadlines sent with each draft, so there is a clear date to aim for
- Follow-ups when a project has been waiting for a few days
- Partial progress: where possible we continue on parts that do not depend on the missing input
- Phase two lists so new ideas do not reopen the current round
Why this matters for cost too
Long pauses cost more than time. Every restart needs context: re-reading feedback, checking what changed, re-testing. Missing content, which causes the longest pauses, is a good example: WordPress projects affected by it logged a median of 32.6 in our timesheets, compared with 13.5 for projects where content was ready. Placeholders get built, replaced and adjusted, and every pause means re-reading the history before work can continue.
When a pause is the right choice
Sometimes pausing is sensible: a rebrand in progress, a product not yet ready, a busy season. In those cases we agree a restart date and park the project cleanly, rather than letting it drift.
FAQ
Do you charge for waiting time?
No. Waiting time is not billed. But long pauses can mean extra work when a project restarts, and fixed timelines may need to be re-planned.
What is a reasonable review time for a draft?
A few working days is ideal. For larger sites, a week with one consolidated document works well.
Can you start without all content?
Yes, with placeholders. It helps us move, but launch will still depend on final content.
What is the one thing to prepare before a website project?
A named decision maker with time to review. Content and brand assets matter, but in our experience the projects that stall are the ones where nobody can approve a draft within a few days.
How many hours of work go into a typical website?
Our WordPress projects logged a median of 15.2 hours, with the middle half between 9.3 and 32.1 hours. Calendar time is much longer than working time, because most days are spent waiting for inputs and decisions.
Where the numbers come from: our own project records in Odoo – 233 finished projects, 909 tasks and about 4941 logged hours, mostly from 2025–2026. Durations are calendar days from kickoff and we quote medians, so one unusually long project does not distort the picture.
Planning a consulting project?
If you want a realistic plan for your own project, book a short call with our team and we will walk you through the phases, what we need from you and where projects like yours usually lose time. You can also browse finished work in our consulting portfolio.
Comments