A website project moves through scope, design, implementation, content, testing and release, followed by ongoing care. The phases can overlap, but their responsibilities should be clear. This guide explains what each one should produce and which decisions keep the work moving.
Phase 1: Discovery and strategy
Define the audiences, languages, services and actions the site must support. For an existing site, inspect useful content, important URLs and available search or enquiry data before planning replacements. The output is a written scope with responsibilities, assumptions and acceptance criteria. Our preparation guide lists the information that helps.
Phase 2: Design
Agree the information order, page types and visual direction using real content where possible. Review representative desktop and mobile layouts and how important interactions behave. The approach may use sketches, prototypes or a working preview. Feedback rounds and approval responsibilities belong in the project agreement rather than a universal promise that every project follows the same sequence.
Phase 3: Development
Build the pages and the systems behind them. A form needs validation, accepted data and a reliable next step; a booking needs availability and a confirmed record. Connections to payments, calendars or business software are part of the same flow. The web-development page describes the possible scope, while the portfolio shows delivered projects.
Phase 4: Content integration
Use approved text, photographs and product information. Adapt each language naturally and verify names, prices, claims and links. Images need suitable dimensions and alternatives according to their purpose. Preserve useful old addresses or map them to the right replacement. Content readiness is a project dependency, so make missing inputs visible before they delay a release.
Phase 5: Testing
Test representative browsers, screen sizes and the actual actions people will take. Keyboard access, errors, mobile navigation and loading performance need their own checks. A successful form response does not prove that its email arrived. A passing build does not prove the deployed site works. Record what was tested, what failed and any remaining limitation; agree how unresolved issues affect release.
Phase 6: Launch
Prepare the production configuration, backup and rollback, then release the approved version. Check the public domain, HTTPS, old links, crawl controls and critical actions afterward. Search Console and analytics need account-side verification too. Record the deployed version and the evidence; do not mark a planned check complete simply because the site opens.
After launch
Assign responsibility for updates, backups, content changes and incident response. Use real enquiries and search data to choose improvements rather than changing the site on a calendar alone. Our care plans describe continuing work. A price or feature change should reach the relevant pages and connected systems together.
Where projects go wrong
Unclear scope, missing content, late access and conflicting approvals can all hold up a project. Keep a short decision record and an owner for each open item. Changes may be useful, but they should update the agreed scope and timing. The pricing guide explains what to compare in an offer; a project conversation can turn the initial idea into a concrete next step.
