Is it a bird? Is it a plane? It’s… delays!

In the middle of every major website project, one question almost invariably drops. 

“Guys, why is this taking so long?” 
The devs have been at it for a while. The designers have been churning out pages after pages, and writers are writing for the brand, and then rewriting for the POCs at breakneck speed. So… what is the delay?

The logical response might be to look for a technical answer. Perhaps the website is too complex. Perhaps there are too many pages. Perhaps the CMS is holding things up. Perhaps the front end development services involved are more complex than they first appeared.

​​Sometimes, of course, that is true. But largely, there is another, considerably less glamorous culprit: Decision-making.

A website can move remarkably quickly when a team knows what it wants, knows who gets to decide, and is willing to make the decision. It can move remarkably slowly when every page becomes a committee meeting. A week lost to “just one more round of feedback” is still a week lost to the project.

“Can we get one more person to look at this?”
“Legal has a few comments.”
“Leadership wants to see another option.”
“Let's revisit the homepage once we have the inner pages.”

Individually, none of these requests sounds unreasonable. Collectively, they can derail a timeline.

The problem isn't feedback itself. Good feedback makes websites better. The problem is unstructured feedback from an undefined set of decision-makers.

When ten people can comment but nobody clearly owns the final call, the project starts moving sideways. A designer takes a call. Someone challenges it. The copy changes. The design changes to accommodate the copy. Development waits. A new stakeholder joins the conversation and questions an earlier decision.

And this isn't always a client-side problem. Agencies have their own bottlenecks too. A brief that wasn't thought through enough at the start, a dependency that wasn't flagged early, a development challenge that wasn't communicated clearly, or feedback that gets lost between teams can create the same kind of drag.

Suddenly, the original piece of feedback is lost in the embers of time, and the project at hand, which felt like a sprint at best, is as daunting as the Berlin Marathon now. 

Websites are very good at attracting opinions. More so than a social media campaign or brand film.

They sit at the intersection of brand, business, marketing, technology, HR, investor relations, leadership, legal and sometimes half a dozen other teams. Everyone has a legitimate reason to care. That doesn't mean everyone needs to approve everything.

A more effective structure is simple: define who contributes, who reviews and who decides.

The brand team might own visual consistency.
The business team might own accuracy.
Legal might own compliance.
Leadership might own the final strategic direction.

Everyone else can still have a voice. They just don't all need veto power.

This distinction matters because website projects are built on a chain of decisions. When one decision remains unresolved, everything downstream can remain unresolved too. For the agency too, everyone working on the project can have a role, but there needs to be clear ownership at every stage. If a problem is spotted, it needs to have a name, an owner and a next step. It can’t sit in someone's inbox waiting for the next catch-up.

When someone asks, “How long does it take to build a website?”, the instinct is to count pages.
Twenty pages? Six weeks.
Fifty pages? Three months.
A hundred pages? Longer.
But page count is only one variable.

A better way to think about a website timeline is as a combination of complexity and certainty.

How many systems need to talk to each other?
How complex are the user journeys?
How much content already exists?
How many stakeholders are involved?
How quickly can they make decisions?
How much of the scope is actually settled?

A relatively large website with a decisive team can move faster than a smaller website where every headline needs three rounds of internal approval.

The irony is that the website can look like the complicated part. But often, it's the organisation behind it.

I can see your nostrils flare up. Unclench your jaw. “Fast” doesn't mean rushing. It means reducing uncertainty early enough that the team doesn't have to solve the same problem twice.

That starts before design. Follow steps, get definitive approval from the final authority at EACH step.

This is also why a good website partner shouldn't simply ask, “What do you want the website to look like?”

The better question is:
“What needs to be decided before we start designing?”

And, equally, the agency needs to be asking: “What do we need to know, own and communicate to keep this moving?”

There is a useful rule for complex website projects: Decide once. Document it. Move forward.

Yes, websites evolve. Ideas improve. New information appears.

But there is a difference between making a considered change and repeatedly reconsidering the same decision because nobody was quite sure who owned it in the first place.

The goal is to make feedback useful, and avoid loops where the final word of approval is a myth.

There isn't one honest answer.

But there is a simple framework that can help make the answer shorter: ALIGN. OWN. DECIDE. FLAG. MOVE.

ALIGN: Before work begins, agree on the scope, objectives, stakeholders, dependencies and what “done” actually means.

OWN: Give every major decision and deliverable a clear owner on both sides. If something is waiting, there should be no ambiguity about who it is waiting on.

DECIDE: Set approval points and decision-makers upfront. Feedback should be consolidated wherever possible, and a closed decision should stay closed unless something materially changes.

FLAG: Don't wait for the next weekly call to surface a problem. If a dependency, delay or change threatens the timeline, say it early, and expect the same transparency from the other side.

MOVE: Once a decision is made, document it and move forward. Don't let every new thought reopen something that has already been settled.

Because getting a website live faster isn't about making the agency work faster, or making the client approve faster. It's about making the entire system work better.

And as it turns out, maybe the website isn't taking too long after all.

Maybe, there are just too many people pressing pause now and again.