Start with the problem
Good software
is a living loop.
The software development lifecycle is the work that carries an idea into a dependable product—and keeps that product useful after launch. Explore every stage, the people involved, and the decisions that connect them.
SDLC means Software Development Life Cycle: a repeatable way to decide, design, build, verify, release, and improve software.
Eight stages. One connected practice.
Use the map to explore the flow. Each stage has a purpose, a set of activities, tangible outputs, and a decision that helps the next stage start with enough clarity.
The lifecycle map
Select a stage or play the guided walkthrough. The progress marks your position in this guide; real teams revisit stages as they learn.
The work behind every handoff.
Open a stage for the people, practices, artifacts, and questions that make it useful. Teams may rename or combine stages; the intent matters more than the labels.
01UnderstandDiscover the problem
Goal: establish whose problem is worth solving and what improvement would look like. Discovery reduces the risk of building a polished solution to the wrong need.
- Interview users and observe the existing workflow.
- Map pain points, constraints, alternatives, and affected systems.
- Test assumptions with prototypes, data, or a small experiment.
- Define outcomes and baseline measures before choosing features.
Outputs: problem statement, user journeys, opportunity hypotheses, risks, success measures, and an initial product brief.
02DecideDefine the outcome
Goal: turn the problem into a shared, testable direction while keeping the solution open enough to learn.
- Describe user needs, functional behavior, and acceptance examples.
- Set non-functional requirements: availability, privacy, latency, accessibility, and scale.
- Prioritize a thin first release and make exclusions explicit.
- Estimate uncertainty, dependencies, cost, and delivery risk.
Outputs: outcome brief, prioritized backlog, acceptance criteria, constraints, release boundaries, and a plan for unresolved questions.
03ShapeDesign the experience and system
Goal: choose an experience and technical approach that meet user needs and fit operational constraints.
- Prototype key journeys, content, empty states, errors, and edge cases.
- Design service boundaries, data models, APIs, and integration contracts.
- Review security, privacy, accessibility, reliability, and migration implications.
- Record important decisions and alternatives so future changes have context.
Outputs: tested flows, interface specification, architecture decisions, data/API contracts, threat considerations, and an implementation plan.
04CreateBuild in small slices
Goal: turn validated design into maintainable, reviewable software in small increments.
- Set up version control, reproducible environments, CI, and coding conventions.
- Implement vertical slices across UI, services, data, and integrations.
- Review changes for behavior, readability, security, and operability.
- Add focused unit and integration checks alongside implementation.
Outputs: reviewed code, automated checks, updated technical documentation, and a deployable artifact tied to a known source revision.
05ProveVerify quality and readiness
Goal: gather enough evidence that the software behaves correctly, safely, and predictably for the intended release.
- Run unit, contract, integration, end-to-end, and regression checks at the right layer.
- Test accessibility, performance, security, failure handling, and supported environments.
- Validate important workflows with users or product owners against acceptance criteria.
- Triage defects by user impact and release risk; document known limitations.
Outputs: test results, defect decisions, security findings, release risks, and a clear go/no-go recommendation.
06DeliverRelease with control
Goal: move a known build into the intended environment with a safe path forward and a safe path back.
- Package and identify the exact artifact, configuration, and source revision.
- Use staged rollout, canaries, feature flags, or limited cohorts where appropriate.
- Manage schema/data migrations and backward compatibility deliberately.
- Prepare release notes, support guidance, monitoring, and rollback or roll-forward steps.
Outputs: deployed version, release record, migration result, change communication, and verified recovery plan.
07RunOperate and support
Goal: keep the live product healthy and make its real behavior observable to the people responsible for it.
- Track service-level indicators such as availability, latency, and error rate.
- Use logs, metrics, and traces to diagnose behavior without exposing sensitive data.
- Handle incidents with clear ownership, communication, mitigation, and learning.
- Support users, manage access, patch dependencies, and maintain backups/recovery.
Outputs: service health, support insights, incident records, operational runbooks, and evidence about real-world usage.
08LearnEvolve or retire
Goal: use product and service evidence to improve the next iteration—or retire the product responsibly when it no longer creates enough value.
- Compare outcomes with the original measures and user feedback.
- Prioritize fixes, usability improvements, new capabilities, and technical debt.
- Refresh dependencies, data policies, security controls, and architecture as context changes.
- When retiring, migrate users/data, communicate timelines, revoke access, and decommission infrastructure.
Outputs: a new set of priorities, revised assumptions, improvement work, or a retirement and migration plan.
Release is a checkpoint. Learning is the engine.
A release puts a hypothesis into the world. Real users, production behavior, support requests, and business outcomes reveal what the team could not learn in a planning room.
That evidence can change the backlog, the design, the architecture, or the product goal itself. Continuous delivery makes smaller changes easier to learn from; it does not remove the need for judgment, testing, or accountable approvals.
See what stays active across the loopSome responsibilities never wait for a phase.
These practices travel through the whole lifecycle. Treating them as a final-stage checklist makes risks more expensive and feedback arrive later.
Security and privacy
Threat modeling, least privilege, safe data handling, dependency updates, and incident readiness belong in decisions and delivery—not only in a final penetration test.
PLAN → DESIGN → BUILD → RUNQuality engineering
Quality is a product of clear examples, sound design, maintainable code, layered tests, useful observability, and fast feedback across the team.
PREVENT → DETECT → LEARNDocumentation and decisions
Keep the information people need to use, change, operate, and support the product close to the work. Record durable decisions and why they were made.
CONTEXT → ACTION → OWNERSHIPDelivery automation
Automate repeatable build, test, package, and deployment steps. Automation improves consistency, but teams still own the rules and release decisions.
REPEATABLE STEPS, REVIEWABLE OUTCOMESAccessibility and inclusion
Include keyboard use, readable content, assistive technology, language, and different user contexts in research, design reviews, and verification.
DESIGN FOR REAL PEOPLERisk and technical debt
Make uncertainty visible. Track shortcuts and deferred work with context, impact, and a revisit trigger instead of letting invisible risk accumulate.
NAME IT → SIZE IT → REVISIT ITUse gates to make risk visible.
A gate is a decision with evidence and an owner—not a ceremony for its own sake. Keep the evidence proportional to the impact of getting the decision wrong.
Problem worth solving?
Do users have this need, and can the team describe the outcome it intends to improve?
Evidence: research, baseline, validated assumptionsApproach fit for purpose?
Can the proposed experience and architecture meet user, security, privacy, and operating needs?
Evidence: prototype, design review, risk analysisChange safe to release?
Are the important behaviors verified, known risks understood, and recovery path credible?
Evidence: test results, rollout and rollback planProduct still valuable?
Do outcomes and service health justify more investment, a change of direction, or retirement?
Evidence: usage, outcomes, support, cost, riskMany roles. One product team.
Titles vary by organization. The important thing is that each responsibility has a clear owner and that decisions include the people who understand their consequences.
| Role / perspective | Lifecycle contribution | Questions they help answer | Typical evidence |
|---|---|---|---|
| Users and customers | Explain context, try prototypes, use releases, and report friction or value. | Does this solve a real problem? What happens in the real workflow? | Research notes, feedback, usage patterns |
| Product manager / owner | Connect outcomes to priorities, clarify scope, and make product tradeoffs. | What matters now? What is the smallest useful next change? | Outcome measures, backlog, roadmap decisions |
| Design and research | Understand user behavior and shape understandable, accessible experiences. | Can people complete the task? What should happen at edge cases? | Journeys, prototypes, usability findings |
| Engineering | Design, build, integrate, review, and maintain the software system. | Is it correct, secure, understandable, and changeable? | Code, reviews, tests, architecture records |
| Quality engineering | Identify risk and create fast, useful evidence across test layers. | What could fail? What evidence is enough for this release? | Coverage, exploratory findings, defect analysis |
| Security / privacy | Bring threat, data protection, access, and compliance context into decisions. | What can be abused or exposed? Which controls are needed? | Threat models, findings, control evidence |
| Operations / support | Deploy, observe, respond, restore, and connect service behavior to user impact. | Can we detect trouble and recover? Who is affected? | Service levels, runbooks, incidents, support trends |
Small teams may share these responsibilities across a few people. Accountability should stay explicit even when job titles do not.
Methods change the rhythm, not the need.
Waterfall, Agile, DevOps, and continuous delivery describe different planning and operating choices. None removes the underlying lifecycle work.
Waterfall
Work moves through largely sequential phases with substantial upfront definition and formal review points.
Agile methods
Teams deliver small increments, revisit priorities, and learn through frequent stakeholder and user feedback.
DevOps
Development and operations share responsibility for flow, automation, reliability, and production learning.
Continuous delivery
Software is kept in a releasable state through automated checks and deployment practices; release timing remains a product decision.
Agile is not “no planning,” and DevOps is not a final phase. Both affect how planning, building, release, and operations connect. Choose a cadence and controls that fit the product’s risk, users, and regulatory context.
Lifecycle vocabulary, in plain terms.
Use a shared language to make handoffs clearer and decisions easier to revisit.
- SDLC
- Software Development Life Cycle: the activities and controls used to create, release, operate, and improve software.
- Requirement
- A user need, system behavior, constraint, or quality expectation that shapes the solution.
- Acceptance criteria
- Conditions that make a piece of work understandable and verifiable as complete.
- Backlog
- A prioritized, revisable set of work and questions a team may address.
- CI
- Continuous Integration: frequent code integration with automated build and verification.
- CD
- Continuous Delivery or Deployment: automated practices that keep software ready to release or release it automatically.
- Technical debt
- The future cost created by a shortcut or deferred improvement, ideally recorded with its reason and impact.
- Observability
- The ability to infer what a system is doing from its outputs, commonly logs, metrics, and traces.
- Rollback
- A recovery action that returns a service or data to a known-good state after a release problem.
- Feature flag
- A control that separates deploying code from exposing a capability to users.
- SLO
- Service Level Objective: a target for a measured reliability or performance indicator over a defined window.
- Retirement
- The planned end of a product or service, including migration, communication, data handling, and decommissioning.
Start with the next decision, not the whole roadmap.
Find the biggest uncertainty. Gather the people who can reduce it. Make the smallest useful change, verify it, release it safely, and listen to what happens next.
Explore the eight stages