How Long Does It Actually Take to Build a Small Business Website?

“How long will this take?” It’s usually one of the first questions in any website conversation, and one of the hardest to answer honestly without knowing exactly what’s being built, who’s building it, and how ready everything else around the project actually is. A landing page and a custom booking system aren’t the same job, even though both technically count as “a website” on paper.

Rough timelines by project type

A single landing page usually takes about a week start to finish, once your content and any needed assets, logo, photos, are actually ready to go before work begins. A marketing site running five to eight pages typically takes two to three weeks, covering design, content placement, and a review round or two along the way as things get refined. A site with a CMS you’ll manage yourself sits in a similar range to a marketing site, plus a bit more time to set up and test the actual editing experience properly before handover. A custom web application, bookings, portals, integrations, varies a lot, but typically starts around four to six weeks and scales up with however much real functionality gets involved in the final scope.

What actually stretches a timeline out

Waiting on content is the single biggest delay on most projects, and it’s not close to the second-biggest cause. It’s not the build itself. It’s waiting on the client to send final copy, photos, or logo files that were promised early but arrive weeks late. A developer can’t finish a page sitting on placeholder text indefinitely without the project stalling entirely. Scope changing mid-build resets parts of the timeline too, even for small additions that feel minor at the time they’re requested. Slow review turnaround adds up fast as well. If a design or draft sits in your inbox a week before you respond, that whole week gets tacked straight onto your delivery date without anyone intending it that way. Agency versus freelancer capacity plays a role too. A larger agency juggling several clients at once can quote a longer timeline than a freelancer with one project active, purely because of how work gets queued up behind the scenes across their whole client list.

What you can actually do to keep your own project on schedule

Have your core content, page text, logo, key photos, ready before the project even starts, not sent in halfway through once work is already underway. Agree on the full scope upfront and get it written down somewhere everyone can refer back to, so “just one more page” doesn’t quietly stretch the timeline later without anyone noticing the cumulative effect. Set aside real time to review drafts promptly instead of letting them sit in an inbox for days. A same-week turnaround on your end keeps the whole project moving at the pace it actually deserves.

A realistic week-by-week example

For a typical eight-page marketing site: week one covers the scope call, proposal, and content gathering on your end. Week two is design and structure, with a first look sent your way for feedback. Week three is refinement based on your notes, plus technical setup, domain, hosting, forms. If everyone stays responsive throughout, launch happens near the end of week three or early in week four, right around the original estimate given at the start.

A red flag worth knowing about

A quote with no timeline attached at all, or one that says “it depends” without ever landing on an actual date once scope is agreed, is worth pushing back on directly. A fixed scope should come with a fixed, dated timeline attached to it. “It depends” is a fair answer before scope gets locked in, not after you’ve already agreed on exactly what’s being built together.

The honest bottom line

Most delays trace back to communication gaps, not the actual coding work itself. A developer who’s clear about deadlines and a client who responds promptly usually finishes close to the original estimate, no matter how the project started out or how complex it initially seemed.

Why bigger projects don’t scale timelines evenly

It’s tempting to assume a sixteen-page site simply takes twice as long as an eight-page one, but that’s rarely how it actually works out in practice. A lot of the timeline on any project is fixed setup time, the scope call, the technical foundation, domain and hosting configuration, that doesn’t grow much just because there are more pages involved. Larger projects often move faster per page than smaller ones once that foundational work is already done, which is one reason a mid-sized site sometimes surprises clients by finishing sooner relative to its size than a tiny one-page project that still needed all the same setup steps regardless of its smaller scope.

What to do if a project starts running behind

If a timeline starts slipping, the most useful thing you can do as the client is ask directly what’s causing the delay rather than just waiting anxiously and wondering. Sometimes it’s genuinely on the developer’s end, other times it traces back to a content delay or a slow review turnaround on your own side that’s easy to forget about once a few weeks have passed. A quick, honest conversation usually gets things back on track faster than silence does on either side of the relationship, and most delays turn out to have a simple, fixable cause once someone actually names it out loud instead of letting it linger unspoken.

Why rush jobs rarely turn out well for anyone

A compressed timeline sounds appealing when you need something live fast, but rushing a build usually means skipping the review rounds that catch mistakes before launch, or cutting corners on testing across different devices and browsers. A site built in half the normal time often needs a second round of fixes shortly after launch anyway, which ends up costing more total time than a realistic timeline would have taken in the first place. If speed genuinely matters more than anything else for your situation, say so upfront, and a developer can tell you honestly what corners would need cutting to hit that date, so you can decide together whether that tradeoff is actually worth it.

Want an actual date, not a wide range? A written proposal includes a dated timeline once scope is agreed, no open-ended “it depends” left hanging over the project.