- project management
- web development
- buyers guide
Why Your 3-Month Website Project Took 9 Months
It's almost never the code. Here's where the months actually go — and the three decisions that prevent most of it.
Md Ariful Islam
4 min read
Almost every website project overruns.
If you've been through one, you probably came out of it believing your developer was slow, or that web projects are just like that. Neither is quite right.
I've watched this happen from the inside many times. The code is almost never the reason. Here's where the months actually go.
1. Waiting for content
This is the biggest cause, by a wide margin.
The quote assumed copy and photos would arrive in week two. It's week nine and there's still placeholder text on four pages.
Why it happens: nobody was assigned. The developer assumed the client would write it. The client assumed it was included. Neither said so out loud, because at kickoff everyone is optimistic and content feels like a detail.
It isn't a detail. It's the thing the whole website is made of.
What it costs: anywhere from two weeks to three months. And it's worse than idle time, because the developer moves on to other work and has to come back and re-learn your project.
The fix, and it takes ten minutes: name a person and a date, in writing, before anything starts. Not "marketing will handle it." A name.
2. Too many people approving things
Two decision-makers is normal. Three is manageable.
Five means every round of feedback has to survive five sets of preferences. Someone likes the blue. Someone finds it cold. Someone's on holiday. Someone joins in week six with opinions about week two decisions.
Rounds that should take two days take two weeks.
Nobody is being difficult. It's arithmetic — more approvers, more rounds, more time per round.
The fix: one person owns the decision. Others advise. Write down who that is at the start, when it isn't personal yet.
3. Scope arriving quietly
Nobody says "let's add an online shop." That would get noticed and re-quoted.
What happens instead is "could we just add one more page?" Eleven times. Each one is genuinely small. Together they're a month.
The word "just" is the tell. "Just a small change." "Just one more thing." When you hear it three times in a week, the scope is moving and nobody has said so.
The fix: keep a visible list of what's included. New requests go on a second list for after launch. Not a refusal — a queue. Most things on that second list turn out not to matter.
4. Nobody agreed what "finished" means
This is the quietest one and the most damaging.
Without a written definition, a project doesn't finish — it just gradually stops. There's always one more tweak, one more page, one more round of polish. It ends when everyone runs out of energy, and that date was never on any plan.
The fix: write down what done looks like before you start. "All pages live, forms tested, team trained, load time under 2 seconds on mobile." Specific enough to argue about. Then you can point at it.
5. The decision that arrives three months late
A product photo shoot that hasn't been booked. A legal review nobody scheduled. Login details for a system the site needs to connect to, held by someone who left.
Each one stops work completely.
The fix: at kickoff, list everything outside the developer's control that the project depends on, with an owner and a date for each. Half of them will slip. At least you'll know which half.
What this means for your quote
When you get a three-month estimate, it's usually a real estimate — of the building.
It assumes content arrives on time, feedback comes back in days, scope holds, and outside dependencies land. Those assumptions are rarely stated, and they're the ones that break.
So when you're comparing quotes, ask: what are you assuming about me?
A good developer has a list ready. It's one of the better signals you'll get about whether they've done this before.
Three decisions, one afternoon
None of these are technical. You can make all three before a single line of code is written.
- Name who writes the content, with a date. A person, not a department.
- Name who signs off. One person.
- Write down what "done" means. Specifically enough that you could disagree about whether you've reached it.
I'd guess these three save more time on a typical project than any technical choice either of us makes.
And if a developer pushes back on doing them — that tells you something too.
Starting a project and want a second opinion on the plan? Send me the scope you've been quoted. I'll tell you what I'd worry about in it.
