A schedule is a chain of decisions.
A concise marketing website with prepared content can move quickly. A redesign with several stakeholders, content migration and integrations needs more investigation, review and testing.
Instead of accepting a date in isolation, ask for the stages behind it. The schedule should show what the client needs to supply, when decisions are due and which technical unknowns could change the plan.
How long does it take to design and build a business website?
A professional business website often takes several weeks rather than several days, but there is no universal duration. The reliable estimate follows discovery. It depends on content readiness, unique page systems, integrations, feedback speed, migration risk and the depth of testing required for launch.
The phases that belong in a realistic website plan.
Some phases can overlap, but removing a label does not remove the work. A short schedule still needs a route through the same core decisions.
Discovery and scope
Clarify the objective, audience, content, features, technical constraints, approvals and launch responsibilities. Unknown integrations may need a separate technical check.
Structure and content
Agree the sitemap, page purposes, content hierarchy and calls to action. Writing and approving copy is often the largest client-side dependency.
Design and responsive states
Resolve the visual system on representative pages, then extend it across mobile, tablet and desktop states without treating smaller screens as an afterthought.
Development and integration
Build the components, content model, forms and external connections. Complex states such as errors, empty results and permissions need deliberate handling.
Quality assurance
Check content, links, forms, keyboard access, browsers, devices, performance, metadata, tracking where approved and operational handover.
Launch and observation
Coordinate domains, redirects and production configuration, then watch the live journeys. A launch plan should include ownership and a route to correct unexpected issues.
The five decisions that change the schedule most.
The calendar is usually controlled by dependencies, not by how quickly someone can draw a homepage.
Content readiness
Prepared, approved copy and images remove a major dependency. If messaging, photography or migration sit inside the project, allow time for production and review.
Number of decision-makers
One consolidated feedback route is faster than several independent reviews. Name the approver and agree how conflicting comments are resolved.
Distinct page systems
Ten articles using one template are different from ten individually designed landing pages. Estimate the number of unique structures and states, not only the URL count.
External systems
Bookings, payments, CRM, product feeds and authentication bring documentation, access, test environments and supplier response times into the schedule.
Migration and search protection
An established site may need a URL inventory, redirect map, metadata transfer and post-launch checks. That work protects existing value and should not be compressed into the final afternoon.
What a client can prepare to keep the project moving.
Fast delivery is usually a shared result. These preparations remove waiting without cutting quality checks.
One owner for approvals
Give one person authority to consolidate feedback and approve milestones. Record who must be consulted and who makes the final call.
Access before it is needed
Collect domain, hosting, analytics, CMS and integration access early. Do not send passwords in ordinary email; agree a secure transfer route.
A content inventory
Mark content to keep, rewrite, combine or remove. For a redesign, record the current URL beside its intended destination.
Protected review windows
Book feedback time in advance and review against the agreed objective. New ideas can be useful, but should be assessed as scope rather than folded in silently.
Which project shape needs more time?
This is a planning guide, not a fixed calendar. Each factor adds decisions, production work or release risk.
Focused launch
A narrow offer, a small set of page systems, prepared content and a direct enquiry route.
Content-led site
Several services, original messaging, reusable editorial pages and more internal review.
Established-site redesign
Existing rankings, analytics, content and URLs to inventory, migrate and protect.
Integrated website
Bookings, CRM, payment, search or other third-party systems with test states and access dependencies.
Web app
User flows, data, roles, validation and product decisions that normally require discovery before a delivery estimate.
Sources and further reading.
These primary sources inform the guidance above. Your project may need additional legal, security or accessibility advice for its own context.
Site moves and migrations
Google Search Central: Official guidance on URL mapping, redirects, testing and the temporary search fluctuation that can follow a migration.
Build the date from the scope.
Share the target date and the reason behind it. We can identify the critical dependencies, a sensible first release and the decisions needed to make the schedule dependable.
Project timescales questions.
Can a business website be built in one week?
A small site can sometimes be assembled quickly when the objective, content, design system and technical setup are already settled. That is not a useful default promise. Ask which discovery, content, responsive, accessibility, testing and launch tasks the schedule includes.
What usually delays a website project?
The common causes are unapproved content, fragmented feedback, missing account access, late feature changes and integrations that were not checked during scoping. A visible decision log and named owners help prevent each one.
Should all of the content be ready before design starts?
The key message, page purpose and representative content should be known before detailed design. Some writing can continue in parallel, but designing around unrealistic placeholder text creates rework when real headings, tables or proof arrive.
How long should website testing take?
Testing should be planned around the number of templates, interactive states, browsers, devices and integrations, not an arbitrary number of days. Leave enough time to fix and retest findings before the public launch.