The Website Development Process: From Brief to Launch

A sequence of decisions, not a sequence of screens.

Every stage of the website development process exists to close one question so the next stage is not guesswork. Design cannot settle until the content is known. Build cannot settle until the design system is agreed. Launch cannot settle until someone has checked what a crawler actually sees.

The eight stages, in the order they have to happen:

• Discovery — who the site is for and what one action it must produce
• Sitemap and content — every page named, every page owned
• Design system — the components, before any page is drawn
• Build — the system assembled into pages
• SEO and AI-readiness — schema, structure and crawlability
• QA — mobile, speed, accessibility, forms
• Launch and indexing — redirects, sitemap, Search Console
• Maintenance — the stage most quotes leave out

Run them out of order and you pay for the same work twice.

You decide what the site is for before anyone argues about the homepage.

Discovery is short and it is not a workshop for its own sake. It ends with written answers, because every later disagreement is resolved by pointing at them:

• The one action the site exists to produce — enquiry, booking, application, sale
• Who is buying, what they already know, and what they need answered before they act
• The three competitors whose sites the buyer will also open
• The constraints: brand assets, existing systems, data that has to flow somewhere
• The measure of success, named as a number, agreed before anything is designed

A project without a named number is a project where every later decision becomes a matter of taste. Our guide to choosing a website development company covers the questions worth asking a supplier at this point.

You name every page, and you give every page an owner and a job.

This is the stage most often skipped, and skipping it is what produces a beautiful site filled with placeholder text three weeks before launch.

A usable sitemap records, for each page:

• The question that page answers, in the buyer's words
• The one action it asks for
• Where it links up to, and which pages link into it
• Who is writing it and by when
• Whether it already exists, and if so what its current URL is

Content decides layout, not the other way round. Planning the links at this stage rather than after launch is also the cheapest version of the work described in internal linking for organic growth.

Because pages designed one at a time never agree with each other.

A design system is the small set of decisions every screen inherits: type scale, spacing, colour roles, buttons, form fields, cards, states. Agree them once and a new page takes hours. Agree them never and every new page is a fresh negotiation.

What the system should settle before the first page is drawn:

• Type scale and line length at phone, tablet and desktop widths
• Spacing increments, so nothing is nudged by eye
• Colour roles and the contrast ratios they have to hold
• Every interactive component in all its states — default, hover, focus, error, disabled, loading
• What an empty state and a long-text state look like

The test of a design system is that someone who did not design it can build a new page that still looks like the site.

The design system becomes components, and the components become pages.

The decisions that matter here are mostly invisible in a demo and expensive to change afterwards:

• Whether pages are served as rendered HTML or assembled in the browser
• Where the content lives, and who can edit it without a developer
• How forms are handled, where submissions go, and what happens when one fails
• Which third-party scripts are allowed, and what each one costs in load time
• How the site is deployed, and how a bad deploy is rolled back

That first choice — rendered HTML versus browser-assembled — is the one with the longest tail, because it decides what search engines and AI crawlers can read at all.

You treat it as a build requirement, not a marketing task to add later.

Retrofitting this is the single most common cause of a new site losing visibility it previously had. Built in from the start, it costs almost nothing:

• Content present in the served HTML, not injected after load
• One H1 per page, headings that describe the content beneath them
• A direct answer near the top of every page that answers a question
• Structured data on every template — Organization, Breadcrumb, Article, FAQ, Service as relevant
• Clean, stable URLs, with redirects mapped for anything that is changing
• An XML sitemap generated by the build, not maintained by hand

Technical SEO covers the foundation in detail, and answer engine optimisation covers what changes when the reader is an AI assistant rather than a search results page.

Everything you would be embarrassed to discover from a customer.

QA is not a final glance. It is a checklist run on real devices, and it reliably finds things that looked fine in the design file:

• Every page at 390 px wide — no horizontal scroll, no overflowing buttons
• Keyboard-only navigation through every interactive element, with a visible focus state
• Contrast checked against WCAG AA, including text over images
• Every form submitted for real, including the failure path and the confirmation
• Page weight and load time measured on a throttled connection, not office wifi
• Every internal link followed; every image carrying meaningful alt text
• Analytics firing, and firing once

Most of the issues in common technical SEO problems are QA failures that shipped.

Mostly plumbing, and all of it is reversible if it was planned.

Launch is the stage where an unmanaged detail costs months of accumulated authority. The sequence:

• Every old URL 301-redirected to its closest new equivalent — one hop, no chains
• Staging blocked from indexing, and the production site confirmed not blocked
• Canonical tags pointing where you intend, and HTTPS enforced
• Sitemap submitted in Search Console and Bing Webmaster Tools
• Key pages inspected and submitted for indexing
• Analytics and conversion tracking verified against a real submission

The most expensive launch-day mistake is also the quietest: a site that went live still carrying the staging environment's instruction not to index it.

The part of the website development process that decides whether the investment holds.

A site is infrastructure, and infrastructure that nobody tends degrades. A sensible ongoing scope:

• Platform, dependency and security updates on a schedule
• Backups taken automatically and restored as a test, at least once
• Broken links, 404s and crawl errors reviewed monthly
• Speed re-measured after any new script is added
• Content reviewed against what buyers are actually searching for
• One named owner, internal or external, who is accountable for all of it

Maintenance is also where most of the long-run cost sits, which is why it belongs in the quote rather than in a surprise invoice. What website development costs in 2026 sets out how the line items usually break down.

Not in the build. In the handover between stages.

The recurring failures are structural rather than technical:

• Design started before content was written, so the content is cut to fit the design
• No named owner for content, so launch slips waiting on copy nobody was assigned
• Search and AI-readiness treated as a post-launch phase, then quietly dropped
• QA done by the people who built it, on the machine they built it on
• Redirects mapped on launch day instead of during the sitemap stage
• No agreement on who maintains the site after the final invoice

Every one of those is a sequencing problem, which is why the order of the stages matters more than the length of any one of them.

Long enough that content is written before design, and no longer.

Timelines are set by scope and by decision speed, not by the number of pages. Two things lengthen almost every project:

Content. Writing is slower than designing and is nearly always the critical path. Naming an owner and a date per page at the sitemap stage is the single most effective way to protect a launch date.

Approvals. A project with three decision-makers and no named arbiter will spend more time waiting than building. Agree who settles a tie before the first review.

AiS LABZ builds this way deliberately — digital product development runs discovery, build and AI-readiness as one engagement rather than three handovers. Founded in 2024 by Salman Usman and working across seven markets, we start with a free diagnostic.