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.
The critical path: tasks that genuinely control the launch date
Some tasks move the entire schedule when delayed. They usually include scope approval, content delivery, architecture decisions, integration access and acceptance of representative designs. Adding more parallel activity does not help when one of these dependencies remains open.
A useful plan names the owner of every decision, the response deadline and the consequence of missing inputs. A decision log prevents the project from reopening settled questions several weeks later.
What can run in parallel
Once the structure is stable, a team can develop the design system, write content, model data and configure environments at the same time. Parallel work only saves time when shared assumptions are settled. Building screens around unapproved copy usually creates rework.
The client’s role in meeting the deadline
The client supplies domain knowledge, consolidates feedback and makes timely decisions. They do not need to write a technical specification, but they should nominate one accountable product owner and reserve time for regular reviews.
Can a website be delivered faster?
Yes, when the scope is deliberately reduced. The team can use fewer unique templates, launch one language first, defer secondary integrations or use a proven component system. Form testing, accessibility, mobile behaviour and essential technical SEO should not be removed to create an artificial deadline.
If launch is tied to an event, campaign or regulation, define a complete first release and a post-launch backlog. Keep a contingency for critical fixes and third-party approvals.
Launch planning and the first 30 days
Before release, verify the domain, TLS certificate, redirects, canonicals, sitemap, robots rules, analytics, consent, forms, transactional email and backups. Replacing an existing website also needs a dedicated website delivery plan.
After launch, monitor server errors, indexation, analytics events, Core Web Vitals and enquiry quality. Early data should refine journeys rather than trigger a complete strategic rewrite. Many websites need several weeks to collect representative behaviour.
How to request a realistic schedule
Ask for phases with outcomes, dependencies, decision deadlines and contingency. Confirm whether quoted weeks are calendar weeks, working weeks or team availability. The start event must be explicit: signature, deposit, workshop or receipt of content.
For websites, applications and integrations, N0VA web development can be organised into accepted releases. Each release should end with a working result that can be tested and reviewed.
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.
Does the timeline include writing the website content?
It should if the supplier owns copywriting. If the client supplies content, the plan must show delivery dates and explain how delays affect design and development.
How long does a second language version take?
Usually several days to several weeks after the structure is stable. Volume, translation review, forms, metadata, imagery and hreflang quality all affect the duration.
Can a website project begin without a finished logo?
Discovery and architecture can begin, but an unsettled identity slows final visual design. The core brand system should be approved before the main design direction is signed off.
What is schedule contingency?
It is planned time for unexpected issues, corrections and external dependencies. It does not replace sound planning, but protects the launch from common delivery risks.
How long does a website redesign take?
Often as long as a new build because existing URLs, content, data, integrations and organic traffic must be audited. A visual refresh is faster only when structure and functionality remain stable.
Do user tests delay delivery?
They add planned time but can prevent expensive post-launch changes. Short prototype tests can often run alongside content and technical architecture work.
When should the final launch date be fixed?
Set a target early, then confirm it after scope and representative designs are approved. A firm date before integrations, content readiness and decision capacity are known is unreliable.