The Short Answer

A landing page takes one to two weeks. A multi-page business site takes three to six. An online store takes five to eight. A web platform with accounts and integrations takes eight weeks and up. Those are working timelines with a design already agreed, not best-case sprints. The number that varies most is not the development — it is how long the project spends waiting for you.

Realistic Timelines by Type

• Landing page — 1-2 weeks. One template, one flow, one form. Add a week if the design is being made from scratch
• Business site, 5-8 pages — 3-4 weeks with a ready design, 5-6 weeks including design
• Corporate site with blog, multiple languages and animation — 5-7 weeks. The second language and the motion work each add roughly a week
• Online store — 5-8 weeks. Catalogue structure, filters, payments, delivery rules and test orders all take real time
• Web platform or application — 8-16 weeks, and it is delivered in stages rather than as one launch
• Redesign of an existing site — add 1-2 weeks to the equivalent new build for content migration and redirects

Where the Time Actually Goes

For a typical business site, the split looks roughly like this. Notice how little of it is the part most people picture when they think about building a website.

• Brief, structure and page-type planning — about 10%. Cheap to do, expensive to skip
• Design — about 30%, and the phase with the most back-and-forth
• Layout and development — about 35%. The predictable part; this is the part that rarely surprises anyone
• CMS integration and content entry — about 15%, and it is the phase most often forgotten in the estimate
• Testing, performance, SEO basics and launch — about 10%. Cutting this is how a site launches broken on mobile

What Actually Makes Projects Run Late

In eight years and a few hundred delivered projects, I can count on one hand the times the bottleneck was writing code. It is almost always one of these.

• Content that does not exist yet. Texts, photos and product data are usually promised for week one and arrive in week five
• Feedback by committee. Four people reviewing separately produces contradictory notes and a second round that nobody planned for
• Scope added mid-build. Every "while we're at it" is a real change to structure, design and testing
• Third parties: payment providers, CRM vendors, hosting or domain access. Their response time becomes your timeline
• Decisions with no owner. If nobody can approve the homepage, the homepage does not get approved

How to Genuinely Compress It

• Have the content ready before design starts. This single thing can take two weeks off a project
• Name one decision maker. One person who consolidates feedback and says yes
• Agree the page types up front and freeze them. New page types mid-project are new projects
• Give access early: domain, hosting, analytics, any accounts we will need on launch day
• Launch in stages. A live site with five pages beats a perfect one in three months — the rest can follow
• Review in batches, in one document, once per phase, rather than in messages across a week

About "We Can Do It in Three Days"

It is usually true and usually useless. Three days buys a template with your text in it — no structure work, no performance tuning, no SEO foundation, no testing beyond the developer's own laptop. That is a fine choice if you need a placeholder before an event. It is a poor choice if the site is supposed to bring you customers for the next three years, because everything skipped in those three days comes back as a rebuild later.

Conclusion

Ask for a schedule with phases and dependencies, not a single date. A plan that says "design by the 14th, provided texts arrive by the 7th" tells you the truth about who is holding what. If you have a hard deadline — a launch, a season, a trade show — say so at the start. Timelines can be built around a fixed date by staging the release, but only if the date is known before the plan is made, not after.