How long does a custom website take? A realistic timeline from brief to launch

A website timeline is often reduced to one question: "How many weeks will development take?"

Development is only one track.

A custom website moves through business decisions, information architecture, content, UX, design, technical implementation, integrations, migration, testing, acceptance and deployment. Several activities can overlap. Others cannot begin responsibly until a predecessor is approved.

The launch date is governed by the longest connected sequence of dependencies, not the sum of developer hours.

A realistic website schedule is a model of decisions and dependencies, not a date selected before the work is understood.

For that reason, there is no responsible universal duration for "a custom website". A controlled corporate build and a multi-location platform with integrations may share the same label while carrying completely different critical paths.

The short answer

A credible timeline should show eight stages:

Qualification and brief
Resolution of material unknowns
Architecture and UX
Visual design
Development and integration
Content and migration
Quality assurance and acceptance
Deployment and stabilisation

A timeline should show sequence, overlap and acceptance gates.

The detailed delivery schedule should be confirmed after the project boundary, responsibilities, assumptions and dependencies are understood. A deadline can shape scope and phasing, but it cannot make predecessor work disappear.

What actually controls the duration?

Scope certainty

A team can plan a defined website more accurately than an unresolved platform.

If audiences, content types, functions, integrations and migration are clear, the agency can sequence work and assign the right specialists. If business rules or data flows remain assumptions, the plan must allow time to resolve them or carry explicit contingency.

Not every unknown needs Focused or Full Website Discovery. A straightforward gap may be resolved through a stronger brief and focused conversation. Focused or Full Website Discovery becomes proportionate when unanswered questions could materially change architecture, scope, cost, timing or viability.

Decision latency

The schedule includes the time between work being ready for review and a consolidated decision being received.

If five stakeholders provide separate feedback over ten days, the agency cannot treat that as one approval milestone. If a final approver enters after design, earlier decisions may reopen.

Define:

One day-to-day project owner
Required contributors by stage
Final approvers
Review windows
Consolidated feedback process
Escalation path
Cover for leave or absence

Fast decisions do not mean rushed decisions. They mean authority and evidence are available when needed.

Content readiness

Content affects sitemap, wireframes, component design, search strategy, accessibility and migration.

A schedule that places "client content" in one late task hides the dependency. The project needs to know:

Which content will be retained, rewritten, merged or removed
Who writes, fact-checks and approves it
Which representative content is needed for UX and design
Who supplies and licenses imagery
Who enters and formats content
How structured data will be cleaned and imported
Which content needs legal, privacy or technical review

Content can run in parallel with design and development when the model, owners and deadlines are agreed. It becomes a launch blocker when the team waits for final layouts before beginning the work.

Integration and vendor dependencies

An integration timeline depends on more than agency development.

The project may need vendor documentation, credentials, sandbox environments, licences, field mapping, security approval and test data. A third party may have its own queue or release window.

Map these dependencies before assigning the launch date. "CRM integration" is not schedule-ready until the systems, behaviour, access and owners are known.

Migration scale and quality

Content, product, location, customer or resource migration can be simple, automated, manual or mixed.

The source data may contain duplicates, obsolete records, inconsistent categories or embedded formatting. Cleaning can be more time-consuming than import. Search migration also needs URL inventory, redirect mapping, metadata review and post-launch monitoring.

Google’s site-move guidance recommends preparing URL mapping, testing redirects and monitoring the move. That work belongs in the plan before launch week.

Quality and risk

The level of testing should match the website’s responsibility.

A brochure site with a small number of templates differs from ecommerce, accounts, health information, payments or operational integrations. More critical journeys, devices, roles, data and failure modes create more acceptance work.

The Australian Cyber Security Centre’s Secure by Design guidance positions security across the product lifecycle. Security, privacy and accessibility requirements need to influence planning and implementation rather than being compressed into a final check.

The schedule belongs to the whole delivery system.

Stage 1: qualification and brief

The first stage establishes fit and enough context to choose the next process.

A useful brief covers:

Business outcome
Priority users and actions
Current website and problems
Known pages, content types and functionality
Systems and data
Brand and content readiness
Search and migration context
Stakeholders and governance
Desired timing and reason for the deadline
Investment parameters

This is not free strategy. It is qualification. Detailed research, architecture, wireframes or implementation planning require an agreed scope.

The timeline should not begin with a design promise while the agency is still determining whether the project is template-led, focused custom or Discovery first.

Stage 2: resolve material unknowns

Some projects need only targeted clarification. Others need a formal Focused or Full Website Discovery phase involving stakeholders, users, systems, data, governance and risk.

The output should make the implementation more decision-ready. Depending on the engagement, it may cover requirements, architecture, content model, journeys, wireframes, integration mapping, migration approach, risks, governance and roadmap.

Discovery can also change the original plan. It may support a simpler implementation, a phased programme, improvement of the existing website or further validation. A schedule that treats the original idea as fixed before Discovery begins misses its purpose.

Stage 3: architecture and UX

Architecture and UX turn business and user requirements into a usable structure.

Work may include:

Sitemap and navigation
Audience journeys
Content types and relationships
Functional behaviour
Wireframes and prototypes
Responsive priorities
Accessibility considerations
Measurement points

The most demanding journeys should be addressed early. A homepage wireframe does not prove that the system supports product search, locations, forms, account states or long-form content.

Approval means the structure is ready for visual design. It should not mean every sentence is final, but representative real content should be available.

Stage 4: visual design

Visual design translates the brand and approved experience into a responsive component system.

The schedule depends on:

Number of distinct templates and states
Brand maturity
Mobile and responsive complexity
Interaction and motion
Accessibility requirements
Review groups and revision rounds
Availability of content and imagery

Design can overlap with technical foundation work after architecture is stable. Development should not race ahead on components that are still changing materially.

Stage 5: development and integration

Development configures or builds the CMS, templates, components, functions and integrations.

A responsible schedule includes technical review, code management, development and staging environments, data handling, error behaviour and internal quality checks. Integrations need suitable test environments and representative data.

Progress is not measured only by screens appearing in staging. A page may look complete while form routing, permissions, analytics, migration or accessibility states remain unfinished.

Stage 6: content and migration

Content work should begin earlier, but it becomes visible in the platform here.

Tasks may include final writing, approval, entry, formatting, metadata, media preparation, structured imports, redirects and link updates. Run a representative migration before the full import. It can expose field, formatting and taxonomy problems while there is still time to respond.

Freeze rules should be explicit. If the old website continues to receive new content or transactions, decide how changes will be captured between final migration and launch.

Stage 7: quality assurance and acceptance

Quality assurance is a workstream, not spare time between build and launch.

It can include:

Functional testing
Responsive and browser review
Accessibility evaluation
Performance checks
Integration and data validation
Content and broken-link review
Analytics and consent checks
Security activities appropriate to risk
User acceptance testing
Defect correction and retesting

Client acceptance needs an agreed environment, test cases, owners and deadline. Feedback should distinguish defects from new requirements. Adding features during acceptance changes the critical path.

Stage 8: deployment and stabilisation

Launch is a controlled operational change.

Before production release, confirm:

Functionality and acceptance status
Approved production content
Redirects and migration readiness
Analytics, tags and consent
Domain, DNS and certificate ownership
Hosting-provider coordination
Backups and rollback arrangements
Communication and support ownership
Post-launch checks

Emote does not sell, resell or directly provide hosting infrastructure. Emote can advise on requirements, recommend and coordinate with an appropriate hosting partner or work with the client’s suitable existing provider. The client normally contracts with and pays the host directly.

Release follows evidence, acceptance and operational readiness.

After release, check priority journeys, forms, integrations, redirects, analytics and errors in production. The website then moves into warranty, maintenance, support and improvement under their separate agreed boundaries.

How to turn the stages into a credible delivery schedule

Begin with outputs and acceptance, then work backwards through dependencies.

For each stage, record:

The decision or deliverable required
Work that must finish before it can start
Work that can proceed in parallel
The agency and client contributors
The approver
Required system or provider access
Review and correction allowance
The evidence that marks completion

Next, identify the critical path: the longest connected sequence that determines the earliest credible release. A delayed item outside that path may consume effort without moving launch. A short approval on the critical path can move the entire programme.

Use one integrated schedule rather than separate agency and client plans. Content, legal review, photography, vendor access and procurement are not external notes if delivery depends on them.

Maintain a decision log and a dependency register. When scope changes, show which approved outputs, dates, resources and tests are affected. A timeline should not remain visually unchanged while the project beneath it grows.

Also distinguish three dates:

Target date: the desired business window.
Forecast date: the current evidence-based expectation.
Committed date: the date governed by the agreed contract, scope and assumptions.

Using one label for all three creates false certainty. A healthy project can discuss movement in the forecast without quietly changing the commercial commitment.

Finally, update the schedule at stage gates. Planning should become more precise as evidence improves. If material uncertainty remains after a gate, record the decision, validate it or change the pathway rather than allowing an optimistic date to conceal it.

Protect the schedule once delivery begins

A credible plan can still lose time if the project does not govern decisions and change. Protecting the schedule means maintaining the conditions on which the forecast depends.

Establish a baseline after scope, outputs, responsibilities and major dependencies have been agreed. The baseline should include client work as well as agency work: content preparation, subject-matter review, legal approval, data access, procurement and third-party coordination. If those activities remain outside the schedule, their delays will still affect launch while appearing to have no owner.

Maintain three short working records:

Decision log: the decision, owner, due date, approved answer and affected outputs.
Assumption log: what the plan currently assumes, how it will be validated and what changes if it proves false.
Dependency register: the external input, provider or predecessor task, its required date and escalation path.

These records should connect to the schedule rather than sit in a separate status document. When an approval moves, show the dependent design, content, build or testing activity. When a new requirement is accepted, identify what will be added, removed, deferred or rescheduled. A team cannot preserve every element of scope, quality, cost and timing when the underlying work changes.

Content needs its own readiness view. Track each priority page or content type through source collection, drafting, review, approval, CMS entry and final quality assurance. Reporting that content is "in progress" until the week before launch hides the distribution of work. A readiness view exposes where one unavailable approver or missing data source threatens the critical path.

Third-party dependencies also need active escalation. Confirm named contacts, response expectations, environment access and test windows early. If an integration provider cannot supply documentation or a test account by the required date, the project should decide whether to escalate, substitute, phase or move the forecast. Waiting silently is still a scheduling decision.

At each gate, reforecast from current evidence. Preserve the historical baseline so the team can understand movement, but do not defend an obsolete forecast for appearance. A transparent change to the expected date is more responsible than compressing testing, migration or accessibility work to maintain a date that no longer reflects the project.

What can run in parallel?

Parallel work can shorten elapsed time when dependencies are stable.

Examples include:

Content inventory while early UX begins
Copy development after the content model is agreed
Technical setup during approved design work
Data cleaning before migration scripts are complete
Test planning during development
Hosting coordination before launch readiness

Parallel work becomes rework when it relies on unresolved decisions. Writing all content before the proposition and structure are agreed can be fast activity and slow delivery.

How to respond to a fixed deadline

A real deadline may come from a campaign, event, contract, platform end-of-life or organisational change.

Use four levers:

Scope: define the smallest credible launch capability.
Sequence: move later-value features into governed phases.
Readiness: assign content, decisions and access immediately.
Risk: state what compression changes in validation, contingency and operational exposure.

Adding people does not automatically shorten a knowledge-dependent project. More contributors can increase coordination. The strongest acceleration often comes from earlier decisions and narrower scope.

Do not label an incomplete website an "MVP" merely to meet a date. A smaller release still needs to satisfy essential user, business, security, privacy, accessibility and operational requirements.

Separate target date from schedule confidence

A target date is an objective. Schedule confidence depends on accepted scope, available people, content readiness, system access, decision turnaround and test evidence. Report both so leadership can decide whether to reduce scope, add capacity or move the date.

Frequently asked questions

Why can an agency not confirm the launch date from the first call?

The agency may not yet know the pathway, scope, content, integrations, migration or decision process. It can discuss feasibility and constraints, then confirm a delivery schedule after the engagement boundary and dependencies are agreed.

Does custom design add time?

It adds UX, interface and review work compared with applying an established template. The value should come from meaningful differentiation or better journeys, not custom work for its own sake.

Can content be added after development?

Final entry often occurs during or after development, but content planning and representative copy should begin earlier. Late content can expose missing components, hierarchy and compliance needs.

Does Focused or Full Website Discovery make the overall project longer?

It adds a separate phase, but can reduce false starts and produce a more credible implementation plan when material unknowns exist. It may also recommend a simpler or phased solution.

What commonly delays launch?

Unresolved scope, late content, fragmented feedback, missing vendor access, data quality, new requirements during acceptance and unplanned migration work are common causes.

Should every project launch as soon as development finishes?

No. Production release should follow agreed acceptance and launch-readiness checks. Development completion is one input.

How Emote can help

A custom website takes the time required to make and implement the decisions on its critical path. The schedule becomes credible when scope, content, systems, approvals, testing and launch ownership are visible.

If you have a required launch window, book an initial meeting with Emote. We will clarify the business outcome, known requirements, deadline drivers and material unknowns, then recommend the appropriate pathway. A detailed delivery schedule follows agreed scope and onboarding.