You are planning a website and you need to know how long it will take, because something else depends on it, a launch, a campaign, a rebrand, or simply knowing when you can stop thinking about it. The trouble is that the answers you have been given do not agree. One source says a few days, another says over a month, and you cannot tell which applies to you.
The honest answer is that it depends, but not vaguely: it depends on a specific and knowable set of things, most of which are within your control. This article explains why the same question gets such different answers, what genuinely sets a website's timeline, and a realistic sequence from first conversation to launch, so you can plan around a timeframe that actually fits your project.
Why the same question gets three different answers
Ask three suppliers how long a website takes and you will often get three very different numbers, and the reason is not that one is honest and the others are not. It is that they are each measuring something different.
Some quote build days only, the time their team spends actively building once everything they need is in hand. That number can look impressively short because it leaves out everything that happens before and around the build. Others quote from the day you sign, which includes all the back and forth of content, feedback and approvals, and so comes out much longer. And some quote a timeframe that quietly assumes your content already exists, ready to drop in, which is rarely the case for a business starting fresh.
None of these is wrong exactly, but they are answering different questions, which is why they cannot be compared directly. The number that matters to you is the one measured from where you actually are, with the content you actually have, to a finished live site. When you understand what a quoted timeframe is counting, the contradictions stop being confusing and start being useful.
What actually sets the timeline
Behind every timeline sit a handful of factors. These, not the design software or the team's speed, are what decide whether a project takes two weeks or two months.
- Content readiness. Whether the words for your pages already exist, or still need to be written, is the single biggest factor. A site with copy ready to go moves quickly; a site waiting on content waits, no matter how fast the build team is.
- Photography. Images matter the same way. Professional photos, or sourcing and selecting them, take time, and a project often pauses while the right images are found or shot.
- Page count. A small site and a large one are different jobs. More pages mean more to design, more to write and more to review, and the timeline grows with the count.
- eCommerce and integrations. An online store, or connections to booking, payment or other software, add real work. Product data, payment and shipping setup and the testing they require all extend a timeline beyond what a simple brochure site carries.
- Approval rounds. Every round of feedback and sign-off takes as long as it takes the people giving it. A project with prompt, decisive approvals moves; one waiting on a busy approver stretches out.
None of these can be reduced to a fixed number of days on its own, because each depends on your project and your inputs, but together they explain almost every difference in how long a build takes.
A realistic sequence for a standard business site
Rather than a schedule, think of a build as a sequence of stages, each feeding the next. It helps to see how we run a project laid out, because the order is what makes a timeline make sense.
It usually begins with discovery, understanding your business, your goals and what the site needs to do. From there comes structure, mapping out the pages and how they fit together, so everyone agrees what is being built before design starts. Then design, where the look and feel take shape and get your sign-off. Then the build itself, where the approved design is turned into a working site. Then content load, where the words and images go into the pages, which is why content readiness matters so much to the overall timeline. Then review, where you check the site, request changes and approve it. And finally launch, where the finished site goes live.
Each stage depends on the one before it being settled, which is why a hold-up early, an unapproved structure or missing content, pushes everything after it back. Understood as a sequence rather than a fixed calendar, the timeline becomes something you can see and influence, because you can see exactly where your inputs feed in and keep things moving.
What slows projects down most often
In practice, two things stretch timelines more than anything else, and in this order: content and approvals.
Content is first because it depends on people who already have a full-time job doing something else. Writing the copy, gathering the photos, deciding what each page should say, these fall to busy people, and they are easy to put off. A build team can be ready to go and still be waiting. Approvals come second for the same underlying reason: feedback and sign-off take as long as the people giving them take, and a project can sit idle waiting on a review.
The good news is that both are the parts you most control. You can prepare your content before the project starts, draft the copy, gather or shoot the photos, decide your key messages, so it is ready when the build needs it. And you can line up who will give feedback and approvals, and commit to turning them around promptly. Doing these two things is the single biggest influence you have on how quickly your site is finished.