The web development process is the order a website comes together in. Discovery, then structure, then design, then the build, then content, testing, launch and the care that follows. This guide walks through each stage in turn. It says what happens, who has to turn up, and what usually goes wrong there.
Skipping a stage does not remove the work. It moves the work later, where it is slower and more expensive to do. So the order below matters more than the labels anybody puts on it.
It also assumes you already know roughly what you are building. If that part is still open, our plain guide to web and mobile app development covers the choice between a website, an app and something you buy ready made.
What the web development process is really for
Each stage exists to answer one question and then stop reopening it. Discovery answers what the site is for. Structure answers what goes on it. Design answers what it looks like, while the build answers how it behaves.
Trouble starts when an answer reopens later. Moving a page in the structure during the build looks cheap on paper. In practice it touches the navigation, the design and the code at the same time. So a clear web development process is not about tidiness. You settle each decision once, at the point where changing your mind still costs almost nothing.
If you are replacing a site that already ranks, the order matters even more. Our guide to planning a redesign that keeps its traffic covers the extra steps that sit alongside these stages.
Stage one: discovery, before anyone draws anything
Discovery is a short set of conversations with a written outcome. Who is the site for? What do you want them to do? Which of those actions is worth money to you?
Ask for the answers in writing. A page count, a list of features, and a plain sentence about what success looks like. Vague briefs do not produce vague websites. Instead they produce arguments halfway through the build.
- Audiences, in the order they matter to the business.
- The one action you want most visitors to take.
- Features you genuinely need, kept apart from features somebody liked.
- Whatever has to connect, such as a booking tool, a payment provider or your CRM.
- Who signs off, and who does not.
That final point is worth settling in writing. Two people with equal authority and different taste will disagree at some stage. Neither one can overrule the other, so the design simply stops.
Stage two: structure, sitemap and content plan
Structure comes before design, always. You cannot lay out a page well until you know what sits on it and what sits next to it.
The output here is a sitemap and a rough plan for each page. Not the words yet, but the purpose, the sections and the next step you want a reader to take. Write the page titles at this point too, because a title tends to expose a page with no job.
This is also where you find pages nobody needs. A site with a page for every service, every sub service and every town is usually a site nobody can maintain. Cutting it now costs one meeting. Cutting it after design costs the design as well. Structure is the cheapest stage of the web development process to change your mind in, so use it.
Stage three: design, and the approval trap
Design usually starts with two or three key templates rather than every page. The home page, one inner page and one form page will settle most of the questions.
Review each round properly, then give one consolidated set of comments. Feedback arriving in drips, from different people, over a fortnight will stretch a design stage on its own.
Ask to see the design at phone width before you approve it. Check your own analytics first for the split between phone and desktop. Then judge the layout at the width your visitors actually use. Look at the navigation, the forms and any table at that width too, because those break first.
Stage four: the build
Now the developers turn the approved design into working pages. Front end work covers what a visitor sees. Back end work covers what happens when somebody submits something.
Ask for a staging link early, even while it looks unfinished. Watching the site arrive page by page beats one big reveal near the deadline. You will catch misunderstandings while they are still small.
New ideas will arrive mid build, and some of them will be good ones. Agree before the build starts how a change gets priced and what it does to the date. A change nobody costs is a deadline nobody meets.
The build is also where your platform choice starts to show. A system your own team can edit without help saves a year of small requests, which is why picking a CMS your team will actually use deserves a real conversation rather than a default. A sane web development process keeps the build honest with short check ins. Weekly is usually enough. Daily is theatre.
Stage five: content, which is where projects stall
Content is the stage that depends least on the agency and most on you. Words, photographs, staff biographies, product details, legal pages. Somebody on your side has to produce all of it.
Start it during design rather than after the build. If the words arrive last, they end up poured into a layout drawn for different words. The page then reads like a form somebody filled in.
Agree who writes what, then put dates against it. Treat those dates as seriously as the development ones. Code can carry on without you. Content cannot, so it becomes the thing everybody ends up waiting on.
Stage six: testing on real devices
Testing means more than clicking around the home page. Work through it in layers.
- Every page on a phone, a tablet and a laptop.
- Forms, including what happens when somebody submits nothing at all.
- Payment or booking flows, end to end, with a real transaction.
- Speed, since a page nobody waits for is a page nobody reads.
- Broken links, missing images and any page only the developer knew about.
Speed deserves its own pass rather than a glance. Oversized images, a pile of third party scripts and a slow host are the usual causes. Start with the images, because they are normally the cheapest of the three to change. Measure the result on staging before launch, while there is still time to act.
Test on the devices your visitors really use, not just the newest phone in the office. An older handset on a weak connection is the honest test.
Stage seven: launch day
Launch is a checklist rather than an event. Redirects from old addresses to new ones. Analytics recording. Forms delivering to an inbox somebody reads. Search engines allowed back in after staging.
The redirect list is the part people forget. Every old address that had visitors or links needs a new home. Skip it and each of those addresses lands on a missing page instead. Launch is the shortest stage in the web development process and the one with the most ways to go wrong.
Keep the old site reachable somewhere for a week or two. When a stray page turns up missing, having the original in front of you turns an hour of guessing into a minute of copying.
Stage eight: the weeks after launch
A website is not furniture. Software updates, security patches, broken forms, expiring certificates and content that goes stale all arrive whether or not anyone planned for them.
Agree what happens next before launch day, while everyone still cares. Who applies updates? Who fixes a broken form on a Sunday? What does that cover? Our piece on the maintenance nobody budgets for sets out the work that carries on long after the project ends.
Who does what in the web development process
Roles blur on small projects and separate on large ones. Even so, somebody has to hold each one.
| Role | Owns |
|---|---|
| Client lead | Decisions and sign off |
| Strategist | Goals, audiences, structure |
| Designer | Templates and the visual system |
| Developer | The working site |
| Writer | Page copy and product detail |
| Tester | Finding what broke |
On a small project one person may hold three of those. That is fine, as long as the roles stay visible. Trouble arrives when nobody holds one at all, which is usually the writer.
How long a web development process takes
Nobody can answer that from a web page, and anybody who tries is guessing at your scope. What you can work out in advance is which stage will be your long one.
Each stage has one thing that governs its length. Discovery waits on getting the decision makers into one room. Design waits on how quickly you return a single consolidated set of comments. The build depends on how much is written from scratch rather than configured.
Testing grows with the number of ways a visitor can pay you or book you. Content depends on how many pages need original words, and on who is writing them. Find the longest of those and you have found your real timetable.
A worked example, with round numbers chosen to make the arithmetic easy rather than to describe a typical project. Say a site has ten pages of copy to write, and one person writing them at one page a week. Content alone then runs for ten weeks. If design and build together take eight weeks, content sets the launch date, not code. Starting the writing four weeks earlier moves the launch four weeks earlier, and nothing else in the plan has to change.
So ask your supplier which stage they expect to be the long one, and why. An answer that names a stage and a reason is worth more than a total in weeks with nothing behind it.
What each stage of the web development process hands over
A stage is finished when it produces something you can keep, not when somebody says it feels done. Ask for each of these, then file it where you can find it again.
- Discovery: a written brief with the goals, the audiences and the sign off list.
- Structure: a sitemap, plus a one line purpose for every page on it.
- Design: approved templates, at desktop width and at phone width.
- Build: a staging link you can open yourself, whenever you like.
- Content: a page by page list of who owes what, and by when.
- Testing: what was checked, on which devices, and what is still open.
- Launch: the redirect map, the analytics setup and the logins, in your name.
That final item matters long after everybody has moved on. Hosting, domain and CMS accounts held only by a supplier become a problem the day you want a different supplier.
How the web development process changes for shops and apps
The stages stay the same. What changes is the weight of each one.
An online shop adds product data, tax and delivery rules, payment testing and stock control. Testing grows a lot, because a broken checkout is a broken business. Budget for a second round of it after the first real orders arrive.
A mobile app adds store review, device permissions and release management. A web page can be corrected as soon as you spot the problem. An app update has to go through the store before anybody receives it. So more of the testing has to happen before release rather than after it.
Custom features change the shape too. Anything written from scratch needs its own specification and its own test plan, which is part of why custom development only pays in certain situations.
A shorter web development process for a small site
A five page brochure site does not need the full ceremony. It still needs the order.
- Write down the goal and the page list in one sitting.
- Draft the words before anybody designs a layout.
- Approve one design template, then apply it everywhere.
- Build it, then check every page on a phone.
- Launch with redirects, analytics and a contact form that works.
That is the same web development process, compressed. Skipping a stage causes rework. Doing a stage quickly does not.
What to ask before you sign anything
Take these questions to whoever is quoting. The answers tell you more than the number at the bottom does.
- Which stages does this quote cover, and which ones cost extra?
- Who writes the content, and by when?
- How many design rounds come as standard?
- What happens to my old web addresses at launch?
- Who owns the code and the hosting account afterwards?
- Support after launch: what does it include, and how fast is the response?
A supplier who answers those clearly has a real web development process behind them. One who cannot is improvising, and you will pay for the improvising later.
None of this is complicated. Ultimately the web development process is a sequence of decisions, each settled once, in the order that makes the next one cheaper. Follow it and the surprises turn up early, while they are still cheap to deal with.
Frequently asked questions
What are the stages of the web development process?
Eight, in the order they have to happen: discovery, structure, design, build, content, testing, launch and maintenance. Each one exists to settle a question and then stop reopening it, which is why the order matters more than the names. Content and testing overlap with the build rather than queueing politely behind it. Launch day is a checklist to work through, not a moment to celebrate. Maintenance then carries on for as long as the site stays live. A small project compresses all of this into days instead of weeks, but it does not reorder it.
How long does it take to build a website?
Nobody can give you an honest number without seeing the scope, so treat any figure in a first email as a guess. Ask instead for a plan with a date against each stage, and for the name of the person who owns each date. Then count how many of those dates belong to you rather than to the agency. Content dates and approval dates usually sit on your side of the table. Those are the ones that slip, and they take the launch date with them.
What comes first, the design or the content?
Content planning comes first, and the finished words should arrive early. You cannot design a page properly until you know what goes on it and how much of it there is. So the usual order is a content plan during the structure stage, draft copy during design, and final copy before the build ends. Designing first and pouring words in afterwards produces pages that look right in a mockup and read badly in real life.
Who is responsible for the content on a web project?
Usually the client, unless the contract says otherwise in writing. Agencies design and build, yet they rarely know your products, your customers or your tone as well as you do. If you want the agency to write it, agree that at the quote stage and expect to spend real time briefing them. Either way, name one person on your side who owns content, then put a date against every page.
Can I skip stages in the web development process?
You can compress any stage of the web development process, and on a small site each one might take an afternoon. Skipping a stage is different, because the work reappears somewhere more expensive. Miss discovery and you hold the argument during design instead. Leave out the testing and your customers find the bugs for you. Launch without a redirect map and the rankings leave with the old addresses. The order is what matters, not the ceremony around it.
What is a staging site, and do I need one?
A staging site is a private copy of your website where the work happens before anything goes public. Yes, you need one. It lets you review real pages on real devices instead of approving a picture of a page. It also keeps unfinished work away from customers and out of search results. Ask for the staging link early in the build, so you can watch the site take shape rather than seeing everything at once near the deadline.
What happens to my rankings when a new site launches?
That depends entirely on whether anyone planned for it. Rankings attach to addresses, so every old address needs either the same path on the new site or a permanent redirect to its closest match. Keep the titles and the main content of pages that already perform. Launching without a redirect map is the quickest way to throw away traffic that took years to earn. Check the redirects on launch day, then check them again a week later.
Do I need a maintenance plan after the site goes live?
Yes, in some form, even if it amounts to a few hours a month. The size of the plan matters less than the answers inside it. Name who applies updates, and how quickly they reply when something breaks. Say what counts as included and what gets billed separately. Check that backups exist and that somebody has actually tried restoring one. Settle all of it before launch, while the project still has everyone's attention. A site nobody maintains slowly becomes a site nobody trusts.
Who owns the website once the project is finished?
Whoever the contract says, which is why that clause is worth reading before you sign anything. Ask about three things in particular: the code, the hosting and domain accounts, and any licences bought on your behalf. Accounts opened in the agency's name are the usual sticking point, since moving them later needs their cooperation. Put your own name on the domain and the hosting from the start. A supplier with a settled web development process expects that question and answers it plainly.