Display preferences

Text size
100%
Process6 min read

How Long Does a Website Take? The Honest Answer, by Type of Site

How long building a website really takes: real ranges by type, what actually causes delays (hint: not the code), and how to shorten it.

"How long will it take?" is always the second question, right after "what does it cost". And the honest answer — the one nobody likes giving — is that the part which depends on me is usually the shorter one.

I can tell you exactly how long my work takes. What I can't promise is how long it'll take you to settle on the headline for your homepage. And in most projects that run longer than expected, that's precisely where the clock stopped.

The Ranges, Without the Gloss

From the moment content and branding are in hand — not "roughly", actually in hand:

  • Landing page — 3 to 7 working days. One page, one message, one form.
  • Small brochure site (4–6 pages) — around two to three weeks.
  • Brochure site with a CMS you update yourself — three to five weeks, depending on how many content types there are.
  • Online store — a month and up, often more. Not because of the design, but because of what's wired into it: payments, invoicing, delivery, stock. Each of those connections is a test in its own right, and I went into why in the stores guide.
  • Making an existing site accessible — days to weeks, entirely dependent on what the first audit turns up.

Note the opening condition: "from the moment content and branding are in hand". That isn't a footnote, it's the clause that decides everything.

What Actually Causes Delays — and It's Almost Never the Code

Here's what holds projects up in practice, in order of how often it happens:

1. There's no content. A site skeleton sits finished, waiting three weeks for copy. This is the number one cause, by a wide margin.

2. There are no images, or the images are bad. Blurry phone shots of the product, a logo that exists only as a small JPG from 2014, and not one photo of the team. Good photography changes a site more than any effect.

3. Too many decision-makers. When four people must approve every headline, each round takes a week. A project with one contact who decides moves twice as fast.

4. A change of direction mid-way. "Actually, should we add a store too?" Entirely legitimate — but it's a different project, and it's worth saying so out loud rather than discovering it in the schedule.

5. Access and credentials. Who owns the domain? Who holds the hosting account? The answer "oh, the guy who built our site six years ago" easily adds a week.

Projects almost never run late because the code was too hard. They run late waiting for the copy for an About page.

How to Actually Shorten It

Prepare the content before starting. Even a rough draft. Editing an existing sentence is far easier than inventing one against a blank page.

Appoint one decision-maker. Everyone else can comment, but one person closes. That single change shortens timelines more than anything else.

Gather the access up front. Domain, hosting, Google account, brand assets. Five minutes now, a week saved later.

Agree what's in the first version. A live site with four good pages beats a perfect site that doesn't exist yet. The rest gets added afterwards.

Book a photographer, if there's budget. One shoot day does more for a site than two weeks of design polish.

The Day After: Launch Isn't the Finish Line

A common planning mistake is counting up to launch day and stopping there. There's another week or two of things that happen afterwards, and they belong inside the plan:

Connecting the domain. A DNS change usually propagates within hours but can take up to a day, depending on the provider. Don't schedule a launch for the hour a campaign is already running.

Google doesn't see you on day one. Indexing a new site takes days to weeks. Submit the sitemap, request indexing for the main pages — and don't panic that the site "isn't on Google" after two days. More in the indexing guide.

The first week of real use. The first leads expose things no test did: a question that keeps coming up by phone because the copy isn't clear, a form field people fill in wrong. Plan a small fix round for a week or two after launch — it's part of the project, not a bug in it.

And What About "Urgent"?

Sometimes it genuinely is urgent — a trade show, a campaign, a launch. We can work fast, but we have to be honest about what gets compressed. What I don't compress: speed, accessibility and testing. What can be compressed: the number of pages in version one, the design rounds, and how much of the copy gets written from scratch.

The Bottom Line

A real timeline isn't a nice promise in a meeting — it's the result of agreeing up front what's being built, who decides, and what already exists. With me that's settled in a short document before anything starts, so nobody discovers surprises halfway through.

Got a date you need to hit? Tell me the date and what you already have — I'll tell you whether it's realistic, and if it isn't, what we can do by then instead.

More from the blog

Tell me what you're building.

A short message is enough. I'll get back within a business day — with a real answer, not a sales script.