Managing a website project from brief to launch without the chaos

By Axyra Nova Editorial · 20 October 2026 · 4 min read · Project management

Website projects have a reputation for running late and over budget. The reasons are usually predictable: unclear goals, content that arrives late, feedback from too many people, scope that keeps growing and testing squeezed into the last day. None of these are technical problems. They are project management problems, and they can be managed.

This guide sets out a stage-by-stage approach to website project management, suitable for freelancers, small agencies and in-house teams.

Stage 1: Discovery

Before designing anything, understand the project:

Goals: what should the website achieve? More enquiries, online bookings, sales, information for existing customers?
Audience: who visits, and what do they need to do?
Current site: what works, what does not, what must be kept?
Competitors and examples: what do the client and their customers like elsewhere?
Constraints: budget, deadline, platform, integrations, accessibility requirements.

Summarise discovery in a short brief that the client confirms. Our project kickoff checklist covers the questions in detail.

Stage 2: Sitemap and content plan

Plan the structure before the design:

Sitemap: list every page and how they relate.
Content plan: for each page, note its purpose, key messages, who writes the content and when it is due.
URL plan: if replacing an existing site, map old addresses to new ones. Our guide to URL redirects explains why this matters.

Content is the most common cause of delays. Agree deadlines early and decide what happens if content is late, such as launching with fewer pages.

Stage 3: Design

Design in stages to get feedback early:

Wireframes or rough layouts for key pages, focusing on structure and content hierarchy.
A visual design for one or two key pages, such as the home page and a service page.
Remaining templates once the direction is approved.

Present designs with real or realistic content, not placeholder text. It is much easier for clients to judge whether a design works when they can see their own words in it.

Stage 4: Build

During development:

Work on a staging site, never the live site.
Build templates and reusable components first, then pages.
Add content as it arrives.
Share progress regularly so there are no surprises.

Track tasks on a shared board. Our guide to Kanban with Trello shows a simple setup.

Managing feedback

Feedback can make or break a website project. Set rules early:

One person collects and approves feedback on the client side.
A fixed number of review rounds per stage.
Feedback in one place, such as a shared document or annotation tool, not scattered across email and chat.
Specific comments: "make the button more visible on mobile" is actionable; "it doesn't feel right" needs discussion.

When feedback conflicts with the agreed goals or scope, discuss it openly rather than quietly absorbing extra work.

Managing scope changes

New ideas will appear during the project. Handle them consistently:

Note the request.
Assess its impact on time and cost.
Agree whether to include it now, add it later or decline it.
Update the plan and confirm in writing.

A "phase two" list is a useful way to capture good ideas without derailing the launch.

Stage 5: Testing

Testing deserves its own stage, not the last afternoon before launch. Check:

Every page on mobile, tablet and desktop. Our mobile-friendly checklist covers the essentials.
Every form, including the emails it sends.
Every link, including navigation and footer.
Page speed on key pages, using a tool such as PageSpeed Insights.
Accessibility basics: headings, alt text, colour contrast and keyboard navigation. MDN's accessibility guides explain the principles.
Search basics: titles, descriptions, sitemap and redirects.

Ask someone who has not worked on the project to try common tasks. Fresh eyes catch problems the team has stopped noticing.

Stage 6: Launch

Plan launch day carefully:

Choose a quiet time, not just before a weekend or a major campaign.
Take a full backup of the old site.
Prepare redirects and test them.
Switch DNS or publish, then check the live site thoroughly.
Submit the sitemap and monitor for errors.
Keep the old site available for a short period in case something was missed.

Have a simple rollback plan in case something serious goes wrong.

Stage 7: Handover

A good handover makes the client confident and reduces support requests:

Logins and access, transferred securely.
Short guides or videos on common tasks, such as editing pages and adding posts.
A list of plugins, services and renewals.
Backup and maintenance arrangements.
Who to contact for help.

A worked example

A freelancer rebuilt a dental practice's website over six weeks. In discovery, the practice said online booking and clear treatment prices were the priorities. The freelancer mapped every old URL, agreed a content deadline for week two, and named the practice manager as the single approver.

Content for two treatment pages arrived late, so the freelancer launched with the main pages and added the others a week later. During testing, a colleague found that the booking confirmation emails were going to spam; fixing the email setup before launch avoided a flood of confused patients. After launch, the freelancer delivered a short video showing staff how to update opening hours and add news posts.

Common mistakes

Starting design before goals and content are clear.
No single approver on the client side.
Unlimited feedback rounds.
Testing only on the developer's own computer.
Launching without redirects.
No handover, leaving the client dependent for every small change.

Learning more

Free courses on our learning platform, such as Atlassian's project management guide, cover planning and tracking in more depth.

Frequently asked questions

How long does a small business website take?

It depends on size, content readiness and feedback speed. Clear goals and content deadlines make the biggest difference.

Who should write the content?

Whoever knows the business best, with editing help if needed. Agree responsibilities and deadlines at the start.

How many design revisions should I include?

Two rounds per stage is common. Define what counts as a round.

What if the client wants changes after launch?

Small fixes may be included in a short support period. Larger changes can be scoped as a new piece of work.