From Brief to Launch: A Healthy Website Project Flow

Website projects rarely fail for technical reasons. They fail on decisions never made, or remade at a stage where changing them is expensive. The symptoms are recognisable: endless revisions, deadlines slipping repeatedly, and two parties both convinced they already explained.

This article lays out a healthy website project flow in seven stages: what each stage produces, who decides what, and the minimum documents that stop work from circling. The framework applies whether you use a vendor or build with your own team.

The principle underneath everything

One principle explains most of the rules below: the cost of changing something rises sharply with each stage. Changing a page structure while it is still a wireframe takes ten minutes. Changing it after the design is finished takes a day. Changing it after code is written and content loaded takes a week, and usually breaks something else.

Everything in this flow is therefore designed to move decisions as early as possible, and to make settled decisions hard to reopen without anyone noticing.

Stage 1 — Goal alignment

This stage answers a question that is surprisingly often skipped: what has to change in the business once this site exists? An answer like "look more professional" is not enough, because it cannot be checked later.

Output: one page covering the business goal, one to three metrics that will be judged, today's baselines, and the fixed constraints — budget, deadline, and what must not change.

Decider: the business owner. This is the one stage that cannot be delegated.

Stage 2 — Content and structure mapping

Before any design exists, decide which pages there will be, what each one's job is, and how visitors move between them. This stage is cheap and prevents most of the expensive rework.

Output: a full page list with each page's job, a navigation map, and a content inventory naming who prepares what. The framework for building it is in our website structure guide.

Decider: the business owner, prepared jointly with the delivery team.

Stage 3 — Wireframes

A wireframe is a simple drawing with no colour and no styling, showing each page's arrangement: what is at the top, what is below, where the buttons go. Its purpose is separating the discussion about arrangement from the discussion about taste.

Skipping this stage is expensive, because the discussions then blend: when page arrangement is debated alongside colour choices, neither gets resolved.

Output: wireframes for every distinct page type, approved in writing.

Stage 4 — Visual design

Only now are colour, typography, and visual style discussed. Because the arrangement is already approved, the conversation can focus on one thing.

A rule that saves considerable time: agree the number of revision rounds in advance, and agree that feedback is collected from everyone at once rather than trickling in. Trickling feedback is the most common reason one revision round becomes five.

Output: designs for every page type, at large and small screen sizes, approved in writing.

Stage 5 — Build

During the build, the business owner's job is not waiting but preparing two things: the content still missing, and the access that will be needed at launch — domain, hosting, analytics accounts, third-party accounts.

Access is the most frequent and most preventable cause of launch delay. Gather all of it during this stage, not on launch day.

Output: a working site at a test address, reviewable by everyone concerned.

Stage 6 — Review and testing

This stage is often treated as a formality, which is a mistake. Provide a checklist and divide the review so not everyone checks the same things.

What is checked	By whom
Accuracy of content, pricing, and claims	Business owner
Forms genuinely arriving at their destination	Sales team
Display on the phones people actually use	Several different people
Speed, broken links, 404 pages	Delivery team
Conversion tracking firing correctly	Delivery team + owner
Old URL redirects	Delivery team

The last two rows are missed most often and hurt most. A new site that does not redirect old URLs loses most of the search positions built over years; the detail is in our technical SEO guide.

Stage 7 — Launch and afterwards

Launch is not the end of the project. The two weeks after are when most real problems surface, because actual visitors use the site in ways nobody imagined during testing.

What to prepare: who monitors, what they monitor, and how problems get reported. At minimum, watch three things daily for two weeks — are forms arriving, are any pages erroring, and is visitor volume reasonable compared to before.

Output: a handover note covering how to manage content, where credentials are stored, and who to contact when something breaks.

The minimum documents that stop endless revisions

These four are enough for most projects, and all of them are short.

1. The goals sheet from stage one — one page, referenced whenever scope is disputed.
2. The page list with jobs — prevents pages appearing quietly.
3. An approval record per stage — one dated line each is enough.
4. A change log after approval — recording what changed, when, and at whose request.

The fourth is absent most often and rescues most. Without it, the question "why did the project slip" has no checkable answer and degenerates into blame.

An approval that was not recorded did not happen. Not because people are dishonest, but because memories of who approved what are genuinely unreliable after two months.

Handling change requests

Mid-project change is not inherently bad; some of it improves the result. What causes damage is change entering without its impact being assessed.

The handling is simple: every change request gets three answers before work starts — what changes, how much extra time, and how much extra cost if any. "Yes, that adds three days" is far healthier than "yes" followed by a quietly slipping deadline.

Some changes should not be accepted at all at a late stage. Reworking navigation structure once the build is underway, for instance, is usually better deferred to a post-launch improvement round than forced in.

The meetings worth having, and the ones that are not

A project with too many meetings is as damaging as one that never communicates. The first consumes time without producing decisions; the second produces decisions nobody else knows about.

For a mid-sized website project, four meetings usually suffice, each with a distinct purpose.

• Kickoff. Agreeing goals, constraints, roles, and how communication will work. One to two hours, with the outcome written down.
• Wireframe review. Discussing page arrangement before any design exists. Usually generates the most change, which is exactly the point.
• Design review. One meeting with feedback already gathered beforehand, not an open discussion.
• Pre-launch review. Walking the checklist together rather than admiring the result.

Beyond those, a written weekly update is enough: what finished, what is in progress, what is being waited on from the client. That last line matters most and goes missing most — most delays happen because nobody knew something was being waited on.

Giving feedback that can be acted on

Feedback like "it feels underwhelming" cannot be acted on by anyone. Actionable feedback names the element, the problem, and where possible the intent: "the headline at the top does not say who this service is for, and that is our customers' first question." Asking for feedback in that form is not procedural fussiness; it directly reduces the number of revision rounds.

Roles that must be clear from the start

Most project chaos comes from unclear roles rather than incompetent people. Four roles need naming with a person, not a team.

• A single decider on the client side. They may consult anyone, but only one person delivers the final decision.
• A daily owner on the delivery side. One point of contact, not three people taking turns.
• A content owner. The person responsible for having text and images ready on time.
• An access owner. The person who can supply domain, hosting, and third-party credentials.

The first matters most. A project where five people may all request changes will slip regardless of how capable the delivery team is.

Preparing content: the always-underestimated work

If one part destroys website project schedules most often, it is content. Text, photos, and product data are almost always estimated as lighter than they are, because writing intuitively feels like something that can be slotted in anywhere.

In reality, writing a clear service page requires business decisions: who this service is for, what is excluded, what the price range is. Those decisions are what consume time, not the typing.

Three approaches usually accelerate this without sacrificing quality. First, start from an interview: record a thirty-minute conversation about one service, then build the text from the recording. Talking is far easier than writing, and the result sounds more honest. Second, set deadlines per page rather than one combined deadline for "all content" — combined deadlines always slip at the end. Third, agree that unfinished content launches in an honest interim form rather than holding the whole launch.

Photography and visual assets

Photography often becomes an unexpected blocker because it requires scheduling third parties. Decide in stage two: own photography, stock imagery, or illustration. All three are legitimate, but each has very different time implications, and deciding at stage five means delaying launch.

Avoiding slow scope creep

Scope rarely expands through one large request. It expands through a dozen small ones that each feel reasonable: one more page, one more form, one small integration.

The most effective control is not refusal but visibility. Keep one open list of every additional request with its time estimate, and review that list together every two weeks. Once the total added time appears as a single number, deciding what gets done now and what waits becomes far easier — and it gets decided by the project owner rather than quietly by whoever is building.

Realistic time estimates

Missed deadlines usually come not from slow work but from unaccounted waiting time. Waiting for content, waiting for approvals, waiting for access — all three are often longer than the work itself.

To produce a more honest estimate: calculate build time, then explicitly add waiting time for each approval point. If design approval typically takes a week in the client organisation, write a week — not an optimistic two days.

A pre-launch checklist

This list is deliberately short. It contains the items that cause hard-to-reverse damage when missed — not a complete list of everything worth checking.

1. Old URL redirects are in place and tested individually for pages that had traffic.
2. Forms tested to their final destination, not only to the success message.
3. Conversion tracking works and does not double count.
4. The site is indexable — the development-phase no-index marker has been removed.
5. Credentials have transferred to the business owner, not held only by the vendor.
6. The first backup exists and restoring it has been tested once.
7. Legal pages are live — privacy policy and terms, particularly where forms exist.

The fourth is a classic mistake whose symptoms only appear weeks later: the new site looks perfect, but search traffic never arrives because the development-phase marker was never removed.

Adapting the flow for small projects

Seven stages sound heavy for a single landing page or a small fix. The flow can be compressed, but by merging stages rather than deleting them.

For a small project, stages one and two fit into one thirty-minute conversation producing half a page of notes. Stages three and four can merge into one design round, provided the arrangement is still agreed at the start of the meeting. Stage six must not be removed, only shortened to a brief checklist.

What must never disappear regardless of size: a written goal, one decider, an approval record, and a pre-launch check. Together those take under two hours, and their impact is greatest on small projects — because small projects have no spare time to absorb mistakes.

In summary

Seven stages: align goals, map content and structure, wireframe, design, build, review, launch. Decide as early as possible because change costs rise sharply. Name one decider on each side. Record approvals and changes, even as one line. And estimate waiting time, not only working time — that is where most deadlines disappear.

One last point worth stating plainly: none of this requires heavy process. Four short documents, four meetings, and one written weekly update cover a mid-sized project completely. The value is not in the paperwork but in the fact that every decision has a place to live, so nobody has to reconstruct it from memory two months later.

Want your website project run this way? Talk to our team.