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

1. Realistic timelines by site type

These are calendar-time ranges for a hand-coded custom build from the first conversation to a live, tested, properly launched site. They assume content is reasonably ready and feedback comes back within a few days at each stage. Projects with slow feedback cycles or content that's "almost ready" for weeks at a stretch will run longer regardless of how fast the code gets written.

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

A website build isn't one continuous block of development time. It moves through distinct phases, and each one has its own timeline. Understanding this breakdown matters because the parts of the schedule you control as a client are concentrated in specific phases — and knowing where those are tells you where to focus your energy if hitting a launch date is important.

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.

Phase 1: Discovery (Week 1)

Discovery is the scoping and planning phase. It covers one or two conversations to understand the business, the audience, what the site needs to accomplish, what pages are required, what content exists versus what needs to be created, any design preferences or reference sites, and any technical requirements: booking integrations, payment processing, or other integrations. The output is a written scope, a fixed quote, and an agreed timeline.

Discovery takes roughly a week in calendar time. Most of that is a short back-and-forth to nail down the brief and get the scope signed off. Projects where the client has already thought through their requirements (page list, services to highlight, what they want visitors to do) move through discovery in days. Projects where those decisions get made during discovery take longer.

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 →

Phase 2: Design (Weeks 1–2)

Before any code is written, the full site is designed as wireframes and then high-fidelity mockups. Wireframes define the structure and content hierarchy of each page without visual treatment — what's above the fold, where the calls to action sit, how the navigation works, what information is on each page and in what order. Mockups add typography, color, imagery style, and the visual language of the brand.

The design phase takes 1–2 weeks, with the range driven primarily by how many revision rounds the mockups require. Well-organized clients who provide clear design direction and reference sites they like tend to need fewer rounds. Clients who aren't sure what they want until they see it benefit from the design phase most. This is specifically the time to explore options before any code commitment is made.

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.

Phase 3: Development (Weeks 2–4)

Development is when the approved mockup becomes a live, hand-coded website. This phase covers writing all the page structure and styling, the logic that runs forms and routes visitors to the right pages, optimization so images load fast and the site runs efficiently, and technical configuration so Google understands what your business is, your site shows up correctly when shared on social media, and search engines can crawl and index every page.

For a standard multi-page PHP site, active development takes 1–2 weeks. This is the phase where the developer's speed matters most, and also where a client's involvement is lowest. The main dependency on the client side during development is having final content available: the actual copy, high-resolution images, and any third-party account credentials (Google Analytics, booking platforms, existing domain registrar logins) needed for integrations.

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.

Phase 4: Review and Revisions (Weeks 3–5)

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.

The review phase is where client feedback speed has the most direct impact on the timeline. A client who reviews the staging build within a day or two and consolidates feedback into one organized list lets the developer batch all revisions and move to launch quickly. A client who takes two weeks to review and then sends a second wave of feedback two days after the developer has already addressed the first wave adds weeks to the calendar, even if the total amount of revision work is identical.

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.

Phase 5: Launch (Week 4–6)

Launch covers pointing your domain at the live server, provisioning security certificates, testing the site on every device size, verifying Google can find and index your pages, checking that contact forms work and confirmation emails send correctly, verifying that pages load at a good speed from the production server, and monitoring for any errors in the first 24–48 hours after the site goes live.

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

This is the pattern that shows up on almost every project, regardless of site type, budget, or how organized the developer is: the build finishes faster than the content. Pages are structurally complete, designs are implemented, everything works — and the site sits in staging with placeholder copy because the "about us" paragraph hasn't been written yet, or the service photos are still being taken.

Business owners have a business to run, and writing website copy isn't the day job. It's easy to agree to bring content to kickoff and then find that three weeks into the build, the content is "almost done" or "waiting on one more photo." Meanwhile, the developer can't launch pages with Lorem Ipsum standing in for real copy, and can't optimize images that haven't been provided yet.

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 is one of the most common reasons for 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 content preparation isn't feasible before kickoff — some projects move fast for legitimate reasons — the alternative is to include content writing in the project scope. A developer who offers copywriting assistance or has a writing partner isn't padding the scope; they're solving the most reliable cause of timeline overruns before it has a chance to become one. See how ArdinGate handles content in the build process →

4. What actually speeds a project up

Compressing a website build timeline without cutting corners requires specific inputs from the client side. These aren't just nice-to-haves — they're the actual levers that determine whether a project runs at the lower end of its range or the upper end.

Tight scope from the start. Every decision made before development begins is a decision that doesn't need to be made (or re-made) during development. For a website, that means knowing before kickoff whether the contact form needs to route to multiple email addresses, whether the site needs a blog section and who will write it, whether an appointment booking widget is required or a simple phone number works, and whether the gallery shows 6 portfolio pieces or 60. A brief that answers those questions eliminates entire categories of mid-build conversation. The discovery phase exists to get scope this tight. Clients who come to discovery with a clear list of requirements rather than an open-ended "we need a website" compress the discovery phase from a week to a day or two.

Content ready before development starts. Content readiness is the single largest timeline lever in the client's control. In practice, this means page copy drafted for every URL in the brief, images sized at least 1,200px wide and not still on someone's phone camera roll, and any third-party embeds (Google Maps, Calendly, booking widgets) already set up and tested. A developer working with real copy and real images from day one can complete the build in the lower range. A developer building with placeholders and retrofitting real content needs a significant second pass after the structural build is done.

Fast, consolidated feedback cycles. The review phase is a back-and-forth loop, and the speed of that loop is set by the client's response time. Reviewing the staging build within 24–48 hours of receiving access, writing down all changes in one organized list, and avoiding batched-late feedback ("one more thing" conversations that happen after the developer has already marked the round complete) keeps the review phase at 3–5 days instead of 2–3 weeks.

Decisions made, not deferred. Deferred decisions are the stealth cause of timeline slippage that nobody notices until it's too late. "We haven't decided on the service pricing yet" and "I need to check with my partner on the about page copy" are both reasonable things to say at week one. At week four, those same deferrals are blocking launch. Projects that stay on schedule have a decision-maker engaged and available throughout the build — not just at kickoff and launch.

Resisting scope additions mid-build. Adding a page, feature, or section that wasn't in the original brief isn't a problem in principle. It's a normal part of the discovery process, where teams learn what a business needs. The issue is when additions happen during development rather than during discovery. Every mid-build addition requires the developer to context-switch, assess the new requirement, update the design, and extend the build. Some additions are worth the disruption. Most of them could have been identified in discovery if the brief had been more thorough. For urgent additions discovered during build, identify them as change orders, agree on timeline impact, and keep them from blocking the rest of the project.

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

Timeline slippage on website projects almost never comes from a single dramatic failure. It comes from a series of small delays that compound: a week waiting on photos, five days waiting on feedback, three days tracking down a forgotten domain password. None of those individually derails a project. All of them together add three weeks to a schedule that was supposed to be four weeks total.

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

Client-side delays (most common): content delivery, feedback turnaround, access credentials, and approval from internal stakeholders (a business partner, a marketing person, a legal team) who weren't in the original brief conversation. These delays are controllable by setting internal deadlines on the client side and communicating them to the developer upfront. A client who says "I'll need 48 hours to run revisions by my business partner before I can approve them" at kickoff enables the developer to build that into the schedule. The same delay discovered mid-project is a surprise.

Scope creep (shared responsibility): "While we're at it" requests that accumulate throughout the build. On website projects these commonly surface as: adding a blog section mid-development, switching from a simple contact form to a full appointment booking widget after the form is already coded, requesting an e-commerce shop on a site scoped as a brochure site, or asking for a photo gallery on a page that wasn't in the original brief. Clients naturally think of new requirements as they see the build take shape. The solution is treating every addition as a formal change order with an explicit timeline impact documented and agreed upon, not a verbal handshake to "squeeze it in" that quietly pushes the launch date without anyone acknowledging it.

Third-party dependencies (unpredictable): DNS propagation after a domain transfer (generally 24–48 hours but occasionally longer), SSL certificate issuance, payment gateway approval timelines (some processors take days to approve a merchant account), Google Search Console indexing queues, and third-party API integrations where the external platform has its own timeline for provisioning credentials or webhooks. These can't be controlled, but they can be anticipated. Experienced developers start DNS and payment gateway processes early, before the rest of the launch checklist is complete, so delays in those external systems don't block the overall launch.

Developer-side delays (less common than the others): underestimating technical complexity, taking on more projects than the schedule supports, or technical problems that take longer to solve than expected. These happen. A developer with a clear process and a realistic client load should flag timeline risks early and communicate them before they become surprises. If a developer goes quiet for a week with no update during the development phase, that's a signal worth following up on.

6. Custom build vs. page builder: the time comparison that actually 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 real 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 actually does what you need it to do." That's a different calculation.

Page builders make the first hour cheap and fast. They make the following years expensive and constrained. Every customization requires working within the platform's system, which has limits. Every structural change that the builder's template doesn't support requires a workaround, a third-party app with its own subscription, or accepting that it can't be done. Performance optimization beyond what the platform provides isn't available. Technical SEO customization — custom structured data, server-level headers, the ability to control exactly what markup gets rendered — is constrained by the platform.

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

The custom build takes longer to get live. It's ready to perform from the moment it goes live, without months of platform workarounds and plugin stacking to close the gap between what the template offers and what the business needs. For sites built to drive revenue, the few extra weeks at the start are the investment. Full comparison: custom code vs. page builders →

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

"Redesign" is one of the more overloaded terms in web development. 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 of the existing site. Before touching anything, the current site's URL structure, indexed pages, backlink targets, and technical SEO state need to be documented. A page that ranks on Google for a valuable search term can't just be deleted or renamed during a redesign without a redirect — that's domain authority earned over months or years, and it can be destroyed in an afternoon without careful planning.
• Content migration. Existing copy, images, and files need to be moved or rewritten for the new site. Content that was acceptable when the site was originally built often needs improvement as part of the redesign: copy that was thin or poorly structured, images that are too small for modern retina screens, pages that lack the metadata and structured data that search engines now expect.
• Redirect mapping. Any URL that changes between the old and new site (whether a page is renamed, moved to a new path, or consolidated with another page) needs a 301 redirect from the old URL to the new one. This tells search engines to transfer the ranking signals from the old page to the new one. Missing redirects are how redesigns silently kill 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.

If your current site is on a platform you want to leave (WordPress with accumulated plugin debt, or a page builder you're paying monthly for), a redesign is usually also a migration. The timeline doesn't expand dramatically for the migration itself, but the SEO preservation work is especially important. You're not just rebuilding — you're moving the site off the platform that holds all the existing indexed content, which adds complexity to the redirect and verification process. When does a website need a redesign? →
Moving off WordPress: what the migration process looks like →

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 actually 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 →