Web Development Life Cycle: The 7 Stages, Their Deliverables and Who Does What
28/04/2023
3.12k
The web development life cycle (WDLC) is the sequence of stages a website or web application goes through from idea to ongoing operation. It has seven stages: planning, analysis, design, development, testing, deployment and maintenance. Each stage has a clear goal, a set of deliverables and an exit point, so the team knows when to move on. Following the cycle keeps scope, budget and quality under control. This guide explains what happens in each stage, who is involved, how the cycle works in Agile projects, and what it looked like on a real web application project.
What is the web development life cycle?
Web development is the work of building a website or web application: designing it, coding it, testing it and deploying it to a production environment, then keeping it running and useful. The web development life cycle is the framework that organizes that work into defined stages, from planning to maintenance, so it can be done systematically rather than ad hoc.
The cycle matters most when several people or companies are involved. A business owner, a designer, front end and back end engineers, QA and operations all need to know what has been decided, what is being built now and what comes next. A shared life cycle gives everyone the same map. It also helps clients who hire a web development company understand how their project will progress and where their input is needed.
Web development life cycle vs. software development life cycle (SDLC)
The WDLC is a version of the software development life cycle adapted to the web. The stages are similar, but web projects add concerns that general software projects do not always face.
| Aspect | Software development life cycle (SDLC) | Web development life cycle (WDLC) |
|---|---|---|
| Scope | Any software: desktop, mobile, embedded, enterprise systems | Websites and web applications delivered through a browser |
| Typical stages | Planning, requirements, design, build, test, deploy, maintain | Same core stages, with stronger focus on content, UX and information architecture |
| Extra concerns | Platform specific packaging and distribution | Browser and device compatibility, SEO, accessibility, page speed, public facing security |
| Release style | Often versioned releases | Frequent, continuous releases to a live site |
| Who uses the output | Often known users inside an organization | Often anonymous public users as well as logged in users |
Why the web development life cycle matters: the data
Skipping or rushing stages creates problems that real users notice and that cost money to fix later. Three findings show why each stage deserves time.
- Most sites still fail basic accessibility checks. In its 2026 analysis of the top one million home pages, WebAIM detected WCAG 2 failures on 95.9% of them, with an average of 56.1 detected errors per page. The most common issue was low contrast text, found on 83.9% of home pages (WebAIM Million, 2026). These are design and development stage issues that testing alone cannot fix cheaply.
- Small speed gains move revenue. A study by Deloitte, commissioned by Google, found that a 0.1 second improvement in mobile site speed increased retail conversions by 8.4% and travel conversions by 10.1% (Deloitte, Milliseconds Make Millions, 2020). Performance has to be designed and budgeted, not patched in at the end.
- Poor quality is expensive. The Consortium for Information and Software Quality estimated the cost of poor software quality in the United States at no less than $2.41 trillion in 2022 (CISQ, 2022). Structured analysis, testing and maintenance stages are how teams keep their share of that cost low.
A well structured cycle helps organizations build websites that meet user needs while reducing costs and improving collaboration and transparency between the business and the development team.
The 7 stages of the web development life cycle
Each stage below lists its goal, the main activities, the deliverables that mark it as done and the people usually involved. In a strict Waterfall project the stages run once in order. In an Agile project, design, development and testing repeat in every sprint, but the same work still happens.
1. Planning
Planning sets the direction for everything that follows. The team defines the purpose of the website or web application, the business objectives, the target audience and the resources available. Understanding the audience means looking at who they are, what they want to achieve and how they behave online. That information becomes user personas that guide design and development.
Planning also covers several decisions that are expensive to change later: the technology stack, the development methodology, the high level sitemap, the budget, the team and the timeline. If the site needs to rank in search, keyword research and content strategy start here too.
- Deliverables: project goals and success metrics, user personas, high level sitemap, technology choice, budget and timeline, team and roles.
- Who is involved: business owner or product owner, project manager, business analyst, technical lead.
- Exit point: the sponsor approves goals, scope, budget and timeline.
For a step by step method to build this plan, see how to plan a software project.
2. Analysis
Once the goals are clear, the team analyzes requirements in detail. Functional requirements describe what the site must do: user accounts, search, checkout, dashboards, content management. Non functional requirements describe how well it must do it: speed, availability, security, accessibility level and supported browsers and devices.
This stage also checks technical feasibility and risk. Which systems must the site integrate with? Is the data available and reliable? Are there legal or compliance constraints such as privacy rules? Careful analysis here saves time and money later, because each misunderstanding found in analysis costs a conversation, while the same misunderstanding found after launch costs a rebuild.
- Deliverables: requirements specification or product backlog with user stories, non functional requirements, integration list, risk list, acceptance criteria.
- Who is involved: business analyst, product owner, technical lead, QA lead.
- Exit point: requirements and acceptance criteria are agreed for the first release.
3. Design
Design turns requirements into a structure and a look. It starts with information architecture: how content and features are organized and how users move between them. Wireframes then show the layout of each key page, and prototypes let users and stakeholders click through the experience before code is written. Finally, the visual design adds the brand: menus, buttons, dashboards, graphics, color schemes and typography.
Good design serves both the audience and the brand. An uninteresting or confusing design pushes visitors away and raises the bounce rate. This is also the stage to build in accessibility (sufficient color contrast, text alternatives for images, labeled form fields) and a performance budget (target page weight and load time), because both are far cheaper to design in than to retrofit.
- Deliverables: information architecture, wireframes, clickable prototype, UI design and style guide or component library, accessibility and performance targets.
- Who is involved: UX and UI designers, business analyst, product owner, front end lead.
- Exit point: the client approves the prototype and key screen designs.
4. Development
Development is where the website or web application is built, using programming languages, frameworks and tools chosen in planning. Front end development builds what users see and interact with in the browser. Back end development builds the server logic, databases, APIs and integrations that power it. For content driven sites, the content management system is set up and connected in this stage as well.
This is usually the longest stage. Teams that run it well work in small increments, review each other’s code, write unit tests as they go and integrate changes often, ideally through an automated build and deployment pipeline. Content creation runs in parallel: copy, images and other media should be ready when the pages that need them are built.
- Deliverables: working front end and back end code, integrations, unit tests, configured CMS, technical documentation.
- Who is involved: front end and back end engineers, technical lead, DevOps or infrastructure engineer, content owner.
- Exit point: features meet the definition of done and are ready for full testing.
5. Testing
Every website should be tested many times before launch to protect performance and user experience. Testing checks functionality (does each feature work as specified), usability (can real users complete their tasks), compatibility (does it work across the agreed browsers and devices), performance (does it stay fast under expected load), security (are common vulnerabilities closed) and accessibility (does it meet the agreed standard).
Skipping or shortening testing leads to errors that hurt quality, reputation and revenue. In Agile projects testing is not a single phase: QC engineers test each feature in the sprint in which it is built, and regression testing runs before each release. User acceptance testing (UAT) gives the client the final say that the release meets the acceptance criteria agreed in analysis.
- Deliverables: test plan, test cases, test reports, defect log, UAT sign off.
- Who is involved: QC engineers, developers, product owner, selected end users.
- Exit point: no open critical defects and the client signs off UAT.
6. Deployment
In deployment the website or web application goes live on production servers and becomes available to users. Depending on the size and complexity of the project, this can involve configuring the hosting environment, setting up domains and HTTPS, migrating data, compressing and caching assets, setting up load balancing and turning on monitoring.
Modern teams make deployment repeatable through automated pipelines, so releasing becomes routine rather than risky. Every deployment should have a release checklist, a named approver and a rollback plan in case something goes wrong.
- Deliverables: production environment, deployment pipeline, release checklist, rollback plan, monitoring and alerts.
- Who is involved: DevOps or infrastructure engineer, technical lead, project manager, client operations team.
- Exit point: the site is live, monitored and stable.
7. Maintenance
Launch is not the end. Feedback from real users shows what to improve, and the site must keep up with security patches, browser updates, content changes and new business needs. Regular maintenance and updates keep the site running smoothly and help it attract and keep users.
Maintenance includes monitoring uptime and performance, fixing bugs, applying security updates, backing up data, reviewing analytics and planning enhancements. Each enhancement then runs through a smaller version of the same cycle, which is why it is called a cycle and not a line.
- Deliverables: support model and SLAs, monitoring reports, update and patch schedule, improvement backlog.
- Who is involved: support and maintenance team, product owner, DevOps, analytics owner.
- Exit point: none; maintenance continues for the life of the site, or until it is handed over to an in house team or retired.
The web development life cycle at a glance
| Stage | Main goal | Key deliverables | Lead roles | Common mistake |
|---|---|---|---|---|
| 1. Planning | Set direction, budget and team | Goals, personas, sitemap, tech stack, timeline | Product owner, PM | Starting design before goals are agreed |
| 2. Analysis | Define exactly what to build | Requirements, backlog, acceptance criteria | Business analyst | Ignoring non functional requirements |
| 3. Design | Shape structure and experience | Wireframes, prototype, UI design | UX and UI designers | Leaving accessibility and speed for later |
| 4. Development | Build the working product | Front end, back end, integrations, unit tests | Engineers, tech lead | Adding features outside scope |
| 5. Testing | Prove it works for real users | Test cases, reports, UAT sign off | QC engineers | Compressing testing to meet a deadline |
| 6. Deployment | Go live safely | Production setup, release checklist, rollback plan | DevOps | Manual, one off releases with no rollback |
| 7. Maintenance | Keep it secure, fast and useful | SLAs, patches, improvement backlog | Support team, product owner | No budget or owner after launch |
Waterfall vs. Agile: two ways to run the web development life cycle
The seven stages are the same in both approaches. What changes is how often they repeat and when users see working software.
| Factor | Waterfall WDLC | Agile WDLC |
|---|---|---|
| Stage order | Each stage runs once, in sequence | Planning and analysis up front, then design, development and testing repeat each sprint |
| First working version | Near the end of the project | After the first sprints |
| Handling changes | Formal change requests | Backlog reprioritized each sprint |
| Testing | A dedicated phase after development | Inside every sprint, plus regression before release |
| Best for | Small sites with fixed, well known requirements | Web applications and products that will evolve with user feedback |
| Main risk | Discovering late that the site does not meet user needs | Scope drift if product ownership is weak |
How SupremeTech runs the cycle in practice
At SupremeTech, web projects follow the five phase life cycle described on our software product development process page, which maps directly to the seven WDLC stages.
- Initiation covers planning: clarifying the product concept and business purpose, a rough estimate, choosing the technical stack and forming the team.
- Design Sprint covers analysis and design: researching user needs, journeys and use cases, then creating wireframes, prototypes and UI designs.
- Agile Development covers development and testing in time boxed sprints of one to three weeks. Each sprint delivers working features, test cases and test reports, an updated backlog and a sprint report.
- Release covers deployment in stages: POC, MVP, beta and official launch, with market feedback fed back into development.
- Maintenance and Kaizen covers maintenance and continuous improvement, or a handover to the client’s in house team.
Business analysts who speak Japanese join requirement meetings with clients directly and act as a proxy product owner next to the developers, which keeps analysis and design close to what the client actually means. A PMO of experienced delivery managers runs a weekly health check on all active projects. SupremeTech is ISO/IEC 27001 certified, so security controls apply across every stage, not only in testing.
A real example: building an advertising data dashboard
The life cycle is easiest to see in a real project. SupremeTech built a web application and dashboard for Search Inc., a Japanese company in digital out of home (OOH) advertising analytics that gives agencies and advertisers data about their audiences. The details below come from the OOH advertising data dashboard case study.
| WDLC stage | What it looked like on this project |
|---|---|
| Planning | Goal: let users log in and see personal dashboards with real time impressions for their digital billboards and ads, plus reports for specific ads and billboards. Team: a project manager, a business analyst, a front end engineer, a back end engineer and quality control. |
| Analysis | The first challenge was understanding the definition of each data point and how it was calculated, before deciding how to show it. |
| Design | The second challenge was presenting complex audience and impression data in a form that is easy to digest for billboard owners and advertisers. |
| Development | Web application built with React on AWS infrastructure, within three months of development. |
| Testing and deployment | The final step was synchronizing the dashboard with data supplied by another vendor and with existing digital billboards around Tokyo. |
| Maintenance | SupremeTech’s scope covered design, implementation, testing, migration, and maintenance and operation. |
The lesson for any data heavy web application: analysis is not a formality. Spending time to understand how each number is defined is what made the design stage possible, and it reduced the risk at the integration step at the end. [SupremeTech detail: one concrete decision or result from the Search Inc. project, for example how the data definitions were documented, if it can be shared.]
Does the life cycle differ for a website and a web application?
The stages are the same, but the weight of each stage shifts. A marketing website puts more effort into content, SEO and visual design, and its development stage is often shorter because a CMS does much of the work. A web application, such as a dashboard, booking system or customer portal, puts more effort into analysis, back end development, integrations, security and testing, because users log in and act on data. If you are unsure which one you need, read website vs. web application: what’s the difference.
| Stage | Website emphasis | Web application emphasis |
|---|---|---|
| Planning | Audience, brand, SEO goals | User roles, workflows, integrations |
| Analysis | Content inventory and sitemap | Detailed functional and data requirements |
| Design | Visual identity and page layouts | Interaction design, dashboards, forms |
| Development | CMS setup, templates, content entry | Business logic, APIs, databases, authentication |
| Testing | Cross browser, speed, SEO checks | Functional, security, load and data accuracy tests |
| Maintenance | Content updates and plugin patches | Feature releases, monitoring, scaling |
Common tools and technologies at each stage
Competitor guides often list technologies without saying where they fit. The table below places common tools in the stage where they are used. It is not a recommendation for any single stack; the right choice depends on your requirements, your team’s skills and who will maintain the site.
| Stage | Typical tools and technologies | What they help with |
|---|---|---|
| Planning | Roadmap and backlog tools (for example Jira), shared documents, analytics and keyword research tools | Goals, scope, timeline, audience and search demand |
| Analysis | User story mapping, diagramming tools, API documentation | Requirements, data flows, integrations |
| Design | Design and prototyping tools (for example Figma), design systems and component libraries | Wireframes, prototypes, consistent UI |
| Development: front end | HTML, CSS, JavaScript or TypeScript, frameworks such as React, Vue or Angular | Interfaces users see and interact with |
| Development: back end | Languages and frameworks such as Node.js (NestJS), PHP, Python, Java or .NET; databases such as MySQL, PostgreSQL or MongoDB; REST or GraphQL APIs | Business logic, data storage, integrations |
| Testing | Unit test frameworks, end to end and browser testing tools, load testing tools, accessibility checkers, security scanners | Proving function, speed, accessibility and security |
| Deployment | Cloud platforms (for example AWS or Google Cloud), CI/CD pipelines, containers, CDN | Repeatable, safe releases and fast delivery |
| Maintenance | Uptime and error monitoring, log management, backups, web analytics | Stability, security and continuous improvement |
Roles and responsibilities across the life cycle
Clear ownership is what keeps the cycle moving. The table shows who leads (L) and who contributes (C) in each stage for a typical web application project. On smaller projects one person may hold several roles.
| Role | Planning | Analysis | Design | Development | Testing | Deployment | Maintenance |
|---|---|---|---|---|---|---|---|
| Client product owner | L | C | C | C | C (UAT) | C | L |
| Project manager | L | C | C | C | C | L | C |
| Business analyst | C | L | C | C | C | C | |
| UX and UI designer | C | L | C | C | C | ||
| Technical lead and engineers | C | C | C | L | C | C | C |
| QC engineers | C | C | L | C | C | ||
| DevOps or infrastructure | C | C | C | L | L |
Sample timeline for a three month web application project
To make the stages concrete, here is an illustrative timeline for a mid sized web application, such as a dashboard or customer portal, built in two week sprints. It is a planning template, not a quote; real timelines depend on scope, integrations and how quickly decisions are made.
| Weeks | Stages | Main activities | Client input needed |
|---|---|---|---|
| 1 to 2 | Planning and analysis | Kickoff, goals, user roles, requirements workshops, data and integration review, backlog for release 1 | Decision makers available, access to existing systems and data definitions |
| 3 to 4 | Design | Information architecture, wireframes, clickable prototype, UI design for key screens; environments and pipeline set up in parallel | Prototype feedback and design approval |
| 5 to 10 | Development and testing in sprints | Three sprints of build and test; sprint reviews every two weeks; content and integrations completed | Sprint review attendance, test data, content |
| 11 | Stabilization and UAT | Regression, performance, security and accessibility checks; user acceptance testing | UAT testers and sign off |
| 12 | Deployment | Production setup, data migration, release checklist, go live, monitoring | Release approval, operations contacts |
| 13 onward | Maintenance | Monitoring, bug fixes, improvements from user feedback | Priorities for the improvement backlog |
Common challenges in the web development life cycle and how to avoid them
Poor communication
Good communication raises the efficiency of every stage; poor communication can derail the whole cycle. Each stage needs a smooth flow of information between business and technical teams, and small frictions add up to lost time, extra cost and missed goals. Fix it with a named product owner, a fixed meeting rhythm, written decisions and a business analyst who translates business needs into technical requirements.
Scope creep
Scope creep can happen in any stage. Common causes are an incomplete scope definition and weak communication. For example, a developer adds an attractive image gallery to the menu that was never requested. The feature may be good, but it takes extra days and pushes the schedule. Fix it by writing out of scope items down in planning, agreeing acceptance criteria in analysis and routing every new idea through the backlog.
Lack of testing
Without proper testing, a site can ship with bugs that cause a poor user experience, lost revenue and damage to reputation. Testing also finds performance bottlenecks and usability issues early, when they are cheap to fix. Fix it by testing inside every sprint, automating regression tests and protecting the testing time in the schedule.
Accessibility and performance left too late
When accessibility and speed are treated as testing problems, fixing them means redesigning components after they are built. Set targets in planning, design to them and check them in every sprint.
Security treated as a final check
Public web applications are exposed to the internet from the first day they go live, so security cannot wait for a penetration test the week before launch. Build it into each stage instead: list security and privacy requirements in analysis, design roles and permissions carefully, follow secure coding practices and review dependencies in development, run security tests in every release cycle, and apply patches promptly in maintenance. Limit who can access production systems and client data, and remove access when people leave the project. A partner with a certified information security management system, such as ISO/IEC 27001, already works this way across projects, which makes it easier to apply the same discipline to yours.
No plan for life after launch
Many projects budget for the build and nothing after it. Without a support model, security patches are missed and small bugs pile up. Agree on maintenance scope, SLAs and ownership before launch.
Questions to ask your web development partner at each stage
If you hire a web development company, these questions help you check that each stage is being done properly.
- Planning: How will we measure success? What is out of scope for the first release? Who are the named people on both sides?
- Analysis: Can I see the acceptance criteria for each feature? Which non functional requirements have you assumed?
- Design: Can we test a clickable prototype with real users? What accessibility level and page speed targets are you designing to?
- Development: How often will I see working software? How is code reviewed? Is deployment automated?
- Testing: Which browsers and devices are covered? How are security and performance tested? What is in the test report?
- Deployment: What is the rollback plan? Who approves a release? What monitoring is in place on day one?
- Maintenance: What are the response and resolution times? How are security updates handled? Can my in house team take over later?
Web development life cycle checklist
- Goals, audience, budget and timeline are approved before design starts.
- Functional and non functional requirements, including accessibility and speed targets, are written down.
- Acceptance criteria exist for every feature in the first release.
- A clickable prototype has been reviewed by the client and, ideally, by real users.
- Code is reviewed, unit tested and integrated through an automated pipeline.
- Testing covers function, usability, compatibility, performance, security and accessibility.
- The release checklist and rollback plan are ready before launch day.
- Monitoring and alerts are live from the first minute in production.
- Maintenance scope, SLAs and long term ownership are agreed.
Master the web development life cycle with SupremeTech
The web development life cycle is the framework behind every reliable website and web application. Building one well takes a clear plan, careful analysis, user centered design, disciplined development and testing, safe deployment and steady maintenance. That is a lot to run alongside your core business.
Whether you are a startup with a new idea or an established company growing its online presence, a development partner that follows every stage can save you time and rework. Explore how we run projects on our software product development process page, see a real example in the OOH advertising dashboard case study, or contact SupremeTech to discuss your web project.
Frequently Asked Questions
The seven stages are planning, analysis, design, development, testing, deployment and maintenance. Some models split out content creation or merge analysis into planning, but the work covered is the same.
Planning and analysis have the largest influence, because mistakes made there are carried into every later stage and cost more to fix the later they are found. Testing and maintenance protect the investment once the site is built.
It depends on scope. A simple marketing website can move from planning to launch in weeks, while a custom web application often takes several months. For example, the OOH advertising dashboard described above took three months of development. Maintenance then continues for the life of the site.
The WDLC is the SDLC applied to websites and web applications. It follows the same core stages but puts more weight on content, UX, browser compatibility, SEO, accessibility, page speed and public facing security.
It can be either. In Waterfall, each stage runs once in sequence. In Agile, planning and analysis come first, then design, development and testing repeat in short sprints, with releases staged as MVP, beta and launch.
A typical team includes a product owner on the client side, a project manager, a business analyst, UX and UI designers, front end and back end engineers, QC engineers and a DevOps or infrastructure engineer. Smaller projects combine some roles.
The maintenance stage begins: monitoring uptime and speed, fixing bugs, applying security patches, backing up data, reviewing analytics and planning improvements. Each improvement runs through a smaller version of the same cycle.
A shared life cycle gives you and your vendor the same map: what is decided, what is being built and what you need to approve. It makes progress visible, keeps scope under control and tells you exactly when your input is needed.
