Any honest answer to “how long?” starts with “it depends”, and the useful part is what it depends on. A timeline isn’t a fixed property of a website. It comes out of the scope, the number of systems involved, and how quickly content and decisions arrive. Several of those are in your hands, not the builder’s.
So rather than a number pulled from the air, here are the phases of a typical build, what makes each one longer or shorter, and what to ask so the date you’re given means something.
The phases, and what stretches each one
1. Scoping. Agreeing what the site has to do, which pages and features it needs, and what’s out. It stretches when several people need to agree and nobody has the final say, or when the goal is still fuzzy. A short, written scope at the end of this phase protects every later date.
2. Content. Text, photos, product data, team bios, legal pages. This is the phase that most often holds up everything after it, because design and build need real content to work with. It’s quick if you have material ready or have agreed someone will write it. It’s slow when it’s “we’ll send it next week” every week.
3. Design. Layouts for the key pages, usually shown as drafts you comment on. The variables are how many unique page types there are, how many rounds of changes, and how fast feedback comes back. Five people sending separate feedback a week apart can stretch it a long way without anyone noticing.
4. Build. Turning the design into a working site. Driven mainly by functionality: a booking system, a shop with variants and shipping rules, a members’ area, a second language, or connections to a CRM or accounting system each add work. Integrations also depend on third parties, such as getting API access or an account set up with a payment provider.
5. Review and testing. Checking every page on phones and desktops, testing forms and payments, fixing what turns up. You’ll need to look through it too. If you have to collect sign-off from several people, plan for that.
6. Launch. Pointing the domain at the new site, setting up redirects from old pages if you’re replacing a site, connecting analytics and Search Console, and checking that forms still reach the right inbox. Small tasks, but they need someone with access to your domain account to be available on the day.
What usually causes delays
- Content arriving late or in pieces.
- No single decision-maker, so feedback loops back and forth.
- New features added midway. Sometimes worth it, but each one moves the date.
- Waiting on access: domain logins, hosting, the old site, third-party accounts.
- An integration that turns out to work differently from what was assumed.
Most of these can be spotted at the start, which is why a good scoping conversation is the best predictor of a realistic date.
How to get a timeline you can trust
Ask whoever is building the site for:
- A dated plan per phase, not just a launch date.
- What they need from you, and by when. Content, feedback, access. A plan with no client deadlines in it isn’t a real plan.
- How many feedback rounds are included in design and review.
- What happens to the date if something slips on either side.
- What’s in this launch and what’s a later phase. Shipping a smaller first version and adding to it is often the fastest way to get a working site live.
And on your side: name one person who makes decisions, gather feedback into one message per round, and get the content moving before design starts.
If you have a deadline, such as a launch event, a season or an ad campaign, tell us the date and what the site needs to do, and we’ll tell you honestly whether it’s realistic. For the money side of the same question, see what a website actually costs, and for how we run builds, our web service page.