Four to six weeks, and here is where it goes
For a service business site — call it ten to thirty pages, a quote form, booking, and proper tracking — four to six weeks from kickoff to live is a normal, unhurried timeline.
Not four to six months. Not "we will know more once we get into discovery". The work is well understood and the sequence is well established. Where projects genuinely take longer, it is almost always because of something specific and nameable: a complex integration, an ecommerce catalogue, a migration of thousands of URLs, or content that does not exist yet.
If someone quotes you six months for a standard service business site, ask which of those applies. If none does, you are being quoted for their queue rather than your project.
What actually happens each week
Week 1 — audit and scope. Going through the current site, traffic, and conversion path. Agreeing the sitemap, the integrations, the price, and the launch date. Everything in writing before anyone opens a design tool. This week is mostly you talking and us listening, and it is the week that determines whether the rest goes smoothly.
Weeks 2–3 — design and build against real content. Not a static picture of a homepage for approval, but working pages you can open on your phone. Designing against real text and real photos rather than placeholder copy avoids the classic failure where everything looks great until the actual content arrives and does not fit.
Week 4 — the rest of the pages, forms, and tracking. The unglamorous majority of the work. Every form tested end to end, every conversion event verified firing, schema in place, images compressed.
Week 5 — redirects, review, launch. Mapping every existing URL to its new home, checking every conversion path by hand, then going live. Launch itself takes an afternoon; the preparation is what takes the week.
Week 6 onward — watching real traffic. Fixing what real visitors reveal. This is where a build stops being a project and starts being an asset, and it is the part most agencies treat as out of scope.
What actually causes delays
In our experience it is almost never development. It is these, in order:
- Content. Service descriptions, staff details, prices. This is the number one cause by a wide margin, and it is the one thing only you can produce.
- Photos. Everyone underestimates how long it takes to gather twenty good photos of their own work. Start the day you sign.
- Access. Domain registrar logins, current hosting, analytics accounts. Recovering a domain from a developer you fell out with in 2019 can take weeks on its own — start that immediately, before anything else.
- Decision-making by committee. Two decision-makers is fine. Five is a schedule risk, and it is a risk that shows up as three rounds of contradictory feedback in week four.
None of these are anybody's fault. They are just predictable, which means they can be planned for by front-loading them into week one.
When fast is a warning sign
Speed is not automatically good either. Be suspicious of a site delivered in a few days, because the corners being cut are the invisible ones:
- A template with your logo dropped on and nothing rewritten for your business.
- No redirect mapping, so your existing rankings evaporate on launch day.
- No tracking, so nobody can tell whether the new site performs better or worse.
- Uncompressed images, because compressing them takes time nobody billed for.
- Stock photos of other people's work, which quietly costs you the trust the site was meant to build.
The middle of the range is where the good work lives. Very fast usually means a template; very slow usually means a queue.
Launch day is the start, not the finish
A new site does not rank on day one and does not convert perfectly on day one. Anyone who tells you otherwise is selling.
The first ninety days are where the value is: watching what real visitors do, finding the page where everyone leaves, discovering that the form has a confusing field, learning which service pages get traffic and which do not. That feedback cannot be simulated in advance, which is exactly why a "final delivery, we are done" model produces worse sites than an ongoing one.
You do not need to keep an agency on retainer for this. You do need someone — including you — who looks at the numbers monthly and acts on them.
Questions people ask about this
Can I speed it up by paying more?
A little, but not much, and mostly by removing your own bottlenecks rather than ours. If your content and photos are ready on day one and you can make decisions inside 24 hours, a project can compress meaningfully. Paying to skip the redirect mapping or the testing is not speed, it is deferred cost.
What if I do not have content ready?
Then say so at the start and budget for it, either in time or in money. We can write it from interviews, which is faster and usually better than waiting for someone to find a spare weekend. What does not work is starting the build and hoping content appears in week three.
Should I launch all at once or in stages?
All at once for a site this size. Staged launches mean two sets of redirects, two testing cycles, and a period where your site is half old and half new. Staging makes sense for large sites, complex migrations, or when a single section carries most of the traffic and needs to move carefully.
