How Long Does it Take to Build a Website on WordPress?

Wall of clocks | time to build a WordPress site

This piece attempts to give clarity on a tricky and open-ended question: “How long does it take to build a website in WordPress?” It’s been updated on May 30, 2017, to discuss the time cost of training and supporting site owners.

One of the all-time most helpful single pieces of WordPress writing comes from Brian at Post Status: How much should a custom WordPress website cost?

Throughout the post, Brian makes the very correct point that “Pricing is hard,” and that “a website” can truly cost almost anything, depending on the client’s needs.

Unlike the rest of us, though, he doesn’t stop there. The post discusses real numbers: for example, the rough hourly rate of a middle-of-the-road WordPress freelancer. What’s more, the numbers feel right: they closely resemble the internal calculus I do as a developer to decide how valuable a project is likely to be. By putting these secret rules of thumb out there for clients to see, Brian has created a piece of truly required reading.

Even if you don’t read the whole article, please read the following two sections: Freelancer rates vs. agency rates (which breaks down approximate hourly rates for low-and high-demand freelancers and web agencies), and Custom website prices, which has a sequence of paragraphs describing roughly what you can expect to pay, total, for various kinds of projects.

Time is Money: Estimating How Long It Takes To Build a Website On WordPress

I’ve put together a lot of “How long it takes” rules of thumb based on my own experience as a WordPress consultant.

I thought a good supplement to a post about the cost of WordPress websites would be a post describing how long, in hours worked, different WordPress development tasks take.

Cost and time are, of course, two sides of the same coin, as the only sane way to budget a project is with reference to the time it’s expected to take multiplied by an (explicit or implied) hourly rate. However, I think clients and everyone else could benefit substantially from a good understanding of which jobs are quick, and which jobs are long, in WordPress consulting work.

To that end, I’ve put together a lot of “How long it takes” rules of thumb based on my own experience as a WordPress consultant.

How to Use the Estimates Below

As with Brian’s post, keep in mind that all of these numbers are massively imperfect best guesses—they’re the closest I can get to describing my own experience, but can all grow or shrink wildly based on dozens of variables that are impossible to predict.

Also, one intended use for this post is for it to be combined with Brian’s freelancer rates to yield a very rough cost per task that you hire out to a freelancer. So you should be able to multiply any of these numbers by one of Brian’s freelancer rates to get an approximate cost, but bear in mind that cheaper/less experienced freelancers work less quickly and less well.

Finally, just for clarity, an “hour” or a “minute” is time spent thinking about nothing else but a client project. So thirty minutes on the phone with a client would be thirty minutes; five minutes to boot up your computer plus ten minutes fixing a bug would count for ten minutes.

Now, let’s look at some time estimates!

How Long It Takes to Do Some Common WordPress Tasks

This list contains a number of individual tasks that I commonly perform in my work on client sites. These feel like the average time I spend fully committed to a given task (so it doesn’t include the phone call asking me to do it, the email to confirm I’ve done it, etc.). Most tasks grow wildly and unpredictably in complexity if something unusual crops up, so these numbers are when that doesn’t happen.

  • Log in and update WordPress: 5 minutes
  • Install a plugin/solve a problem that revolves around a simple plugin install (e.g. Akismet for comment spam): 5 to 10 minutes
  • Set up a domain-specific email account or email forward: 5 minutes
  • Help restore a client’s admin credentials, add a user, etc.: 5 to 10 minutes
  • Login to a site and change a post’s contents, rearrange the site nav menu, etc.: 5 to 15 minutes
  • Most individual CSS changes (change the color of an object, change a font, reposition an object and give it a shadow): 5 to 25 minutes
  • Create a Twitter account for a client: 10 minutes
  • Help a client set up a MailChimp account, with CSV import if necessary, and an integrated MailChimp for WordPress sidebar signup form: 15 minutes to 1 hour
  • Install WordPress on a given hosting account (including database creation): some passive FTP transfer time, plus 15 minutes active work
  • Update WordPress and all plugins, test to make sure nothing’s broken: 15 to 45 minutes
  • Use a plugin’s interface to create what it’s designed to create (a contact form, a social button bar, etc.): 15 to 30 minutes
  • Purchase hosting and prepare it for a WordPress install (set up username and password, FTP credentials, etc.): 15 minutes
  • Migrate a WP site between hosting accounts using a migration plugin, start-to-finish and including testing: some passive download/upload time, plus 30 minutes to 1 hour
  • Troubleshoot a hosting/registrar/backend problem (improperly set memory limits, bad .htaccess rules, wrong DNS, etc.): 15 minutes to 2 hours
  • Create a Facebook page for a client: 20 minutes
  • Read an emailed bug report, locate an obvious problem in PHP or JS code, fix the problem, upload the fix, test the fix, email about the fix: 15 minutes to 1 hour
  • Purchase a domain name and hosting and create a fresh WordPress install at the targeted domain name: 30 to 45 minutes
  • Track down and fix a non-obvious problem in a WordPress site’s code: 30 minutes to 5 hours for most problems
  • Migrate a WP site between hosting accounts manually, start-to-finish and including testing: 1 hour

The Shortest Possible Development Cycle for a WordPress Site

This is least active development work that I think could be possible to set up a WordPress site, excluding overhead and other real-life factors.

This is smallest amount of active development work that I think is feasible to set up a WordPress site that could really be used by a client. These are either personal bests or what seem to me to be the common-sense lower limit.

These estimates contain only development work and no overhead (initial consultations, planning, estimates, feedback, invoicing, etc.). As such, they basically break down into items from the list above, such as “choose hosting and install WordPress on the hosting,” plus some amount of more idiosyncratic work to make the whole thing usable (like fiddling with the homepage layout).

  • A dead-simple blog on a simple blog theme, no customizations: 2 hours. This would entail installing WordPress and some theme on a particular hosting and domain configuration, setting a site title and permalinks, and that’s it.
  • An informational site (Home, About page, Contact page, maybe a blog) on a very lightly customized premium theme: 8 hours. This would be the absolute minimum time to launch a simple informational site that you could use for a small side business such as a pet grooming service or a yoga practice. This could include bare necessities like a contact form, but very little custom design work.
  • A simple e-commerce site: 20 hours. This would be a fairly minimal WordPress site running WooCommerce that is able to properly list and categorize products and process customer transactions.

Understanding the Time Cost of Overhead on Client Projects

“Overhead,” as defined here, is hours worked that don’t go directly to building websites.

“Overhead,” as defined here, is hours worked on a project that aren’t development—that is, they don’t involve working directly with the technologies used to build websites. Overhead could be either non-billable (an initial phone consultation), or billable (responding to an email in which the client gives feedback).

  • Total initial conversation, emails, and consultations before billable work starts: 1 to 4 hours
  • Time to draw up a project estimate: 45 minutes to 2 hours
  • Additional communications, including progress reports, feedback, invoicing, etc.: 3 to 6 hours for a project under 40 hours in length
  • “Curveballs”—the client has very troublesome obsolete hosting, frequently needs to be re-sent login information, wishes for a logo to be included but isn’t able to send it in a usable file format, etc.: 0 to 10 hours for a project 40 hours or less

Almost all projects have these types of overhead, and some projects have considerably more if client communication is difficult, the client insists on site visits, etc. Certain client personality traits serve as a good indicator of trouble, so they’re worth looking for.

How Long Client Training and Support Takes on a WordPress Project

WordPress clients do need training, but on most projects this training is not terribly time-consuming.

WordPress clients do need training before they’re ready to take ownership of their new site. On most projects, however, this training does not need to be terribly extensive or time-consuming, because most features of WordPress are reasonably intuitive—especially for simple blogging and informational-site uses—and because, as a practical matter, many clients don’t manage their WordPress sites especially actively once they’re launched.

  • Active client training for an average WordPress project: 30 minutes to 2 hours.

In my personal workflow, most of this training occurs informally, on calls that were scheduled for other purposes. “Training” also often takes the form of the client asking questions as she runs into new things she doesn’t know how to do during the process of populating the site with content.

However, a number of specific types of features can lengthen the training time that a project requires:

  • Training for custom layout elements (a shortcode, a page builder, video or audio embeds): 5 minutes to 1 hour.
  • Training for a simple WooCommerce site (few products, and simple products with no variations and few custom attributes): 1 to 2 hours.
  • Training for an associated use outside WordPress (MailChimp, Google Analytics): 30 minutes to 5 hours.
  • Training for a web application built on WordPress (BuddyPress, bbPress, a membership site, an LMS, etc.): 1 to 5 hours.
  • Training for a complex WooCommerce site (product variations, custom product attributes, complex shipping and tax options, third-party software integrations): 2 to 8 hours.

Post-Launch Client Support

Most WordPress projects come with between one and twenty post-launch support calls per year.

Additionally, clients need support post-launch. Most WordPress projects come with between one and twenty support calls per year.

The number of support calls depends on a few factors:

  • How actively the site owner uses and manages the website.
  • How technically adept the site owner is in general.
  • How good or bad the technical environment you’ve set up is.
  • How complex the website’s functioning is (blog, online store, membership site, BuddyPress site, etc.).

The following are some common types of client support calls, with time estimates for each:

  • The client needs a “refresher” on something already built-in, like changing the homepage hero image: 5 to 15 minutes.
  • The client is trying to do something new but well-supported (like child/dropdown menus) and is stuck: 5 to 30 minutes.
  • The client has general questions about a large topic like speed, SEO, or security: 15 to 45 minutes, primarily conversation-based.
  • The client wants new functionality that is well-covered by an existing plugin; examples would include “responsive YouTube embeds” or “an Instagram feed on the About page”: 5 minutes to 1 hour.
  • The client has a critical bug triggered by something like an update or a server PHP version change: 15 minutes to 5 hours.
  • The client wishes for a novel feature that is complex but well-covered by an existing plugin, like a landing page, online store, members’ area, or discussion forum: 1 to 10 hours.
  • The client wishes for something that boils down to “make these two plugins talk to each other”—for example, “integrate my booking plugin with my membership plugin”: 5 to 30 hours.

The client will periodically need support.

The Rhythm of a Typical WordPress Project

Projects have a tendency to feel like they’re “almost done” for much of their actual duration.

Projects have a tendency to feel like they’re “almost done” for much of their actual duration. This is because the transition from “building the project” to “putting it live for the world to see” reveals a lot of details and complexities that may not come up beforehand. For example, the live site’s hosting might be unreliable or unacceptably slow, forcing a second transfer; or the contact form solution may turn out not to work properly with the client’s email service.

  • The initial build (most of what’s covered on the initial estimate): 60% of a project
  • The part where it feels like the job is “almost done”—migrating the finished site, client testing and feedback, bugfixes and improvements not in original spec, late troubleshooting, add-on features: 40% of a project

How Long a WordPress Client Project Actually Takes

This captures what I expect to be the actual hours of a developer’s work required to get a site up and running.

This is what I expect to be the actual hours of a developer’s work required to get a site up and running. It does include the overhead excluded in “the shortest possible development cycle” above, as well as the consideration that complexity tends to pile up toward the end of the project, and the need to train the client.

  • The actual time to build a WordPress site: The “shortest possible development cycle” numbers above multiplied by 1.5 to 3.

This multiplier varies with differences in client needs, levels of communications and support overhead, and “gotchas” and emergent troubleshooting issues.

Some Thoughts on Harder-to-Estimate, More Technical Jobs

The time to complete more technical work varies with the innate complexity of the job, which is very hard to know beforehand.

Here we’ll also briefly discuss common WordPress projects whose requirements are more technical than “install WordPress and customize a theme.” I’m discussing these types of projects separately because their time cost is less easy to predict: the cost tends to vary not with the client’s level of need and the overhead burden, but with the innate complexity of the technical job being asked.

This complexity is very hard to know beforehand (if you knew it, you’d be most of the way to done with the job!), which is why highly technical jobs are harder to estimate.

  • Build a WordPress page template from a Photoshop document: 5 to 10 hours
  • Build a full-featured WordPress site on a premium theme, with significant design modifications and a number of feature additions (like a personal calendar, complex slideshow, etc.): 40 to 100 hours
  • Integrate and customize an existing third-party plugin to make WordPress do something metadata-intensive that it wasn’t built for (tournament brackets, real estate listings, crowdfunding site, hotel room reservation service): 15 to 100 hours
  • Design and develop a WordPress site on a completely custom theme: 60 to 250 hours
  • Write a new plugin that solves a unique or unsolved problem: 20 to 300 hours

The Time to Write and Publish a Blog Post

In my experience, this is what’s required to get blog content out the door. If you’re interested in content marketing (and you should be), you might be interested!

  • A throwaway blog post: 2 to 4 hours
  • A good, well-thought-through blog post: 4 to 7 hours
  • An unusually long, thoughtful, high-quality blog post (the type most likely to gain wide traction or appreciation): 7 to 20 hours

In Conclusion…

The main aim of this article is to start trying to put numbers to the WordPress developer’s job, while recognizing that the numbers are hugely imperfect.

How do these numbers sound to you? How long does it take to build a website on WordPress for you? If I get a lot of feedback in one direction, I wouldn’t mind altering the post to reflect it! Do you have suggestions for any areas of the job I missed?

Image credit: woodleywonderworks

27 Responses


  • Hi Fred,

    I love your article! One thing I would like to add is the time it takes to teach your customer how the dashboard works, how to add featured images, how to (and how NOT to) use the text editor, etc.

    Kind regards from a Dutch Keith Jarett fan,


    • Fred Meyer says:

      Great idea, Anne-Mieke. Would you like to post (or email) your thoughts on the time to train clients in WordPress? I’ve got vague guesses for my own numbers, but interested to hear yours.


  • I usually forward a custom made manual and leave them to it. 5 hours for simple website, with screenshots of their specific theme.


  • Alan says:

    Very interesting article.

    I’m pretty experience in WordPress and I track my time in detail on chargeable work, and I feel your maintenance tasks are understated to some extent, either that or you are very fast and I am very slow.

    I feel your project life cycles are more accurate, but I note they don’t seem include a design process, either in terms of objectives, target clients or look (nearly always using a premium theme), nor the creation or uploading of content. An estimate I just put together to build a website less than 30% was covered by build/setup.

    As far as training goes, we find it is rarely worth giving more than 1 hour training as it all gets forgotten, you just have to provide a (paid for) support service.

    Nice post anyway.

    • Fred Meyer says:

      Hi Alan,

      As I go through and reread the article, I think that’s good feedback. Part of it’s probably in the definition; what do we mean by the time I spend “fully committed” to a task? If I’ve got everything in front of me and I’m actually working, I’ll bet I can log into a site and update WordPress in two minutes. But if we’re including the time it takes for me to read the initial request email (and reply to it once I’m done), put down my bowl of soup, etc…

      I certainly wouldn’t want to run a business that priced maintenance tasks as the minutes above times my hourly rate; but again, that seems to be mostly a discussion about overhead, which is huge relative to the length of many maintenance tasks.

      What do you think? Thanks very much for the thoughts!


      • Alan says:

        I think you hit the nail on the head regarding maintenance.

        Customer raises a ticket – ‘I keep getting messages that my site doesn’t perform in Google’
        – time to read and reply asking for clarification, asking for example – 4 minutes
        – time to read response – 1 minute
        – time to rewrite a response, explaining clearly how to display full email headers and request those – 5 minutes
        – time to read the email headers and identify if the email actually came via the site
        – if it didn’t come from the site, time to write an email explaining how spammers use SEO ‘fear’ as a way of getting leads – 5 minutes *
        – if it was from the site -time to look up the access passwords, 1 minute or less if it is a regular client and you are organised or using a management system, 10 minutes if you are not
        – login and recall how the site is built and how spam is dealt with – 5 minutes
        – check if Akismet (in this example is set up correctly and fix issue – 1 minute
        – time to time to write an email explaining how spammers use SEO ‘fear’ as a way of getting leads – 5 minutes

        Time to fix Akismet settings – 1 minute
        Time to deal with the support request – 21 – 31 minutes

        • Fred Meyer says:

          Yes, exactly!

          To anyone reading this: Alan’s additions and things like them, which I’m calling “overhead” in the article, are a constant and pervasive fact of life in web development. So if you can streamline some of this for yourself (if you’re a developer) or for your developers (if you’re a client), you can get a lot more done quicker and more cheaply.

  • Cheryl says:

    This is totally a MONEY article and I mean that in a Vince Vaughn kinda way!

  • Scott says:

    Hi Fred,

    Since you recently posted your excellent “Squarespace or WordPress?” article, I wonder how different your estimates would be if using Squarespace?

    • Fred Meyer says:

      That’s such an excellent question that I actually considered writing a section on that in this revision to the article.

      Here’s what feels like the short answer to me:

      1. If Squarespace is capable of doing something, it will on average take less time than it would in WordPress. This is because everything in a Squarespace environment works with everything else, and because the UI is very polished, integrated, and frontendy. As the Squarespace article mentioned, I built the skeleton of an entire one-page site that I was quite happy with in around three hours. I could work at the same speed in WordPress, but I don’t think it would come out looking quite as good from a design perspective, and I’d probably be a bit worried about ricketiness in the theme/page builder combination I chose to get to that point that quickly.

      2. Many or most things on this list Squarespace isn’t capable of doing, or is the wrong choice for. To create a “Long Reads” archive page that pulls the site’s most recent ten posts that are over 3,000 words might take 1 to 3 hours in WordPress, and is probably impossible (and almost certainly not worth attempting) in Squarespace.

      So I think Squarespace is faster at what it does, which is beautiful and very simple informational sites with basically zero surprises or novel feature needs. When you do start seeing surprises you need WordPress—basically, because you need full control over the code—and that implies a longer amount of time for the basic stuff (the stuff Squarespace can do) to make sure your various themes and plugins talk nicely to one another, and to harmonize design that is harmonized by default with Squarespace.

      Hope that’s coherent? Would love to hear your thoughts!

      • Scott says:

        Hi Fred,

        My main observation is that it’s very refreshing to finally see a WordPress developer openly and objectively consider other options such as Squarespace. Far too many website developers treat their chosen CMS as their children and religion, and react defensively if someone dares to question their favorite CMS (concrete5 peeps are a particularly defensive and angry group!).

        I’ve been a “car nut” for a long time, but I don’t recall ever seeing a car nut get upset if someone compared their favorite car company or model to another one. In fact, doing so is generally considered entertainment and “sport.”

        Plus, and obviously, the more WordPress developers learn about other CMS options, the more they’ll learn about WordPress’s strengths and weaknesses. WordPress may be the best overall CMS, but using it to its potential requires learning and using a lot of third-party plug-ins that must be properly maintained and oftentimes must be replaced with the next big thing.

  • Loremar Guimaraes says:

    One thing that really helps me to reduce training time is to screencast using Camtasia (or any other editor). If the client need to remember something the screencast is there. For small training I just share a Google Drive link with the main topics. If I need to explain something in more detail I split the screencast in digestable chunks. In the long run doing screencasts save me lots of phone calls and emails. Awesome article, thanks!

  • Jack says:

    Very impressive post. Thank you for sharing

  • Awesome article! If the client need to remember something the screen cast is there. For small training I just share a Google Drive link with the main topics. If I need to explain something in more detail I split the screen cast in digestible chunks. In the long run doing screen casts save me lots of phone calls and emails.