In short
Most custom marketing websites take 8–16 weeks from a clear brief to launch. A small site with ready content may take 6–8 weeks, while content-heavy, multilingual, ecommerce, or integrated builds often need 16–24 weeks or more.
A realistic timeline by project type
| Project type | Planning range | What usually drives the range |
|---|---|---|
| Adapted template site | 2–6 weeks | Ready content, limited customisation, few page types |
| Small custom marketing site | 6–10 weeks | One audience, 4–6 templates, simple CMS |
| Typical custom company site | 8–16 weeks | Discovery, original design, CMS, migration, technical SEO |
| Content-rich or multilingual site | 12–24 weeks | Many content types, migration, localisation, search and filtering |
| Ecommerce or integrated site | 16–28+ weeks | Product data, payments, customer states, operational integrations |
These are planning ranges, not promises. A ten-page website can take longer than a fifty-page website if those ten pages are all unique, the content is unresolved, or several systems must exchange data.
The phase-by-phase schedule
1. Discovery and definition: 1–2 weeks
The first phase turns a request such as “we need a new website” into a buildable problem. The team clarifies audiences, positioning, priority journeys, content, technical constraints, success measures, and decision ownership.
The output should be concrete: an agreed scope, sitemap, content responsibilities, feature list, integration notes, and project plan. Discovery is complete when the important unknowns have owners—not when every future detail has been predicted.
Skipping this phase can make the calendar look shorter at the beginning. It usually moves the same decisions into design and development, where each change affects more completed work.
2. Information architecture and content: 1–4 weeks
The sitemap establishes what pages and content types exist. Page outlines establish what each one must communicate. Draft copy gives the interface real material to organize.
This phase can run partly alongside discovery, but the homepage and primary templates should not reach final visual design while their content is still hypothetical. Design responds to meaning: a short, evidence-led page and a long narrative page need different structures.
Content is the most common hidden dependency in website schedules. If the client owns the copy, name one accountable writer and set review dates before design begins.
3. UX and visual design: 2–5 weeks
Design normally moves from low-fidelity structure to a visual direction and then to the complete set of page templates and states.
A typical sequence is:
- wireframe the highest-risk journeys;
- agree on hierarchy and content order;
- establish the visual system on one or two representative pages;
- extend the system across remaining templates;
- review mobile, interaction, empty, loading, error, and focus states.
Approving one layer before adding the next keeps feedback useful. If stakeholders debate copy, layout, colour, imagery, and strategy for the first time in a polished homepage, every comment becomes entangled with five different decisions.
Troiana's product design process describes this sequence in more detail.
4. Development and CMS implementation: 3–7 weeks
Development turns the approved system into reusable components, responsive templates, CMS models, animations, forms, integrations, analytics, and technical SEO foundations.
This does not always need to wait for every screen. Once the core system and representative templates are stable, development can begin while lower-risk templates are completed. That overlap shortens the calendar only when design and engineering stay in close contact; otherwise it creates rework.
The largest variables here are usually:
- the number of unique templates and component states;
- editorial flexibility and CMS relationships;
- third-party integrations;
- animation and interactive behaviour;
- browser and device support;
- performance and accessibility requirements.
5. Content entry and migration: 1–4 weeks
Approved content is entered into the CMS, existing URLs are mapped, images are prepared, metadata is applied, and old pages are redirected where necessary.
For a new five-page site, this may take days. For a mature site with years of articles, inconsistent media, duplicate pages, and changing URL patterns, migration can become a project of its own.
Do not migrate everything automatically just because it exists. Decide what to keep, improve, combine, redirect, or retire. A redesign is a rare chance to remove content debt.
6. QA, launch, and stabilisation: 1–2 weeks
Quality assurance covers more than visual comparison. The team should test:
- responsive layouts at representative widths;
- keyboard navigation, focus order, labels, and contrast;
- forms, validation, confirmation, and failure states;
- links, redirects, canonicals, metadata, sitemap, and robots rules;
- CMS editing and preview workflows;
- analytics and consent behaviour;
- performance on real devices and connections;
- browser-specific issues;
- backup and rollback procedures.
Launch itself is a controlled change, not the finish line. Reserve time after release to watch error logs, analytics, Search Console, forms, indexing, and real-user performance.
What causes website projects to run late
Content begins after design
The layout is approved using placeholder text, then real copy arrives and changes the structure. Start content alongside discovery and make the most important page drafts available before visual design is finalized.
Feedback arrives as a committee transcript
Contradictory comments force the team to design around internal disagreement. The client should consolidate feedback, identify the decision-maker, and resolve conflicts before sending one clear response.
Approval dates are treated as optional
If a review scheduled for Tuesday happens the following Monday, the project does not lose six isolated days. It may lose the production slot reserved for the next phase. Put client review time into the schedule as explicitly as design and development time.
New features enter without a trade-off
A late request is not always a problem. Pretending it has no effect is. Every added feature should answer one question: are we adding budget, moving the date, or removing something else?
Third parties are discovered late
CRM access, payment approval, domain control, legal review, translation, security review, and procurement can each hold a launch. Identify external dependencies in week one and assign an owner to each.
The launch date is announced before scope exists
A fixed date can be useful, but then scope must be flexible. A fixed date, fixed budget, fixed scope, and unresolved brief cannot all coexist. One of them will move; usually it moves late and painfully.
How to launch faster without cutting corners
Make the first release smaller
Reduce unique templates and defer low-confidence features. A focused six-template site with complete content and excellent execution is stronger than a fourteen-template site whose last third was rushed.
Separate launch-critical work from phase two
Create three lists: required for launch, valuable next, and unproven. Do not let “it would be nice” hold the same status as a functioning lead journey, accurate content, or migration redirects.
Put one decision-maker in the room
Stakeholders can contribute expertise without all becoming equal approvers. One accountable person should decide when preferences conflict.
Prepare content and access early
Draft the core pages, collect brand assets, inventory current URLs, and secure access to the domain, hosting, analytics, CMS, and integrations before production depends on them.
Review in small, scheduled increments
Weekly reviews catch wrong assumptions while they are cheap. A single grand reveal creates the appearance of efficiency while concentrating all risk at the end.
This is why Troiana runs design and development as one practice: questions cross the boundary continuously, so the people making and shipping the decision need a short path between them.
What should exist before the clock starts?
You do not need a perfect specification. You do need:
- a clear reason for the project;
- a primary audience and priority action;
- an accountable decision-maker;
- a realistic budget range;
- known launch constraints;
- an owner for copy and assets;
- access to the current site and analytics;
- a list of required integrations and languages.
If several of these are missing, begin with a paid discovery phase. That is not a delay before the project. It is the work that makes a reliable project possible.
Common questions
Can a custom website be built in four weeks?
Yes, when the scope is small, content is ready, stakeholders are available, and technical requirements are straightforward. Four weeks is not a credible default for a content-heavy custom site with discovery, original design, migration, and integrations.
Does development take longer than design?
Often, but not always. A typical custom site may spend two to five weeks in design and three to seven weeks in development. Content and approval time can exceed either phase if they are not actively managed.
How much time will the client need to contribute?
Plan for a focused kickoff, access and content preparation, and one consolidated review per week. The exact hours vary, but delayed decisions create more schedule risk than the amount of meeting time.
Should the site launch all at once?
The core public site usually should, especially when navigation and URLs change together. Optional tools, secondary resources, or lower-priority sections can follow in planned releases if the first launch still forms a complete experience.
When should SEO enter the project?
Before the sitemap and URL structure are approved. Search intent, existing performance, internal links, metadata, redirects, structured data, and indexability affect architecture and content; they cannot be safely bolted on after development.
