How Long Does It Take to Build a Website?

What "How Long" Actually Measures

A website build is a chain of six dependent gates: discovery, design, content, build, quality assurance, then launch. Each gate holds everything behind it until it opens, which means the schedule is not the sum of the work. It is the wait at the slowest gate.

That single structural fact explains why two sites of identical size ship four months apart with the same team. The schedule is not a measure of how fast the agency works. It is a measure of how fast the decisions arrive.

This is why the question has no product answer. A website is not manufactured on a line with a known cycle time, so there is no honest figure to quote for how many weeks one takes. Anyone who names a duration before seeing the page count, the approval chain, then the state of the content is naming a sales number, not a schedule.

What can be answered honestly is the shape of the clock. Three of the six gates open only when the client supplies something, one belongs to the agency, one is shared, then the last runs on infrastructure nobody in the room controls. Once a buyer knows which gate is theirs, the timeline stops being a promise to be extracted from a vendor, then becomes a number they can work out for themselves.

The same logic decides what a website redesign costs: depth of work rather than surface size. Digital Strategy Force models the schedule side of that with the DSF Website Build Pipeline, a six-gate breakdown that turns "how long will this take" into a question with an arithmetic answer.

The DSF Website Build Pipeline: Six Dependent Gates

The DSF Website Build Pipeline is a six-gate model of a website project, ordered by dependency rather than by department. Nothing downstream of a gate can start until that gate opens, so the gates compose serially. Waits add. Speed does not.

The rule governing the whole pipeline is the Client-Gate Principle: a build's duration is the wait at its slowest gate, then three of the six gates open only when the client supplies a decision or a piece of writing. A team can be fully staffed, fully paid, then fully idle, because the thing it is waiting for is not work. It is an answer.

That is what makes the pipeline useful before a project starts. It does not predict a duration. It identifies the constraint, which is the only place adding money or people changes the date. Every other gate is a place where the same spend buys nothing at all.

The order matters as much as the list. Each gate consumes the output of the one before it, so a decision reversed at gate two does not cost the hours it took to reverse. It costs every hour already spent at gates three through five on the assumption that the first answer would hold. This is why late changes feel disproportionate to the people making them: the change is small, then the rework behind it is not.

It also explains the most common scheduling mistake, which is sizing the team before finding the constraint. A build staffed for speed at gate four while gate three sits shut produces a fast team waiting on a slow one, then bills for both. The pipeline's value is that it makes that visible in a meeting rather than in month three.

Read down the "who holds the key" column and the whole argument of this article is already visible. The agency owns one gate outright. The client owns three. That distribution is not a criticism of clients, it is a description of what a website is: a statement of what a business believes about itself, which only the business can supply.

A website's schedule is not a measure of how fast the agency works. It is a measure of how fast the decisions arrive.— DSF Web Development Division

Gates 1 and 2, Discovery then Design: Decisions Nobody Else Can Make

Discovery is client-gated by definition. No agency can decide what a business is for, which customer matters most, or which of three competing internal priorities the homepage should serve. Those answers exist inside the company or they do not exist at all, so discovery is not research time. It is the time it takes an organization to agree with itself.

Design inherits the same constraint one step later. A direction can be produced in days, then sit for weeks waiting on an approval that has no single owner. The gate does not open when the work is finished. It opens when someone empowered to say yes actually says it, which is why naming that person in the contract does more for the schedule than adding designers.

The design gate is also where dated external constraints have to be resolved, because they are far cheaper to design in than to retrofit. Accessibility is the clearest case. The US Department of Justice has named WCAG 2.1 Level AA as the technical standard for web content under Title II of the Americans with Disabilities Act.

Read that scope carefully, because it is routinely misquoted. Title II covers state then local government entities, whose compliance dates the DOJ sets at April 26, 2027 for populations of 50,000 or more, then April 26, 2028 for smaller entities. A private company is covered by Title III, which carries no published technical deadline. The deadlines are not yours. The standard is still the clearest public benchmark of what accessible means, which is reason enough to fix it at the design gate rather than discover it at the quality gate.

Gate 3, Content: Where Schedules Actually Die

Content is the gate that quietly sets most website schedules, because it is the only one whose work cannot be bought, delegated, or parallelized away. Someone who knows the business has to write the words, then someone with authority has to approve them.

The workload is larger than almost any estimate assumes, then it is measurable. The HTTP Archive's 2024 crawl found the median mobile home page carried 364 rendered words, with the median inner page at 317. Those are medians across the real web, not targets, so a site meant to outperform its category needs more than this, not less.

Multiply that by a page count and the gate becomes visible. A ten-page site starts near 3,200 words. A thirty-page site starts near 9,600. A sixty-page site starts near 19,000. That is a book's worth of writing, assigned to people who already have full-time roles, then usually scheduled as though it were a form to fill in.

Images carry a second decision load on top of the writing. The same 2024 crawl found the median mobile page contains 13 image elements, with pages at the 90th percentile carrying 56. That count includes icons then interface graphics, so it is not 13 photographs to license per page. It does set the floor on how many image decisions exist, then every one of them is a small approval waiting to happen.

The fix is sequencing, not effort. Content written before the design gate opens lets the design be built around real words. Content promised after it turns every page into a placeholder that must be revisited once the words finally arrive, which converts one gate's delay into rework at three later ones.

Ready to Put a Real Date on Your Website Build? Digital Strategy Force scopes the content gate before quoting a schedule, so the date on the contract is one the project can actually hold.

Gate 4, Build: The Only Gate Your Agency Fully Controls

The build gate is the one place where money reliably converts into speed, because it is the only gate whose work is entirely on the agency's side of the table. It is also, on most projects, not the constraint. That combination is why so much web spend buys so little schedule.

Part of the reason the build gate is rarely the bottleneck is that most builds no longer start from nothing. The HTTP Archive found that CMS-driven sites account for over 54 percent of observed websites in 2025, which makes an existing platform the default path rather than the exception.

One platform dominates that share. As of its July 2026 survey, W3Techs records WordPress in use on 41.2 percent of all websites, a content management system market share of 59.1 percent. When the platform is already written, the build gate stops being about producing code, then becomes about configuration, template work, then integration.

This is also the gate that punishes scope added late. Work introduced after the gates behind it have closed does not simply extend the build. It reopens design then content decisions that were already settled, which is why a change that sounds small in a meeting lands as weeks on a schedule.

Gate 5, Quality Assurance: The Gate With a Fixed Target

Quality assurance is the one gate with a published, objective definition of done, which makes it the easiest gate to schedule then the most commonly left open. A build that defines quality as "looks good" has created a gate with no closing condition, so testing continues until someone runs out of patience.

That vagueness is what turns quality into an open-ended cost. A gate defined by taste reopens every time a new person looks at the site, because taste is not a threshold anyone can fail against. A gate defined by numbers closes exactly once, when the numbers are met, then stays closed. The difference between those two projects is not diligence. It is whether anyone wrote the number down before the work started.

The target itself is public. Google's Core Web Vitals thresholds set the bar at 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint, then 0.1 for Cumulative Layout Shift. The measurement rule matters as much as the numbers: to classify a page or site, web.dev states that the 75th percentile value of all visits is used. Three quarters of real visits must clear the bar, so an average is not a pass.

Clearing that bar is not what happens by default when a site ships. Google reports that 40 percent of sites in the Chrome UX Report do not meet the recommended LCP threshold. Two in five live sites fail the most basic speed check, which tells you the quality gate is real work that has to be scheduled rather than a formality at the end.

Gate 6, Launch: A Clock You Do Not Own

Launch is the gate most schedules forget, because it is the only one that runs on infrastructure nobody in the project controls. No amount of budget accelerates DNS propagation or a search engine's recrawl. The clock belongs to someone else, so the only lever available is starting early.

This is the gate where the word "launch" does the most damage, because it implies a moment. Every other gate in the pipeline is work that a team performs, so it responds to effort. This one is a wait that the internet performs, so it responds only to lead time. A team that treats it as a task to complete on the day will discover it is a countdown that should have started the week before.

Google's own move documentation sets the lead time explicitly, advising site owners to lower DNS time-to-live to a conservative low value at least a week in advance of the move. That is a task with a hard start date sitting a week before a launch most teams treat as a single day.

The gate does not close on deploy day either. Google states that after a move, old URLs will continue to occasionally show in results even though the new URLs are already indexed, describing this as normal. Ranking recovery is part of the schedule rather than an event, which is the same reason a redesign can cost rankings when the redirect map is treated as an afterthought.

What a Shut Gate Actually Costs

Waiting has a price, then the price is easy to underestimate because nothing visibly breaks while a gate is shut. The site is coming. The plan is intact. The only thing missing is progress.

The real cost never appears on an invoice. A website that has not launched is not doing the job it was commissioned to do. It is not converting the visitors it was built to convert, not ranking, not answering the customers arriving with questions today. Every week a client-held gate stays shut is a week of that outcome deferred, and because deferred revenue is never itemized anywhere, it is the cost most often left out of the decision. It also means the most expensive gates are the ones the business holds itself, because those are the ones no vendor can open on its behalf.

Delay on that scale is the norm rather than the exception. Reviewing 24 Department of Defense IT business programs, the US Government Accountability Office found seven programs that reported a schedule delay ranging from 3 months to 48 months, a median of 15 months. Those are defense business systems, not marketing websites, so the figure is not a website benchmark. What it establishes is that software slip is measured in months, and it happens inside organizations with mature program offices, so the realistic question is not whether a build will slip but which gate will slip it. That gate is knowable before the project starts.

How to Compute Your Own Number

The honest answer to how long a website takes is a calculation, not a quote. Count the pages the site genuinely needs. Multiply by the 364-word median to size the writing. Divide by the words the business can actually write then approve in a week, counting the approval, not just the drafting. That number, in weeks, is usually the schedule.

Then name the constraint out loud before spending anything. If content is the slow gate, hiring a second developer changes nothing. If approval is the slow gate, a bigger design team makes it worse by producing more to approve. Money only moves a date when it lands on the gate that is actually shut.

It is worth testing the assumption that artificial intelligence removes this problem, because the delivery data does not yet support it. Google Cloud's 2024 DORA report found that as AI adoption increased, it was accompanied by an estimated decrease in delivery throughput of 1.5 percent, then an estimated reduction in delivery stability of 7.2 percent.

The 2025 edition, drawn from survey responses from nearly 5,000 technology professionals, found AI adoption still carried a negative relationship with delivery stability even as more than 80 percent of respondents believed it had increased their productivity. That gap between felt speed then measured delivery is the whole lesson. AI is very good at the build gate, which was rarely the constraint, then it cannot decide what a business is for.

So the date is not something a vendor hands over. It is something a business earns by resolving its own gates early: one named approver, real words written before the design starts, numbers in the scope where "looks good" would otherwise sit, then a launch treated as a fortnight rather than a morning. Do that and the schedule stops being a guess. Skip it and no budget will save the date, because the gate that is shut was never one money could open.

FAQ — Website Build Timelines

Next Steps — Website Build Timelines

• ▶ Count the pages the new site actually needs, then multiply by 364 words to size the writing load before agreeing to any date.
• ▶ Name one person who can approve design and copy without convening a committee, then put that name in the contract.
• ▶ Write the content before the design gate opens, so the design is built around real words instead of placeholder text.
• ▶ Set LCP 2.5 seconds, INP 200 milliseconds, then CLS 0.1 as acceptance criteria in the scope, so the quality gate has a defined close.
• ▶ Lower DNS time-to-live a week before launch, then schedule the redirect map as a task rather than an afterthought.

Digital Strategy Force builds websites on a gated schedule with the constraint named up front, so the date on the contract is one the project can hold. Talk to the web development team.