How long does it take to build a website?

This is one of the most common questions I hear. It’s also one of the key factors in the success of your project.

The short answer is: longer than you would expect, but don’t rush it. There are three main factors in a project’s timeline:

  1. How soon can they start? High quality service providers are usually booked, so can’t start on your website immediately. There could be some delay from when you first hire the provider to when they actually get started.
  2. How long before a website is ready for review? Most designers and developers have a clear process for building a website, and can describe roughly how long it will take to get a website in your hands.
  3. How long before you can launch? This final factor is the biggest variable and depends largely on you, the client. It involves reviewing the website, making change requests, and finalizing content.

How soon can they start?

If your initial inquiry contains something similar to “…and I need the site live in the next month”, you’ll get fewer responses. You’ll eliminate many great service providers because they are booked up so can’t begin immediately.

A better approach is to share your needs and let them describe how they would solve it and in what timeframe. You can then select a service provider based on many factors, including recommended solution, quality of past work, timeline and cost.

There’s no “standard” amount of time that developers are booked up. It completely depends on the individual (or company) and their current workload. My team is typically booked 1-3 months in advance, but it varies. Right now, we’re scheduling projects starting February 5, 2018.

Last year an agency with whom I’ve worked on many projects reached out to discuss another project. The client was in a rush and they were trying to accommodate. They ended up using a different developer who was available a few weeks before me. I followed up a few months later; they ran into lots of issues with their developer and ended up launching later than they would’ve with my timeline and with a lower quality website. From the agency: “We so missed your expertise on our last website. I won’t make that mistake again.”

How long before a website is ready for review?

My team uses a three stage approach to site development. We begin with discovery to examine your needs and define a solution that meets your goals. This includes a sitemap to identify the overall content structure, and documentation describing the features and user experience on all key pages. For existing websites we also perform a technical site audit.

We then move to design, where we mock up exactly how all the pages will look across all devices. The completed designs are like pictures of your future website. Finally, we move to development, where I build a website that matches the approved designs and functionality described in the discovery document. The completed website is then sent to you for review, beginning the modification period.

These three stages take twelve weeks. Here is a sample timeline based on our current availability:

discovery

Discovery Phase

Feb 5 - 9 (1 week)

user

Client Revisions

Feb 12 - 16 (1 week)

hourglass

Break

Feb 19 - Mar 2 (2 weeks)

design

Design Phase

Mar 5 - 16 (2 weeks)

user

Client Revisions

Mar 19 - 23 (1 week)

design

Design Phase continued

Mar 26 - Apr 6 (2 weeks)

user

Client Revisions

Apr 9 - 13 (1 week)

development

Development Phase

Apr 16 - May 4 (3 weeks)

user

Modification Period

May 7 - 25 (3 weeks)*

development

Migration and Launch

May 28, dependent on Modification Period*

How long before you can launch?

The final item in the timeline above is “Modification Period”. We don’t limit it to a certain number of weeks – it can take as long as you need to perfect your website. This typically includes change requests for minor bugs or design inconsistencies. I recommend budgeting at least three weeks for modifications.

The best way to get your website launched in a timely manner: be prepared. This means:

  1. Block out time in your schedule to review and test your website. You know when it will be delivered, and it’s obviously a high priority for you. Schedule it like any other work in your day. The quicker we can iterate through changes, the sooner the site gets live.
  2. Know what content will be needed and have it ready. Planning to have 10 case studies on your website? Write the content while we’re designing and developing the site so they can be added immediately.

The number one cause for delayed launches is incomplete content. No one wants to launch a half-finished website, and content creation is difficult. Consider including content strategy and copywriting in our project’s scope.

Summary: How long to build a website?

A typical website will take 14 weeks at a minimum from start to launch. This includes 2 weeks discovery, 3 weeks design, 3 weeks design revisions, 3 weeks initial development, and 3 weeks of modifications. It could take much longer if you wait until the end to start writing content.

We will provide a list of dates we will have deliverables ready for review, and the date by which we’ll need your feedback to stay on schedule. Add these to your calendar so you’re ready. If there will be any conflicts (ex: you’re gone on vacation), let us know as soon as possible so we can adjust the schedule accordingly.

The time estimate above doesn’t include the time you spend selecting your designer/developer team, nor the potential delayed start due to their availability. You should be actively researching and hiring service providers 4-6 months before your desired launch date.

Business

Receive New Posts by Email

Comments

  1. Wow this is great, I have already forwarded it to a client that i do probono work for, this will help them get a better understanding of the effort we put into there site for them. As we don’t charge them anything and were building a 350 page site. The comment about content is so true, I clearly state that the site will not go live until “all” the content is ready.

    The client will always push to go early however we must remain clear in our descision to be properly prepared and no go off half cocked as its better for everyone

    “So missed your expertise on our last website. I won’t make that mistake again.”
    I knew this was going to be the case the second I read “They ended up using a different developer” hahah I just knew it

    1. It wouldn’t have been much of a story if it ended with “and they loved the new developer who’s faster and cheaper than me!” 🙂

      What I’ve done in the past with pro bono work is provide a fixed bid just like a normal project, and then discount it.

      Website Cost: $5000
      Friends and Family Discount: -$5000
      Amount Due: $0

      That way they can see the actual value they are getting.

      1. That is a great idea, Bill.
        I wander how people would react when they see the actual price?
        Will most of them appreciate the discount or will they think the price was bumped.

      2. I do the same. Whenever I give a discount, or pro-bono…I always send a bill with the actual am9unt, and an appropriate credit. It’s important they know what they got…or they will take advantage of you. This way they tend to appreciate you more I think. I hope anyway.

    2. I wonder why a lot of freelance wordpress developers offer to complete a wordpress website in just 2-3 days. You’ve done the right analysis, a proper and functional website does take time to build and goes through different phases before you can consider it as “complete”

      1. It depends what the developer is offering. If you’re just making a few tweaks to an existing theme then yes, you can complete it in a few days.

        The end client often doesn’t know the difference between the service offerings. They see one company offering websites in 2 days for $500 and another offering them in 8 weeks for $5,000. Part of my sales process is describing what I actually do and how it’s different from lower cost options they’ve seen or used in the past.

    3. Great read, I was getting impatient with a few of my projects. I do all the work myself besides maintaining servers etc…

      Now, I can relax, knowing the time to complete a website varies but I’m well within my timeline, so that’s good!

  2. Bill,

    This is great! I wonder what that modification graph would look like if you factored it against the size of the project? Perhaps as “weeks of modification over total cost” or “weeks of modification over number of templates”, etc? Somehow tying that period to the size/scope would be a interesting metric.

    Great post.

    Cheers,
    Joshua

    1. Surprisingly it’s the smaller projects that are more likely to go on forever, at least in my experience. I took the list of projects, sorted them by price, and then graphed the smallest 50% and largest 50%.

      See the updated data above, directly below the big graph.

      1. Nice!

        As initially surprising as this revised graph is, I think it makes sense for the point you made – the larger the project, the more invested the client. I would also imagine that projects with larger budgets have the staff-power to review and generate content more quickly than the smaller projects.

        Thanks for the updated graph and great post.

        Cheers,
        Joshua

  3. This is great! Thanks for posting. I use a similar system, but some of my projects aren’t always straighforward.

    I work on a lot of sites where we are moving a large amount of content from 1 system into another (from HTML to WordPress, from Joomla to WordPress, etc), and the time it takes to review and make revisions for this is definitely taken into account when the site starts. It can take as much as 3 months for an organization of 2-6 people to review a 100-200 pages and determine if they are needed, based on the high-level sitemap we create during discovery.

    As a developer, I also don’t enter the “development” phase until we’ve received “final” content for at least 75% of the pages (excluding the homepage).

    This means that, for migration projects, we stop after design until the client has identified the pages they want / don’t want, and for new site projects, we stop after design until we get the written content and graphics for those pages.

    I usually make my clients do most or all of their content entry (so that they are better trained to maintain their websites after we’re done), and have a section in my projects specifically for that.

  4. This is great article for anyone who is planning a website to those of us who create them. The modification process time frame was enlightening as I had never thought to allow that kind of time for clients to look through their site. You said you don’t limit the time, but I am sure that you would like to finish a site and get final payment at some point. How do you motivate clients towards completion? Particularly when all the site needs is content?

    1. The key is to not tie payment to launch. I bill 25% upfront to get scheduled, and 75% due one week after site is ready for review. So if a project is scheduled for 2 weeks of initial development, when I get started I send an invoice due in 3 weeks.

      The client gets to see a working website before paying, and I get paid in a reasonable timeframe.

      Your compensation should be tied to your deliverables (ex: website ready for review). If the client doesn’t have to pay the final invoice until going live, that disincentives them to launch. “If I approve the website now I’ll owe $x. I should wait until next month when I have more funds available”

      And while I don’t limit the modification period, if they aren’t actively working on the website (which I define as sending me change requests within 3 weeks of me completing the last round of changes), the modification period ends and the only thing remaining in scope is migration. So if they disappear for 6 months, then have changes they want done, those are all out-of-scope and billed separately.

      I describe my process in more detail here: Structuring Payments to Align Stakeholders

      1. Again, a new concept. I have always thought of launch as completion. But, it makes sense to tie payment to deliverables. The time frame on when the modification period ends make sense too. Thanks also, for the link to the article, it was super helpful too.

      2. This is such a great way to handle the billing process. I’ve been hung up in the ‘waiting to launch’ with many past clients and you’re point is spot on. If they are short on funds they will most certainly push back launch. All new sites payments are due prior to launch, but I’ve never done it within a period of final review – excellent idea and I will certainly implement this in the future.

        As always – great article Bill.

  5. Having a website is like purchase a domain and host it, no big deal. But to have a business started, it takes time. A website is a blank plot which means nothing unless you create it into a beautiful business place and then you say it is “work done”

    You nailed it! This takes time if it is something awesome that you are creating.

  6. My clients always want to get their site live ASAP. Now I know how I can convince them 🙂 Great post. I have already shared this post with my private Facebook client groups.

      1. Thanks. I found that helpful also… I love developing and working on sites…but I REALLY dislike the business side of it, trying to close a deal, getting a fair price, negotiations, contracts…But, without the one, there isn’t the other. So, I’m trying to get in and see what others are doing. Thanks so much for taking the time to write. (I am getting better at it. I finally got someone to pay a rate I wanted, higher than another estimate they got and they still went with me, so I must be learning) LOL…even with my ‘unfinished’ site of my own…it’s a bitch finding time to work on your own site, you know?

        1. Thanks Bill:

          I put a small clause into my contracts that allows me to bill if we’ve completed our deliverable and the client delays approval. We apply this whether it is an approval early in the project, or one of the final sign-offs.

        2. See if you can work on finding designers to work with. I’ve found it very advantageous to work with designers or agencies outsourcing the development process as they find the clients and usually provide the designs. I rarely find clients on my own but have a steady source of work from a variety of designers, small agencies and past clients.

  7. How do you handle quoting with this system? Do you give a range estimate upfront, prior to Discovery, and then whittle it down to a fixed price after Discovery? If so, then is Discovery a paid-up-front phase, maybe with the option for the client to back out if the post-Discovery finalized price is higher than they want to go with? So that the flow from initial contact to finalized quote is: initial client contact > emails > phone call(s) > discovery > finalized proposal?

    1. We provide a fixed bid for discovery, and estimate ranges for design and development. The more we know about the project initially, the tighter the ranges are in the initial proposal.

      On completion of discovery we provide fixed prices for design and development. While the client only commits to the discovery phase initially (waiting until after discovery to approve design/dev quotes), I don’t think we’ve had a client not follow through with design and development.

      1. Thanks. Though I haven’t yet done a true discovery phase on a project, I’ve been studying how others do them — typically I refer away something that would require it. Everyone I’ve talked to (or read) has the same experience as you, regarding the client always following through post-discovery. A followup: discovery is a fixed bid, but does the actual price vary based on the project? And are there any ways to introduce limitations or scope to prevent discovery from turning into an open-ended never-ending back-and-forth nightmare? 🙂

        1. In the past year we have had only two sites built that didn’t go through a discovery phase. Those were projects where they wanted to keep the exact site structure and pages the same, just clean up the design.

          I think every custom designed site involves some form of discovery, but most people don’t separate it out. Our discovery consists of:

          • Sitemap
          • A few rounds of wireframes of the key pages (ones we’ll be designing and building)
          • Once wireframes are complete, I write a technical scope of work document, describing how I’ll build all the features

          Before we did the discovery phase, those were all done in the first part of design. But we found that the actual number of pages and features changed quite a bit during wireframing compared to our initial discussions, simply because early on the client doesn’t know exactly what they want. We were providing fixed design/dev quotes on Scope A, and halfway through design (the discovery part) things would change and we’d need to write new quotes for design/dev.

          Breaking it out into a separate stage allows us to understand the high level things and assure the client we can solve those problems, without getting too much in the weeds scoping out a project prior to it being booked.

          Our proposal for discovery includes a description of the key pages and features we think we’ll be building (based on our initial conversations), and the discovery phase is priced accordingly. Projects with more pages and/or more technical review required (ex: auditing existing codebase to determine what we’ll need to rebuild) have a higher discovery cost than simpler sites.

          There are two ways we control the length of discovery:
          1. Our proposal only includes two revisions of the discovery wireframes
          2. The timeline is built around 2 revisions. Initial discovery lasts two weeks and revisions last another two weeks. If too much time is spent in discovery (too many revisions), the design and development will need to be rescheduled, which could result in a 1-2 month delay in the project.

  8. I never thought of that idea. I personally deal with clients that want websites for less than $1000 (custom code) and they often expect a timeframe of less than two weeks, and I’ve had trouble really getting them used to the fact that a good website takes a long time. Thanks, this really helps.

  9. Great article Bill!
    Have you done your own pagebuilder and themes? I´m real beginner of wordpress but I like it already, I try to find a great pagebuilder or maybe Genesis framework. Any tips/advice for a beginner to start?
    /Pelle

  10. Is a 4 week timeline for a site that’s more than 5 pages, needing custom dev. from scratch realistic?
    I received a quote for 24k . Is the timeline too short to create a really well thought out site?

    1. Is it 4 weeks only for initial development, or does that include design and/or revisions?

      The large projects I build typically have 20-25 unique page templates, cost $25-35k to develop, and I schedule them for four weeks of initial development (site ready for review after 4 weeks). There’s typically eight weeks of design and revisions before that, and another eight weeks or so of development revisions after it. Basically double all the time periods listed in the sample timeline above.

      1. They want the whole project completed in 4 weeks, custom design, custom dev, revisions, review, changes, testing, QA etc. I think it sets us up to miss the project launch date wanting a site done so unrealistically quick when they have more than 3 people reviewing and approving.

      2. I think they are either being very unrealistic with the timeline or they are not doing custom design & dev, but rather tweaking an existing WP theme.

Leave a comment