How Long a Website Really Takes, Stage by Stage

A small brochure site with the words already written can be live in a few weeks. A site with a shop, customer accounts and a link into software you already run is a matter of months. Everything in between is set by how many genuinely different layouts have to be designed, how much has to talk to other systems, and how quickly decisions and content come back to the people building it.

That third one is the surprise. Most people assume the developers are the slow part. In practice the calendar is set by how long a decision takes to travel through your company, and by whether anybody has written the words for the pages nobody volunteered for.

What follows is where the time actually goes. The order matters more than the durations, because these stages overlap less than people hope, and the ones that can overlap are not the ones you would guess.

This is the stage where the scope stops being a conversation and becomes a document. A list of pages, a list of features, a list of the systems the site has to speak to, and a plain statement of what is not being done this time.

For a simple site it is an afternoon. For anything with logins, payments or an integration it is days of work spread over a couple of weeks, and the spreading is the problem. The work itself is not what takes the time. Getting the right people in the same room is.

The usual stretch is a committee. If marketing, finance and whoever runs the warehouse system all have to agree, the calendar is set by diaries rather than by effort. Name one person who can say yes without going back to a group. That single decision does more for the timeline than any technical choice in the project.

Write down what the site is not doing as carefully as what it is. Every week saved later comes from a sentence written here.

Design normally runs in two parts. A small number of key pages first, to settle the direction, then the rest once somebody has agreed to it. That first part is where the real thinking happens and where the feedback has to be sharpest.

The work itself is quick relative to the calendar it occupies. Here is the shape of a typical slip. The designer sends the homepage on a Tuesday. One director replies on Thursday. Another has notes the following Monday. Marketing sees it a fortnight later and wants the whole thing warmer. Three days of work, one month of calendar.

The fix is unglamorous and it works. Collect all feedback into one document, from one owner, by a stated date, and send that date out with the design. Feedback arriving in pieces costs a full turnaround each time, and turnarounds are what fill a project plan.

Design and build can overlap more than people expect. Navigation, buttons, forms and the general structure can be built while later page designs are still being drawn, as long as the direction is settled.

For an ordinary site on a common platform this is the most predictable stretch of the project, and it is usually shorter than the client expects. Pages get built, the editing system gets set up, forms get wired to somewhere real.

Anything with accounts, payments or an integration stretches it, and the stretch is rarely in the obvious feature. It sits in the cases that go wrong: the payment that half completes, the other system that does not answer, the stock count that disagrees with itself.

The delay that catches nearly everybody is access. Keys for the payment provider. A test account on the courier system. Credentials for the software the site has to write into. Somebody in another company has to approve each of those, and that company has its own queue. Raise every single access request in the first week, long before anybody needs it. This is the cheapest week you will ever save.

Ask to see something working every week from early on. Not a screenshot. Something you can click. Surprise at the end of a build is what costs a month.

Content is the bottleneck on most website projects, and it is not close. The site gets built, the placeholder text sits on page after page, and everything stops while somebody in your company tries to find an afternoon.

There are good reasons for it. Writing about your own business is genuinely hard. It is nobody's main job, it competes with work that has a customer waiting, and it usually needs approval from somebody senior who is travelling. Photography needs a day in the diary that never has a free slot.

The remedies are all boring and all effective. Start writing before design finishes rather than after. Give every page an owner and a date, in the same plan as the code, with the same weight. Accept a short honest page over a long unwritten one. And if nobody has the time, buy the writing, because a writer interviewing your staff for a morning produces more usable copy than three months of good intentions.

One more. Do not wait for every page. Launch with the pages that matter written properly and add the rest afterwards. Holding an entire site because two secondary pages are unwritten is the most common self inflicted delay in this business.

Testing takes days rather than weeks on a small site, and it is the stage most often squeezed, because it sits directly in front of the date everybody has already announced.

What stretches it is usually a disagreement arriving disguised as a bug. Somebody sees the site properly for the first time during testing and asks for changes that are really design decisions being reopened. Weekly demos from early on are the only reliable prevention.

Launch day itself is a checklist: point the domain, install the certificate, keep email working through the change, put the redirects live, check the forms, watch the errors. Half a day if it was planned. Do not launch on a Friday. Do not launch in the week your one developer is away.

Then keep a fortnight after launch in the plan. Real visitors find things no test finds, and you want the people who built it still paying attention when that happens.

In rough order of frequency: content that has not been written, decisions waiting on somebody who is busy, scope added in the middle, and access to a third party system that took weeks to arrange.

Scope creep is worth understanding properly, because it never arrives as a big request. It arrives as a reasonable small one, repeatedly. Could it also send a text message. Could we add a second language. Could the form ask two more questions and route to different people. Each is small. Together they are a month, and nobody can point at the meeting where the month was agreed.

The cause nobody writes in a status report is that the project has no owner on your side. Somebody has to chase content, collect feedback, chase the payment provider and make the small calls. When that job belongs to everyone, it belongs to no one, and the project moves at the speed of whoever remembers it that week.

Work backwards from a real event rather than a hopeful one. A trade show, a season, a lease ending. A date with a reason behind it survives pressure. A date somebody picked because it sounded about right does not.

Write the content first. If you take one thing from this article, take that one. Then name a single decision maker, get every access request in during the first week, and split the launch so that the first phase goes live and the rest follows.

A phased launch is the most underused option available to you. The site does not have to arrive complete. A live site being improved beats a perfect site three months late, and it starts earning while the rest is finished.

The honest caveat is this. A date that never moves usually means something else moved, and the something else is normally testing or content quality. Decide at the start which one is genuinely fixed, the date or the scope, and say so out loud. Projects that pretend both are fixed give you a launch you spend the next quarter repairing.