How Long Does a Website Project Take, Realistically?

"How long will this take?" is one of the first questions in almost every web design enquiry, and the honest answer depends more on you than on the designer. This guide sets out typical timelines by project size, walks through a ten-page project week by week, explains what each phase involves and what reliably adds weeks, lists what you can do before kickoff to shorten the whole thing, and covers the part after launch that most timelines leave out.

The short answer: typical timelines by size

As a rough guide, once content is ready: a five-page site takes 2 to 4 weeks, a ten-page site 4 to 6 weeks, and a larger site of up to twenty pages, or one with e-commerce, a booking system or multiple languages, 6 to 10 weeks or more. These ranges assume the client responds to drafts within a few days each round — the same project can run much longer if feedback and content arrive slowly.

Timelines by project type at a glance

The additions stack: a ten-page site with a store and a second language is a 8-to-12-week project, not a 6-week one.

The single biggest variable: how fast you respond

A designer's own build time is fairly predictable and usually the smaller part of the calendar. What varies enormously is the client side: how quickly content, images and feedback arrive, and how many rounds of changes are requested. Two projects of identical size and price can finish weeks apart purely because one client turned drafts around in two days and the other took two weeks each time.

A ten-page project, week by week

This is what a typical six-week, ten-page business site looks like when the client is ready and responsive. Slower feedback stretches each row rather than adding new ones.

A worked example: two ten-page projects, four weeks apart

Both of these are real patterns, not edge cases. Client A signs the quote, and within three days has sent the logo, brand colours, every page's text and a folder of full-size photos. Each draft comes back reviewed within two days, with one consolidated list of changes rather than a stream of messages. That project runs the full six weeks from the table above and launches on schedule.

Client B signs an identical quote for an identical ten-page site. Content arrives in pieces over three weeks rather than at kickoff — two pages of text on day four, photos a week later, the remaining pages only after a reminder. Feedback on the homepage draft takes ten days to come back, split across two emails and a phone call that each add something new. No step in the build itself took longer than for Client A; the same six weeks of design and build work simply happened across fourteen calendar weeks instead of six, with the designer waiting for most of the gap.

The lesson isn't that Client B did anything unusual — most projects look more like Client B than Client A. It's that the quoted timeline describes the designer's work, not the calendar, and the gap between the two is almost entirely filled by whichever side is waiting on the other.

What each phase actually involves

• Scoping and quote. Pages, add-ons and price are agreed — see our guide on what to prepare beforehand to speed this up.
• Design draft. A layout and visual direction for you to review — usually the homepage first.
• Build. The rest of the pages are built to match the approved design, once it is signed off.
• Revisions. A round or two of changes, agreed upfront so it doesn't run open-ended.
• Testing and launch. Checking links, forms and mobile display before the site goes live.

Content collection can run alongside scoping and design if you start gathering it early — this is what actually saves the most time, more than any part of the build itself.

What extends the timeline

Beyond slow feedback, three things reliably add weeks: e-commerce or booking functionality (each product or service needs its own entry, plus a payment gateway to configure and test), additional languages (each needs its own translated content, not just a copied layout), and scope changes mid-project (adding pages or features after the build has started re-opens work that was already finished). Less obvious delays come from waiting on a third party: a logo still being designed elsewhere, domain access held by a former web designer, a photographer's shoot booked for next month, or a payment gateway application that takes a week to approve.

• Payment gateway approval: typically a few business days to about a week once the application is submitted — start it the week the quote is signed, not the week the store is ready to go live.
• Domain access recovery: a day to over a week if a former designer or an old staff member holds the login, since it depends on them responding.
• A booked photography session: often the single longest wait on the client side, since a photographer's calendar does not move to match a website's.

What to do before kickoff to shorten the whole project

• Write the content first, or decide now that the designer will write it. A page cannot be built around text that does not exist yet.
• Gather images of your real team, premises and work; a folder of originals at full size, not screenshots from WhatsApp.
• Find the logo files in a vector or high-resolution format, and the brand colours if you have them.
• Confirm who controls the domain and that you can log in to the registrar. Our guide to who owns your website explains what to check.
• Choose one decision-maker for approvals. A committee reviewing each draft adds a week per round.
• Apply for any payment gateway or booking tool accounts as soon as the scope includes them, not when the build reaches that step.
• Block time in your own calendar for reviewing drafts in the weeks the schedule says they will arrive.

Giving feedback that does not cost a week

Most lost time is not in the designer's queue but in feedback that arrives in pieces: a WhatsApp message on Monday, an email on Wednesday, a phone call on Friday that contradicts both. Review a draft once, properly, on a phone and a desktop, and send one consolidated list with page names and specific changes. Say what is wrong and, where you can, what you want instead, rather than "make it pop". Approve what is right explicitly so it is not revisited. A single clear round of feedback turns around in days; five partial ones take weeks and usually produce a worse result.

Launch is not the end of the timeline

The day the site goes live is the end of the build, not of the project. If the domain's settings change at launch, the new address can take from a few hours to a day or two to reach everyone. Search engines then need time to find and index the pages: expect days for the homepage and weeks for the full site to appear, which is normal and not a fault. Forms should be tested after launch, not only before. Our pre-launch checklist covers what to check on launch day, and our guide to why a new website isn't showing on Google yet explains the weeks that follow.

Can you pay to go faster?

To a point. A designer can prioritise your project or add resource to speed up the build itself, but they cannot speed up how quickly you review a draft or supply content — and that is usually the larger share of the timeline. Being ready and responsive shortens a project more reliably than paying for rush work.

Rush pricing, where it is offered, usually buys priority in the build queue and extra hands on the design and build steps — it compresses the designer's side of the calendar, which, as the worked example above shows, is often the smaller side to begin with. It does not buy faster content from you, faster feedback, or faster approval from a payment gateway provider. Before paying for speed, it is worth checking which side of the project is actually slow.

Common mistakes

• Starting without content and assuming it will arrive during the build. It is the single most common cause of a project doubling in length.
• Feedback in fragments from several people. One reviewer, one list, one round.
• Adding pages or features mid-build. Park them for a phase two.
• Leaving the payment gateway application to the end. Approval takes time you cannot compress.
• Reviewing only on a desktop. The mobile problems found after launch could have been found in week five.
• Treating launch day as the deadline for marketing. Search visibility follows weeks later; plan around it.
• Agreeing a date without agreeing the revision rounds. Unlimited revisions have no end date.
• Assuming the quoted weeks are calendar weeks. They are working weeks; a quote of six weeks describes the build, not a guaranteed launch date six weeks from signing.

Where Gotka Technologies fits

Gotka's package builder gives you a scope and price upfront, which is the first step of any timeline. Web design covers everything from a five-page Starter site through to a twenty-page Growth build with e-commerce, and hosting is ready from RM17.80/month so launch is not held up on that end. Professional copywriting is available as an add-on for businesses that would rather not write the content themselves, which removes the most common delay before it starts.

Key terms used in this guide

• Kickoff: the point at which scope and price are agreed and work begins; timelines count from here.
• Scope: the agreed list of pages, features and languages the project includes.
• Design draft: the first visual layout, usually of the homepage, presented for review before the rest is built.
• Revision round: one consolidated set of changes requested after a draft; projects usually include one or two.
• Scope change: a page or feature added after kickoff, which re-opens finished work.
• Payment gateway: the service that processes card or bank payments on an online store; it needs its own application and testing.
• DNS propagation: the period after a domain's settings change during which the new site reaches all visitors.
• Indexing: search engines discovering and listing the pages of a new site, which takes days to weeks after launch.