How Long Does It Take to Build a Website? An Honest Set of Numbers

A one-page site with a template and your content ready: an afternoon. A small business site of ten to fifteen pages: one to two weeks yourself, four to eight weeks with an agency. A custom application: six months and up. The number that surprises people is that development is rarely the longest phase — waiting for content usually is.

Estimates for this question are usually given by people who benefit from a particular answer. Here are ranges that match what projects actually take, what drives the variance, and the two things that delay most launches regardless of how fast anyone builds.

Table of contents

• Realistic ranges by project type
• Where the time actually goes
• What makes projects take longer than estimated
• What technology choice does and does not change
• Shortening the timeline honestly
• What nobody includes in the estimate
• How this fits the rest of the stack
• FAQ

Realistic ranges by project type

• Single landing page — half a day to two days yourself; three to five days professionally. Assumes copy exists.
• Brochure site, 5 pages — two to four days yourself; one to two weeks professionally.
• Small business site, 10-15 pages with a blog and forms — one to two weeks yourself; four to eight weeks professionally.
• Small store, under 50 products — three to six weeks yourself; eight to twelve weeks professionally.
• Large store, 500+ products — three to six months, and product data is the bulk of it.
• Custom web application — six to twelve months and up. This is software, not a website.
• Redesign of an existing site — often longer than building new, because of migration, redirects, and preserving what works.

The professional timelines are longer, and that is not padding. They include discovery, revision rounds, feedback cycles, and testing across devices. A solo build skips those and accepts the risk that comes with skipping them.

The last row deserves attention. A redesign carries constraints a new build does not: existing URLs to preserve, content to migrate, and a live site that cannot break. Teams routinely budget a redesign as less than new and it usually is not.

Where the time actually goes

For a typical small business site, roughly:

• Planning and information architecture — 10-15%. What pages exist, what each is for, how they connect.
• Design — 20-30%. Wireframes, visual design, revisions. The revision rounds are where this expands.
• Development — 25-35%. Turning approved design into a working site.
• Content — 20-30%, and this is the number everyone underestimates.
• Testing and launch — 10%. Devices, browsers, forms, performance, accessibility.

Development is rarely the bottleneck. In most stalled projects the build finished on schedule and the site sat waiting for copy, photographs, or a decision about the About page that nobody wanted to make.

This is worth saying to anyone commissioning a site: the fastest way to shorten your timeline is to have your content written before development starts. Not outlined — written, proofread, and signed off. Doing that reliably takes weeks off a project, and it costs nothing.

What makes projects take longer than estimated

1. Content that does not exist. Estimates assume text and images are ready. They almost never are, and we will write it as we go means the site launches when the last page is written.
2. Unclear approval. If three people must agree and none has final say, every revision round doubles. Name one decision-maker.
3. Scope creep. Each could we also is small and they compound. A booking system added mid-project is not a small addition.
4. Third-party integrations. A CRM, payment provider, or booking tool with unfamiliar or poor API documentation is the classic schedule risk.
5. Migration from an existing site. Preserving URLs, redirects, and rankings is real work that gets omitted from estimates entirely.
6. Feedback latency. A three-day turnaround on each review round adds a fortnight over five rounds, and nobody counts it.

Feedback latency is the invisible one. Clients think of the timeline as the builder’s time; in practice a meaningful fraction is waiting for responses. Agreeing a maximum review turnaround up front does more for a schedule than any tooling decision.

What technology choice does and does not change

The platform matters less than people expect for a straightforward site.

• Site builders and templates — fastest to a passable result, with a ceiling on customisation and portability.
• WordPress with a theme — fast, flexible, and the maintenance burden is real: updates, plugins, security.
• Static site generators — fast to build for content sites, near-zero running cost, and a build step non-technical editors need help with.
• Custom frameworks — slowest to build and the only option when the site genuinely is an application.

Choosing a faster stack saves days. Having your content ready saves weeks. That ratio is worth keeping in mind before spending a fortnight comparing platforms.

Where technology does affect the schedule meaningfully is deployment and iteration speed. A setup where changes go live in minutes with a build log and a rollback lets you launch earlier and improve continuously. One where deploys are manual, risky, and require a person means changes queue up into batches, and each batch is an event.

That is worth optimising for, because launch day is not the end of the work. On RunxBuild, deploys come from a repository with build logs, a live route, and rollback to the previous deploy — the static sites documentation covers the build-from-repository path for content sites, with 120GB bandwidth included.

Shortening the timeline honestly

1. Write the content first. Before design, before development. This is the single largest lever and it is entirely within the client’s control.
2. Launch smaller. Five excellent pages beats fifteen mediocre ones, and you can add the rest afterwards. A site is not a building; it does not have to be finished to open.
3. Use a template and customise. Custom design from scratch adds weeks and, for most small business sites, adds little the visitor notices.
4. Name one decision-maker. Committees do not shorten timelines.
5. Cap revision rounds — two rounds of design feedback, agreed in advance. Unlimited revisions is how projects run for a year.
6. Defer integrations. Launch with a contact form; add the CRM integration in month two.
7. Agree a feedback turnaround and hold both sides to it.

Launching smaller is the one people resist and the one that helps most. A site live in three weeks that improves monthly beats a perfect site that launches in six months, because the live one is generating enquiries and telling you what visitors actually want.

The corollary is that your first version does not need to be right. It needs to be live, measurable, and easy to change — which is an argument about deployment setup more than about design.

What nobody includes in the estimate

The launch is not the end, and the ongoing work is a real cost that estimates routinely omit.

• Hosting and domain — ongoing, and the one thing everybody remembers.
• Updates and security — WordPress needs regular attention. A neglected install is a liability rather than an asset.
• Content maintenance — a blog nobody updates is worse than no blog.
• Performance monitoring — sites get slower as content and plugins accumulate.
• Backups, tested — an untested backup is a hope, not a plan.
• Analytics review — the site tells you what to fix, if anyone reads it.

Budget a few hours a month for a small site and more for anything transactional. Projects that skip this arrive two years later with a site nobody has touched, running an unsupported PHP version, with a contact form that stopped delivering email eight months ago and nobody noticed.

That last failure is astonishingly common, and it is why monitoring and logs matter more than they sound. A contact form silently failing is invisible without them, and it is directly lost business.

How this fits the rest of the stack

A brochure site is days, a small business site is weeks, a store is months, and an application is longer than that. Development is rarely the constraint — content and approvals are. Write the copy first, name one decision-maker, cap the revisions, and launch smaller than you planned. If you are budgeting the ongoing side and want hosting, database, and bandwidth as separate line items rather than one bundled figure, the RunxBuild hosting calculator breaks them out.

Useful related references:

• Redis Get All Keys: The Right Command, the Wrong Command, and the One That Will Take Down Production
• SSH Using a Private Key: The -i Flag Is the Wrong Long-Term Answer
• How to Troubleshoot a Load Balancer: 502s, Health Checks, and the Long Tail
• Builds on RunxBuild

FAQ

How long does it take to build a simple website?

A single landing page with content ready takes half a day to two days yourself, or three to five days professionally. A five-page brochure site is two to four days yourself and one to two weeks with an agency.

Why do website projects take longer than estimated?

Most often content that was not written before development started, followed by unclear approval processes and slow feedback turnaround. Development finishing on time and the site waiting weeks for copy is the standard pattern.

Does using WordPress make a website faster to build?

Somewhat, for a standard site with an existing theme. But platform choice typically saves days while having your content ready saves weeks, so it is not where the leverage is.

How long does an e-commerce site take?

A small store under 50 products takes three to six weeks yourself or eight to twelve professionally. Large catalogues run to three to six months, with product data entry and image preparation forming the bulk of it.

What is the fastest way to launch a website?

Launch smaller. Five strong pages published in three weeks beats fifteen pages in six months, because the live site generates enquiries and shows you what visitors actually want before you build the rest.