How long does it take to build a website?
A focused landing page typically takes 3–6 weeks, a complete business website 6–12 weeks, and a complex platform or web application at least several months. These are realistic planning ranges when content is prepared, decisions are timely and the first-release scope is controlled.
The number of pages is only one factor. Delays are more often caused by missing content, unclear ownership, third-party integrations and scope changes introduced after design or engineering begins.
A typical delivery timeline
1. Discovery and scope: 3–10 working days
The team aligns business goals, audiences, journeys, functionality, success measures and technical constraints. A larger product may also require workshops, analytics review and a prototype of the critical workflow.
2. Information architecture, UX and content: 1–3 weeks
The sitemap, page hierarchy and key wireframes are created. Content should progress in parallel because real copy determines hierarchy and component needs. Designing every screen around placeholders almost always creates rework.
3. Visual design and prototype: 1–4 weeks
A strong process approves one representative direction before expanding it into a full component system. Typography, colour and brand character can then be resolved once instead of debated across many finished screens.
4. Development, CMS and integrations: 2–8 weeks
Timing depends on components, animation, languages and external services. Applications add data modelling, permissions, authentication, backend processes and non-happy-path behaviour.
5. QA, SEO and launch: 3–10 working days
The final stage covers device and browser testing, performance, redirects, structured data, analytics, consent management and form verification. Removing this step does not remove the work; it transfers risk to real users.
What commonly delays a project
No single decision owner. Feedback from several people should be consolidated by one product owner. Otherwise the team spends time reconciling incompatible preferences instead of improving the outcome.
Content arrives late. Copy, photography and legal materials should be planned during discovery. Their length and structure directly affect layouts, development and approval.
Scope changes without schedule changes. A new integration affects design, engineering and testing. Each addition needs a visible impact assessment and a decision: include it now or plan a later release.
How to move faster without sacrificing quality
Prepare goals, competitor references, analytics access and decision makers. Agree a regular review rhythm and a maximum feedback window. Start with the critical user journey and an approved component system rather than trying to finish every page at once.
If the launch date is fixed, reduce the first-release scope. A smaller complete website is safer than a large untested one. You can compare timing with our guide to website costs in 2026.
Timelines by project type
Landing page: what must fit into 3–6 weeks
A short schedule is realistic when the page has one goal, limited content variants and a clear offer. Structure and messaging should close first, followed by the visual direction, implementation, measurement and QA. A one-week delay in approved copy can block the rest of a tightly planned delivery.
Business website: how to plan 6–12 weeks
A multi-page site should approve page types and components rather than design every screen independently. Services, sectors, case studies and articles are then assembled from the system. Once the first patterns are accepted, content production and engineering can progress in parallel.
Web application: why delivery is organised into releases
A product deadline should refer to a defined release, not a permanently “finished” application. Build the critical workflow, data model and permissions first, then supporting capabilities. Every release needs migration, security and failure-path testing that may not be visible in design prototypes.
The critical path and parallel work
The critical path is the sequence of decisions that unlock later work. The proposition must be approved before final copy, and the data model before backend integrations. Mark these dependencies in the schedule and name the person accountable for each decision.
Photography, secondary copy, analytics configuration and technical environments can often progress in parallel. Parallel work saves time only when teams share approved assumptions. Starting everything at once while direction remains open multiplies rework rather than speed.
Project readiness checklist
Confirm the product owner, approvers, goals and metrics, first-release scope, content sources, access to the domain and systems, legal requirements, integration list, feedback process and planned absence of key people. Missing information may not prevent a start, but it should appear as a named delivery risk.
How milestone acceptance should work
Every stage needs a definition of done. Architecture may require an accepted sitemap and content inventory. Design may require all states of critical components. Engineering may require a CMS-connected workflow tested on the agreed devices. Acceptance criteria reduce subjective debate at the end of a stage.
Feedback should relate to the purpose of the stage, be consolidated in one place and distinguish defects from new requests. An accepted decision can still change, but the later change must have a visible effect on cost and schedule.
How much launch contingency is needed
Do not schedule the public launch for the day engineering ends. Leave time for content approval, domain configuration, redirects, consent, production checks and unexpected integration behaviour. Projects with more suppliers and decision makers need a larger coordination buffer.
What to prepare for the project kickoff
Bring current brand materials, access to analytics and the existing CMS, owners of the domain and integrations, relevant sales evidence, legal requirements and known infrastructure constraints. Name the people responsible for content, approvals and technical access. Every missing input should have an owner and a due date, even if it is not complete on day one.
The kickoff should close with an agreed objective, first-stage scope, communication rhythm, decision log and immediate actions. If the client and delivery team still define success differently afterwards, the schedule is only cosmetic; resolve the difference before production accelerates.
How to agree a credible deadline
Ask for a schedule with milestones, responsibilities and acceptance criteria. It should show client dependencies and time for revisions. To estimate your own launch, book a project conversation with N0VA and prepare the essential functions plus the business reason behind the date.
Frequently asked questions
Can a business website be completed in two weeks?
It can be possible for a very small scope with finished content and rapid decisions. A complete custom business website usually needs more time for discovery, design, implementation and quality assurance.
When should website copy be prepared?
Start during discovery and information architecture. Copy affects hierarchy, page structure and component requirements, so leaving it until after design creates avoidable rework.
Do animations add significant development time?
Simple microinteractions are straightforward to plan. Complex scroll sequences and transitions require motion design, implementation, optimisation and a reduced-motion alternative, so they should be included in the estimate from the start.