What Are the Five SDLC Phases?

The five SDLC phases used in this guide are planning, analysis, design, implementation, and use and maintenance. Implementation includes building, testing, and deploying. Other frameworks split those activities into additional phases; the count is less important than clear ownership and evidence at each decision.

For founders and operators, the software development life cycle is a way to expose missing decisions before they become release problems. A lightweight MVP and a complex enterprise system need different amounts of documentation, but both need scope, design, quality checks, and an operating owner.

One delivery map

Phase	Main output	Accountable decision	Gate before proceeding
Planning	Goal, alternatives, budget assumptions, exclusions	Sponsor approves the next investment	Problem and intended outcome are clear enough to investigate
Analysis	Workflow, requirements, risks, acceptance criteria	Product owner agrees what the release must do	Important users, exceptions, data, and constraints are represented
Design	Prototype, architecture, data and permission model	Design and technical leads recommend a build path	Critical usability and feasibility assumptions have evidence
Implementation	Reviewed code, tests, deployment and recovery plan	Release owner accepts the tested scope	Required checks pass and unresolved risks have a decision
Use and maintenance	Monitoring, support, patches, feedback, improvement backlog	Product and operational owners prioritize follow-up	The system remains supportable or is deliberately retired

These roles can be held by fewer people in a small team. Make that explicit so a responsibility does not disappear between phases.

Phase 1: Planning

Begin with the problem and alternatives, including doing nothing, improving the process, configuring an existing tool, or building software. Define the business outcome, constraints, budget range, decision-maker, and what the first release excludes.

Consider a hypothetical internal purchase-request tool. Requests currently move through email, so staff cannot see who needs to act. The proposed goal is to make request status and approval ownership visible. Version one excludes supplier payments and automatic purchasing.

The planning gate is a decision to investigate that bounded problem. It is not a commitment to every feature in the sponsor’s initial idea. Record uncertain benefits and collect a baseline before claiming savings.

Phase 2: Analysis

Map the current workflow with requesters, approvers, finance, and support. Inspect ordinary cases and exceptions: rejected requests, missing information, absent approvers, cancellations, and duplicate submissions.

For the example, record required fields, approval rules, access boundaries, notifications, audit events, and retention needs. A testable requirement might be: “A requester can view their own request status but cannot approve it or view another department’s restricted request.”

Put acceptance criteria beside requirements, with examples and an owner for unresolved questions. A software requirements specification can be short if the problem is small. Its value is shared understanding and traceability, not page count.

The analysis gate checks whether the team can explain the workflow and estimate the major uncertainties. An unknown identity integration may require a proof of concept before design is finalized.

Phase 3: Design

Design covers the user experience and the technical system. Explore screens and states, data relationships, server-side permissions, integration behavior, errors, deployment, and recovery. Compare alternatives and record why one fits the constraints.

In the purchase-request example, a prototype can test whether employees understand “needs information” versus “rejected.” The technical design specifies who can move a request between states and how duplicate notification delivery is handled.

Do not use a polished prototype as proof that the integration works. Test the hardest technical assumption separately. The design gate requires evidence appropriate to the risk: usability findings, an integration spike, reviewed data handling, or an agreed security model.

Phase 4: Implementation, testing, and deployment

Build in small slices that exercise a complete path. For example, first create and view a request, then add approval, then notifications and exception handling. Review code and tests against the agreed behavior as work proceeds.

Testing should cover normal paths, rejected input, forbidden actions, duplicate requests, integration failures, accessibility, and relevant load. The exact mix depends on the system; more tests do not automatically mean better risk coverage. Connect checks to the failures that would matter to users.

Use development and staging environments with controlled data and access. Before release, verify the build, configuration, database changes, smoke tests, support route, and recovery procedure. A code rollback may not reverse a database migration or external side effect, so rehearse the appropriate recovery path.

For the example pilot, the release owner checks that a requester cannot self-approve, an absent approver has a defined escalation path, and failed notifications are visible. Launch to a bounded group only when those conditions and the agreed baseline controls pass.

Phase 5: Use and maintenance

Operational software needs ongoing ownership. Maintenance includes dependency and security updates, monitoring, backup and restore checks, access reviews, defect triage, vendor changes, and support. It is not an optional extra while people rely on the system.

Measure whether the example tool helps requests move: completion time, overdue approvals, duplicate requests, errors, and support effort. A reduction in clicks alone does not establish a business improvement.

Feed findings into the next planning cycle. If employees return to email, investigate the missing workflow or confusing state before adding another dashboard. If the tool is no longer justified, plan data retention, export, access revocation, and retirement.

Security and quality span every phase

NIST’s Secure Software Development Framework provides a reference for integrating secure development practices into a life cycle. Security is not a final scanner run or a promise implied by using SDLC.

During planning, identify sensitive data and consequences of misuse. During analysis and design, define permissions and likely abuse cases. During implementation, review dependencies, code, configuration, and negative tests. During operation, patch, monitor, and respond to incidents with a named owner.

Similarly, quality assurance begins when requirements and acceptance criteria are defined. It continues through review, testing, and production feedback.

Iterate when evidence changes the plan

The phases do not require one irreversible pass. A usability test may change requirements; an API limitation may change scope; a production incident may change architecture. Record the reason, impact, and approval for a change so the team can adapt without losing accountability.

Choose among SDLC models based on uncertainty, delivery constraints, and risk. The useful result is a repeatable path from problem to tested software to responsible operation, with enough evidence to decide what happens next.

Carry these deliverables and review gates into an MVP development engagement so the first release includes a responsible operating handoff.