How long does it take to build a website? Realistic timelines with no handwaving.

1. Realistic timelines by site type

These calendar ranges cover first conversation through tested custom launch, assuming ready content and feedback within days. Slow reviews or weeks of "almost ready" content extend them regardless of coding speed.

These are realistic ranges, not minimums quoted to win business. The most common outcome for a well-organized client with content ready is hitting the lower end of the range. The most common reason for hitting the upper end (or exceeding it) is content delivery and feedback speed, not development complexity. That pattern holds across almost every project type.

For a more detailed look at how the process works from kickoff to handoff, see the ArdinGate build process →.

2. The five phases of a custom build and how long each one takes

Builds move through distinct phases. Client-controlled delays cluster in particular stages; understanding them shows where your effort can protect a launch date.

The timeline below is based on a standard multi-page small-business site. Single-page sites compress each phase; e-commerce and web applications expand them proportionally.

1. Week 1

   Discovery

   Discovery uses one or two conversations to define business, audience, goals, pages, existing/new content, design references and booking/payment/other integrations. Outputs: written scope, fixed quote and agreed schedule.

   Discovery takes roughly a calendar week, mostly brief refinement/sign-off. Prepared pages, service priorities and visitor goals shorten it to days; deciding during discovery lengthens it.

   Every hour spent defining scope precisely in week one prevents scope creep, revision cycles, and timeline slippage later. A brief that's specific enough to build from is the single best thing a client can bring to the kickoff conversation. How to write a website brief that gets better results →

2. Weeks 1–2

   Design

   Before coding, wireframes establish each page's hierarchy, first screen, CTAs, navigation and content order. High-fidelity mockups then add typography, color, imagery and branding.

   Design takes 1–2 weeks, chiefly by revision count. Clear references reduce rounds; uncertain clients can explore options here before committing code.

   A design is a specification. Every section, layout decision, and content block in the mockup corresponds to code that gets written in phase 3. Changes to the design after development starts aren't impossible, but they require reworking code that was written to a different specification. The design sign-off is the moment to lock decisions.

3. Weeks 2–4

   Development

   Development turns approved mockups into hand-coded pages: structure, styling, forms/routing, image/runtime optimization, Google-readable business setup, social previews and crawl/index configuration.

   Standard multi-page PHP development takes 1–2 weeks, with little client involvement. Supply final copy, high-resolution images and Google Analytics, booking-platform/domain credentials; developer speed matters most here.

   Development time expands for sites with more complex functionality: multi-step forms with conditional logic, live inventory feeds, payment integrations, custom calculators or configurators, database-backed features, or API connections to third-party platforms. Each of those is a development project layered on top of the base site. The scope established in discovery determines which of those apply.

4. Weeks 3–5

   Review and Revisions

   Once the build is complete, the developer hands off a staging or preview environment for review. This phase covers the client reviewing the site against the approved mockups and brief, noting any gaps or requested changes, and the developer implementing those changes. It may cycle more than once depending on the volume of revisions.

   Review within a day or two with one consolidated list for efficient revisions. Waiting two weeks, then sending another batch two days after fixes, adds weeks despite identical work.

   Scope changes during review (adding a page that wasn't in the original brief, changing the contact form to an appointment booking widget, or adding a service not mentioned in discovery) extend the timeline proportionally. They're not a problem as long as they're identified as scope changes rather than "minor tweaks," and the timeline is adjusted accordingly.

5. Week 4–6

   Launch

   Launch covers domain routing, certificates, all-device tests, Google indexing, forms/confirmation emails, production speed and error monitoring for the first 24–48 hours.

   Launch prep on a clean custom build takes 1–3 days of focused work. Projects with complicated domain setups, existing sites with URL structures that need redirect mapping, or third-party integrations that behave differently on production than on staging may take a bit longer. The goal is to launch clean once rather than fast and then spend a week firefighting.

3. Why content, not code, decides your launch date

Across budgets and site types, code usually finishes before content. Working, designed pages sit in staging because about copy or service photography remains unfinished.

Business owners juggle other work; three weeks later, promised copy/photos may remain "almost done." Developers cannot launch Lorem Ipsum or optimize undelivered images.

The projects that finish on schedule consistently share one characteristic: the client treats content preparation as a pre-kickoff task, not a during-build task. That means:

• Copy for every page is drafted before development starts, even if it's rough. A rough first draft that exists is infinitely more useful than polished copy that's still being written. The developer can structure pages around real content. The client can refine the copy during the review phase rather than blocking development entirely.
• Photos are gathered or sourced before kickoff. This includes both high-resolution original photos (headshots, team photos, before/after work examples, location shots) and any licensed stock photography. Waiting for a photography session that hasn't been scheduled yet ranks among the most common causes of multi-week delays on otherwise simple sites.
• Third-party account credentials are located and confirmed. Domain registrar logins, existing hosting control panel access, Google Analytics accounts, booking platform admin credentials, social media logins; any of these that will be referenced or connected during the build should be tracked down before development starts, not after the developer asks for them three weeks in.

If rapid kickoff prevents advance content, scope copywriting or a writing partner. This resolves the most reliable delay source, rather than padding costs. ArdinGate's content process →

4. What speeds a project up

Compressing a website build timeline without cutting corners requires specific inputs from the client side. These aren't nice-to-haves. They're what determines whether a project runs at the lower end of its range or the upper end.

Define scope early: multiple form recipients, blog/authorship, booking widget versus phone, and 6 versus 60 gallery pieces. Deciding before development avoids rework. Clear requirements can shrink discovery from a week to a day or two.

Content ready before development starts. This is the client's biggest timeline lever. Have these ready:

• Draft copy for every URL in the brief.
• Images at least 1,200px wide, delivered rather than left on a phone camera roll.
• Configured and tested third-party embeds, including Google Maps, Calendly, and booking widgets.

Real copy and images from day one support the lower timeline range. Retrofitting them into placeholders requires a significant second pass after the structural build.

Consolidate feedback within 24–48 hours. One organized list without late "one more thing" requests keeps review at 3–5 days instead of 2–3 weeks.

Resolve decisions. Unsettled service pricing or partner-approved about copy is reasonable in week one but blocks launch in week four. Keep an empowered decision-maker available throughout.

Limit mid-build additions. Discovery is the best time for new requirements; later additions require context switching, assessment, design changes and development. Some justify disruption. Document urgent additions as change orders, agree timing and avoid blocking other work.

5. What slows a project down and who's responsible

Small delays compound: a week for photos, five feedback days and three days finding a domain password can add three weeks to a four-week schedule.

Understanding who controls each delay type matters because it determines what you can do about it.

Client delays dominate: content, feedback, credentials and unplanned partner/marketing/legal approvals. Set internal deadlines upfront. Disclosing a partner's 48-hour review at kickoff enables scheduling; discovering it mid-project creates surprises.

Scope creep is shared: added blogs, booking widgets replacing coded forms, e-commerce on brochure sites or unplanned galleries. Emerging ideas are natural. Document every addition and agreed timeline impact as a change order, avoiding informal promises that silently delay launch.

External timing varies: DNS usually 24–48 hours or longer, SSL issuance, merchant approvals lasting days, Google Search Console queues and API credential/webhook provisioning. Start DNS/payment processes early so uncontrollable waits don't block launch.

Developer delays include underestimated complexity, overbooking and difficult technical fixes, though less commonly than other causes. Realistic workloads/processes should surface risks early. Follow up on a week's unexplained silence.

6. Custom build vs. page builder: the time comparison that matters

A Wix or Squarespace site can be technically live in a day. That's true, and it's worth taking seriously as a comparison point. For certain use cases — a pop-up event page, a temporary campaign landing page, a placeholder while the permanent site is built — the builder speed advantage is genuine and worth using.

For a business website you're planning to grow traffic on, convert customers through, and operate for several years, the timeline comparison shifts from "how fast can it go live" to "how long before it does what you need it to do." That's a different calculation.

Builders speed the first hour but constrain years afterward. Unsupported structures need workarounds, paid apps or abandonment. Performance remains platform-limited, as do custom structured data, server headers and exact rendered markup.

The practical timeline comparison for a business-critical site looks like this:

Custom takes longer initially but launches ready to perform, avoiding months of template workarounds/plugin stacking. For revenue sites, those extra weeks are an investment. Custom vs. builders →

7. Redesign timelines: what's the same, what's different

In web development, few terms carry as many meanings as "redesign." It gets applied to everything from a visual refresh of an existing WordPress theme to a full rebuild of a site on a completely new codebase. Those are not the same amount of work, and they don't have the same timelines.

A visual refresh (updating colors, swapping in new photos, adjusting fonts) on an existing site can be fast if the underlying codebase is clean and the scope is limited. This is the kind of "redesign" where 1–2 weeks is realistic.

A full redesign in the ArdinGate context means a complete rebuild: new codebase, new design, content migration, and careful preservation of the existing site's search engine equity. That runs 3–6 weeks — the same range as a multi-page new build, because the amount of work is comparable. What a redesign adds on top of a new build:

• Audit first: document URLs, indexed pages, backlinks and technical SEO. Deleting/renaming ranked pages without redirects can erase months/years of authority in an afternoon.
• Migrate content: move/rewrite copy, images and files. Improve thin structure, undersized retina imagery and missing metadata/structured data during redesign.
• Map 301 redirects for every renamed, moved or consolidated URL. They transfer ranking signals; missing mappings silently destroy organic traffic.
• Post-launch monitoring. After a redesign goes live, Search Console needs to be monitored for crawl errors, coverage gaps, and any indexed pages that returned 404s. A few days of post-launch monitoring is standard practice on any redesign, because even a careful redirect map can have edge cases that only surface once the new site is live.

Leaving WordPress plugin debt or monthly builders usually combines redesign/migration. Moving adds little time but complicates redirects and verification for indexed content, making SEO preservation essential. When to redesign →
WordPress migration process →

8. Key takeaways

• A single-page custom site takes 1–2 weeks from kickoff to launch. A multi-page small-business site takes 3–6 weeks. E-commerce and web applications run longer based on scope and complexity.
• Website builds move through five phases: Discovery, Design, Development, Review, and Launch. Each phase has its own timeline and its own client dependencies. Understanding which phases require your input tells you where to focus your energy.
• Content is the most reliable predictor of whether a project hits its target date. Copy and photos that exist before development starts compress the schedule. Content that's "almost ready" during development extends it, often by weeks, for no technical reason.
• The things that speed a project up are all on the client side: tight scope defined at discovery, content ready before development, fast and consolidated feedback at review, and decisions made rather than deferred. None of those require the developer to work faster.
• Third-party dependencies (DNS propagation, SSL provisioning, payment gateway approvals, Search Console indexing queues) can't be controlled but can be anticipated. An experienced developer starts those processes early so an external delay doesn't block the launch date. If a developer goes quiet for a week mid-build with no status update, that's a signal worth following up on.
• A page builder can have a page technically live in hours. A custom site that's ready to rank, convert, and perform takes 3–6 weeks. For a business website you plan to operate for years, the extra weeks at the start are the investment in something you own and control.
• A redesign takes about the same time as a new multi-page build, because the work is similar plus the content migration and SEO preservation layers. Rushing the redirect and audit process on a redesign is how sites lose organic traffic they took years to earn.

9. Common questions

See all web design FAQs →