Guide · Planning a website
Stages of a website project, from brief to launch and beyond
Website projects run late and over budget for predictable reasons: unclear goals, content that arrives at the last moment, design approved before structure, and testing squeezed into the final day. Knowing the stages — and what is expected from you at each one — makes the process smoother and the result better. This is how a typical website project is organised; details vary with size and type.
[ 01 ]
In short
In short
- 01
Discovery and structure come before design; changing structure after design is expensive.
- 02
Content is a project stage of its own, not something added at the end.
- 03
Each stage ends with a clear approval, so later stages do not reopen earlier decisions.
- 04
Testing covers devices, browsers, forms, speed, SEO settings and every language version.
- 05
Launch is followed by monitoring and a period of fixes and improvements.
[ 02 ]
Guide
1. Discovery
Goals, audiences, competitors, current analytics, required functions and integrations, languages, constraints. The output is a short document that everyone agrees on: what the site must achieve and what is in scope. Your role: share context, data and decisions; involve the people who know customers. See website brief template.
2. Structure and page plan
A site map, the list of page templates and, for each key page, the blocks it contains and the question it answers. For existing sites, the mapping of old URLs to new ones. Your role: approve the structure and priorities. See website structure planning.
3. Content
Texts, photos, videos, product data, translations. Content is written or collected against the page plan — not to fill a finished design. Your role: provide information, review texts, approve them; this is the stage most often delayed. See who writes website content.
4. Prototypes and design
Wireframes and a clickable prototype of key pages, then visual design for mobile and desktop with real content. Your role: feedback from one consolidated voice, approval of the prototype before visual design, approval of design before development. See UI/UX design.
5. Development
Templates, content management, forms, integrations, multilingual setup, SEO settings, analytics. Work happens on a staging site that you can see as it progresses. Your role: provide access to third-party services (payment provider, CRM, domain, analytics), answer questions, review progress.
6. Content entry
Pages and products are entered into the content management system — by the developer, by your team after training, or both.
7. Testing
Functional testing (forms, payments, integrations), devices and browsers, speed, accessibility basics, SEO settings (titles, descriptions, redirects, sitemap, robots.txt), analytics events, every language version. Your role: acceptance testing with real scenarios. See staging and testing before release.
8. Launch
DNS switch, redirects, HTTPS, submission of the sitemap to Search Console, verification of analytics, monitoring of errors. See website launch checklist.
9. After launch
A period of monitoring and fixes, training for editors, and then regular support: updates, backups, improvements based on analytics. See website maintenance.
What slows projects down
- Decisions reopened after approval.
- Feedback from many people without one decision-maker.
- Content delivered late or incomplete.
- Access to third-party services arriving late (payment provider onboarding is a common example).
- Scope added during development without adjusting time and budget.
Planning the timeline
Timelines depend on scope and on how quickly each approval and piece of content arrives. When estimating, ask the developer which stages depend on you, and plan your team's time for them. A realistic schedule includes buffers for reviews and third-party onboarding.
[ 03 ]
FAQ
Frequently asked questions
Can stages run in parallel?
Some can — content writing can run alongside design once structure is approved, and integrations can start while templates are built. Structure, however, should be settled before design and content.
How many design revisions are normal?
That is agreed in the proposal. Most revisions become unnecessary when the structure and prototype are approved before visual design.
Who should approve each stage on our side?
One person with the authority to decide, who gathers input from others. Parallel feedback from several people is the most common cause of delays.