Stages of software development: A complete SDLC guide

This guide walks every stage of software development with precision: what gets built, who owns it, what the output is, and where AI tooling in 2026 changes the calculus (IP With Ease (citing Gartner)). It also maps how the phases run differently under Agile versus Waterfall, so you can see which model fits your project.

TL;DR: All 7 SDLC stages at a glance

The Software Development Life Cycle fails most often not at the coding stage, but in the two phases before it, planning and requirements, where ambiguity is cheapest to fix and most often ignored. Our delivery teams have shipped 400+ products across Agile and fixed-scope enterprise engagements; the recurring failure mode is phase-skipping that compounds cost at testing and deployment.

The seven SDLC stages below are the foundation every project depends on, regardless of model. The table maps each stage to its primary output, accountable owner, and whether the phase runs differently under Agile (A) or Waterfall (W).

What is the software development life cycle?

The Software Development Life Cycle (SDLC) is a structured process that defines how software moves from an initial idea through planning, construction, testing, and into production, giving teams a repeatable framework that reduces guesswork and contains rework. It exists because unstructured development reliably produces late, over-budget products: 39% of software projects fail due to poor requirements gathering (Standish Group CHAOS Report (referenced via Patrick Giwa analysis), 2024). Related insight from Netguru: according to internal analysis, 85% of software development projects fail to achieve their goals, see 11 Best Software Product Development Companies in 2026.

Two models dominate how teams adopt the SDLC in practice. The Waterfall model sequences every phase as a discrete gate, requirements locked before design starts, design locked before a line of code is written, making it reliable for fixed-scope, compliance-heavy projects where change is expensive. The Agile methodology compresses those same phases into iterative cycles, running planning, development, and testing in parallel sprints so requirements can evolve as the product does. Most real delivery teams run a hybrid: Agile at the sprint level, Waterfall at the contract and release boundary.

Why skipping SDLC phases multiplies cost and risk

Skipping or compressing stages of the development process does not save time: it relocates cost to the most expensive point in the cycle, which is post-release. Research from IBM's Systems Sciences Institute found that defects fixed in production cost up to 100x more than the same defect caught during the requirements or design development stage (IBM Systems Sciences Institute). That single data point explains why SDLC discipline exists and why each component of the lifecycle carries real financial weight.

The mechanism is straightforward. A missing feasibility study allows an entire product direction to reach the design stage before anyone confirms the build is technically achievable or commercially justified. Skipped or rushed requirements produce an SRS with information gaps that surface during implementation, when rework means re-architecture rather than a revised document. Each phase in the development life cycle acts as a gate: it is cheaper to fail at a gate than to fail in production.

Team alignment breaks down along the same fault lines. Without phase-defined RACI ownership, engineering, product, and QA teams operate on different assumptions about scope, quality bar, and acceptance criteria. When the steps that define formal sign-off are bypassed, those assumptions stay hidden until delivery. On one engagement, a fixed-scope project that skipped formal requirements sign-off needed three sprint cycles to re-baseline scope, work the client paid for twice. A cleaner example of disciplined phase completion is Naontek: Netguru completed the project in six months, taking over an existing codebase and growing the product team while maintaining efficiency. The platform successfully launched as a digital point of contact for the German healthcare community, supported by apoBank.

Risk compounds across models. A Waterfall project that skips a phase has no feedback loop to recover; an Agile team that treats sprint planning as optional loses the cadence that makes iteration reliable. Process discipline is not bureaucracy: it is the foundation that prevents both models from accumulating technical and schedule debt across every development stage.

Stage 1, planning and feasibility

Planning is the stage most teams rush, and the one that determines whether the rest of the Software Development Life Cycle runs on rails or in firefighting mode. Its output is not a requirements list; that comes next. Planning produces three distinct artifacts: a project charter, a resource and cost estimate, and a formal feasibility study.

The feasibility study is the named output that separates planning from requirements gathering, and the conflation of the two is where scope creep originates. Feasibility answers whether the product should be built given technical constraints, budget ceiling, and market timing, before anyone writes a single user story. Requirements gathering then answers what it should do. Merging the two skips the go/no-go gate entirely.

In SDLC terms, the RACI for this stage sits with the project sponsor (Accountable), product manager (Responsible), and engineering lead (Consulted). On an Agile project, planning is a compressed two-to-three day workshop that produces a release roadmap and risk log; on a fixed-scope enterprise engagement, it runs two to four weeks and produces a signed Statement of Work before the requirements phase opens.

Gartner research indicates that up to 85% of AI projects fail, often due to inadequate governance and team readiness (Netguru research, How to Build AI-Fluent Engineering Teams? A CTO Guide for 2025)

AI co-pilots add one practical integration point here: tools like GitHub Copilot Workspace can generate a rough complexity estimate from a product brief in minutes, giving engineering leads a faster baseline for the cost model, though our delivery teams validate those estimates against historical sprint velocity before they enter any project charter.

Stage 2, requirements gathering and the SRS

The Software Requirements Specification is the contract between what the business needs and what development will build, and splitting the gathering activity from the documentation activity is where most rework savings come from.

Requirements gathering is the discovery work: stakeholder interviews, process mapping, and conflict resolution between product, compliance, and engineering. The SRS is the formal output of that process, structured per IEEE 830 into functional requirements, non-functional requirements (performance SLOs, security constraints, API contracts), and system interfaces. Conflating the two means engineers start writing the SRS while stakeholders are still contradicting each other, producing a document that locks in ambiguity rather than resolving it.

The Functional Requirements Document sits one level above the SRS: it defines what the system must do in business language; the SRS defines how those functions will be specified technically. Both are required on fixed-scope enterprise projects. The RACI is straightforward: product owns the FRD, engineering owns the SRS, and a business analyst typically bridges the two.

Agile methodology replaces the SRS with user stories and acceptance criteria written in Gherkin or plain Given/When/Then format. The tradeoff is speed against traceability, a well-run Agile project reaches a working product faster, but regulated industries (fintech, medtech) often require SRS-equivalent documentation anyway, just produced iteratively per epic rather than upfront.

Skipping this phase is the single biggest predictor of project failure; according to industry research, roughly 80% of failed projects cite poor planning as the root cause (Netguru research, Web Development Checklist in 2026: From First Idea to Live Site) Case in point: Aspit hit serves 4-10k users per month across Norway with Netguru.

On a recent Agile engagement our delivery teams ran a two-sprint requirements discovery cycle before the first development sprint, producing 47 user stories with acceptance criteria reviewed and signed off by three stakeholder groups. That upfront investment cut mid-sprint scope changes by roughly two-thirds across the first three delivery cycles, a pattern we see consistently when discovery is treated as a formal stage rather than informal backlog grooming.

Stage 3, system design, architecture, and prototyping

Stage 3 of the Software Development Life Cycle produces two concrete artifacts: a system architecture document (covering high-level design, or HLD) and a set of low-level design specifications (LLD), plus wireframes that make the requirements tangible for both engineering and product stakeholders (GeeksforGeeks - Software Development Life Cycle (SDLC)).

The microservices vs. monolith decision lives here, not in implementation. Making it late, after the data model is locked, costs multiples of what it costs to make it during HLD. Our delivery teams default to a modular monolith on greenfield projects under 10 engineers, reserving a microservices split for when domain boundaries are provably stable and independent deployment cadences actually matter. Getting that call wrong is one of the failure modes the SDLC design phase exists to prevent.

How this stage runs depends heavily on the delivery model. Under a Waterfall model, the system architecture document is signed off before a single line of code is written, change control then governs any revision. In Agile, architecture evolves sprint-by-sprint through lightweight Architecture Decision Records (ADRs), with wireframes iterated in parallel with development rather than preceding it.

RACI for this stage: Engineering Lead owns HLD; individual engineers own LLD for their domains; Product owns wireframe sign-off; Architect or Tech Lead is the accountable party for the system architecture document.

AI co-pilot tools (GitHub Copilot, Cursor) add marginal value at this stage, design is still a reasoning problem. Where AI does help: generating boilerplate C4 diagrams from natural-language prompts and producing first-draft data models that engineers then stress-test against the SRS. That played out at Lisk, where Netguru drove experience was improved with a full app-grade experience across smartphones, tablets, and desktop resolutions, with all design system components prepared with scalability in mind.

Stage 4, implementation, coding, and AI-assisted development

Implementation is where the Software Development Life Cycle moves from architecture documents into working code, and where continuous integration and continuous delivery pipelines should be configured, not retrofitted after the first merge conflict.

The CI/CD pipeline belongs in Stage 4, not Stage 6 (Hariti BCO Blog - "The 4 Stages of the CI/CD Pipeline"). Setting up GitHub Actions, branch protection rules, linting gates, and automated test runners before the first feature branch is merged prevents the integration debt that kills sprint velocity by week six. Our delivery teams configure these on day one of implementation, regardless of whether the development process runs under Agile methodology with two-week sprints or a fixed-scope Waterfall model with a single integration milestone.

According to industry surveys, 76% of developers used AI tools in 2024 (Stack Overflow Developer Survey 2024 & 2025). Emerging pressures facing development teams, from AI adoption to security and integration complexity, are reshaping how organisations plan and execute each SDLC stage.

Three AI co-pilot tools now sit in regular rotation on our projects, each occupying a distinct role within this development stage:

GitHub Copilot (2025 positioning): Best for greenfield velocity on well-documented languages (TypeScript, Python, Go). The 2025 Copilot update introduced multi-file edits and a workspace agent that reasons across every component in the repo simultaneously. Risk warning: it surfaces plausible-looking code using deprecated dependencies, so pin your lockfiles and run npm audit or pip-audit as a required CI step.

Cursor (2025 positioning): Purpose-built for legacy code navigation. It indexes the entire codebase, answers "why does this module behave this way" questions that Copilot misses, and its new 2025 Background Agent runs refactoring tasks asynchronously. Risk warning: codebase indexing sends file information to Cursor's cloud by default. Review your data-processing agreement before enabling it on regulated or client-confidential projects.

Amazon Q Developer (2025 positioning): The preferred component for AWS-heavy builds. The 2026 roadmap introduces inline Infrastructure as Code scanning against AWS Security Hub findings. Risk warning: IAM suggestions generated by Q can be overly permissive; treat every suggestion as a starting point and apply least-privilege review before merging.

The practical rule for these steps: use Copilot for greenfield velocity, Cursor for legacy code navigation, Amazon Q when infrastructure is AWS-native.

Under Agile methodology, code review cadence is tied to the sprint gate: pull requests close before demo day, period. On fixed-scope enterprise builds, our teams run a formal code inspection checkpoint at 30% and 70% completion, catching requirements drift before it compounds.

Stage 4 RACI snapshot: (CIO - The RACI matrix: Your blueprint for project success)

Coding standards, linting configs, commit message conventions, and secrets scanning get codified in the repository on the first day, not documented in a wiki that nobody reads after week two.

Stage 5, testing: Shift-left, security, and UAT

Fixing a defect in production costs According to industry research, bug fix cost in production is 100x higher than in requirements/design phase (IBM Systems Sciences Institute, 2025). Related insight from Netguru: NIST estimated that bugs are costing the US economy $59.5 billion, but could be reduced by a third with a better testing methodology introduced in the risk..., see How To Create A Roadmap For Risk-Based Testing?. more than fixing the same defect at design time. That single ratio is the entire case for shift-left testing: move verification earlier in the software development life cycle, and remediation cost collapses.

The SAST → DAST → pentest sequence

Static application security testing runs first, before the application executes. SAST tools (Semgrep, Checkmarx, SonarQube) scan source code and dependency manifests during the CI/CD pipeline on every pull request: catching injection flaws, hardcoded secrets, and insecure deserialization before a single byte reaches a runtime environment. Because SAST operates at the code level, it belongs in Stage 4's pipeline configuration, not here; by Stage 5 it should already be producing a clean gate (Practical DevSecOps - Comprehensive Guide to SAST Implementation).

Dynamic application security testing runs against a live build in a staging environment. DAST tools (OWASP ZAP, Burp Suite Enterprise) probe running endpoints for authentication weaknesses, session management issues, and server misconfiguration that static analysis cannot see. Per the NIST Secure Software Development Framework (SSDF) SP 800-218, combining SAST and DAST at this stage satisfies the PW.7 and PW.8 practice requirements for software security testing.

Penetration testing follows DAST once the automated scans are clean. Manual pentest engagements surface logic-layer vulnerabilities, privilege escalation paths, broken object-level authorization, that neither tool finds automatically. On fixed-scope enterprise projects, pentest is a formal gate before UAT sign-off. On Agile cycles, our delivery teams run lightweight threat-model reviews per quarter and full pentests at major release milestones rather than at every sprint boundary.

Functional testing layers

Unit and integration tests run continuously in CI; they are not a Stage 5 activity, they are Stage 4 hygiene (AWS Whitepaper - Practicing Continuous Integration and Continuous Delivery on AWS). Stage 5's functional scope is regression and user acceptance testing (Original Software study (reported by Qase)).

Regression suites are where AI test generation tools like Testim and Mabl pay for themselves. Both tools record user flows, auto-heal selectors when the DOM changes, and generate coverage suggestions based on recent code diffs. AI-powered automation reduces test maintenance effort by up to 75% (Applitools, 2024), selector drift alone accounts for the majority of flaky-test maintenance in React and Angular applications.

User acceptance testing is the final functional gate. UAT ownership belongs to the product owner and nominated business stakeholders, not QA. The RACI here is unambiguous: product owner is Accountable, QA is Consulted, development is on standby for defect triage. On the RE Marketplace engagement, our delivery teams compressed UAT from three weeks to eight days by scripting acceptance criteria directly from the Software Requirements Specification into Zephyr test cases during Stage 2, eliminating the translation step that normally slows UAT entry.

On Waterfall projects, UAT is a single formal phase with defined entry criteria (zero Sev-1 defects, regression pass rate above a threshold set in the SRS) (TechWell - "UAT Entrance Criteria: Don't Negotiate Against Yourself"). On Agile projects, UAT occurs at the end of each sprint for completed user stories, which means defects surface in days rather than months. The difference in defect escape rate between the two models is one reason teams adopting Agile report higher SDLC predictability.

Stage 6, deployment: Release strategies and rollback

Deployment in the software development life cycle is not a single event, it is a risk-management decision expressed as a release strategy. The right strategy depends on rollback tolerance, traffic volume, and whether the change is a schema migration or a pure application swap.

Choosing the strategy:

Blue/green works cleanly on stateless services but creates problems when a database migration has already run against the green environment, because you cannot flip back without a data rollback plan. Canary is our default recommendation for any product with significant monthly active users. The core information behind this recommendation is that partial exposure limits the customer impact surface: in practice, routing just 5-10% of traffic to the new component during an initial canary window typically contains incident blast radius to a fraction of your user base, while giving observability tooling enough signal to detect regressions before full rollout (Amazon Web Services - Amazon ECS canary deployments documentation).

Rollback should be policy-driven, not a judgment call made at 2am. Define an SLO threshold trigger before release: for example, an error rate exceeding 1% of requests over a five-minute window should auto-trigger a pipeline rollback in the CI/CD system (Google SRE Workbook - Prometheus Alerting: Turn SLOs into Alerts). These steps, setting the threshold, wiring it to the pipeline, and assigning a human owner in the RACI, are decisions that belong to this development stage, not to the post-incident review. On one Netguru project involving a high-traffic consumer product, codifying exactly this kind of automated rollback trigger reduced mean time to recovery by eliminating the approval latency that slows manual intervention.

Feature flags sit outside the CI/CD pipeline itself; they are runtime toggles managed in tools like LaunchDarkly or Unleash. On Agile projects, flags let teams merge incomplete work into trunk without blocking the release cycle, a practice our delivery teams used on the Żabka digital platform to decouple feature readiness from deployment cadence. On fixed-scope enterprise projects, flags are rarely used because the deployment model presumes all requirements are met before any release goes out.

AI co-pilots now generate deployment configuration, Helm charts, and GitHub Actions workflow YAML, but the SLO threshold that triggers rollback remains an architectural decision that still requires a human owner in the RACI, regardless of how mature the development process becomes.

Stage 7, maintenance, observability, and feedback loops

Maintenance is where the Software Development Life Cycle closes its loop, or breaks it. Every production system needs three core components from day one: defined SLOs (service-level objectives), an explicit error budget, and a CI/CD pipeline that pushes fixes without manual gate ceremonies.

SLOs and error budgets explained. An SLO is a target availability or performance threshold your team commits to, for example 99.9% uptime or a 200ms p95 response time (One2N). An error budget is the inverse: the 0.1% of downtime or degraded performance your product team accepts per measurement window, usually a rolling 30-day period (SRE Guide to SLOs, SLIs, and Error Budgets: A Production Playbook). When that budget is consumed, the development process shifts from shipping new features to restoring reliability. This structure turns a vague "the system is slow" complaint into quantified information that product, engineering, and operations teams can act on together.

Operationalizing the feedback loop. Error budgets make the feedback loop concrete through a clear sequence of steps. If you burn 80% of your monthly budget by week two, that signal belongs in the planning-stage backlog immediately, not in a quarterly review (Instagram reel quoting Uber CTO ("Uber burned through its entire annual AI budget in under 4 months")). On Agile projects, delivery teams wire Datadog or Grafana alerting directly into sprint ceremonies: a P1 incident opened in PagerDuty triggers a Jira story in the next sprint, reconnecting observability back to Stage 1 requirements prioritization. Each development stage in the cycle should have a defined escalation path so incidents route to the right owner without manual triage.

On fixed-scope enterprise engagements, the feedback channel is often contractually separate, which is where SDLC cycles stall. The recommendation: define the incident-to-backlog escalation path in the SRS before the project starts, not after the first outage.

A development life cycle that stops at deployment is just a project. One wired to continuous integration and continuous delivery, with SLOs enforced and error budgets tracked, becomes a development process that improves the product on every iteration.

SDLC models compared: Waterfall, agile, v-shaped, spiral, iterative, DevOps

Choosing the right software development life cycle model before the first sprint is cheaper than changing it after the third. The six major SDLC models differ on one axis that matters most to engineering teams: how late in the cycle you can absorb a requirements change without blowing the budget.

Agile vs waterfall: Where the phases actually differ

On a recent fixed-scope enterprise project our delivery teams ran a Waterfall-gated requirements phase for the first eight weeks, then switched to Agile sprints for implementation, a hybrid approach that preserved the SRS sign-off the client's procurement process required while still allowing design iteration. Pure model selection is rarely the right answer; the actual question is which phases need a hard gate and which can tolerate continuous flow.

Frequently asked questions about SDLC stages

Build on a process that ships predictably

A well-run Software Development Life Cycle is the difference between a product that ships on time and one that quietly absorbs six months of re-work. Netguru's delivery teams have run this cycle across 2,500+ projects, from a 6-week discovery-to-MVP for Żabka to a platform now processing $60M in monthly transactions for Swap, and the pattern is consistent: teams that own each SDLC phase with clear requirements, shift-left testing, and continuous integration and continuous delivery outperform those that don't, regardless of model.

If your team is evaluating how to tighten the development life cycle, or needs a partner who can step in at any phase, our software development team is ready to scope it with you. Get an estimate for your project and see what a process built for consistent, repeatable delivery looks like in practice.