The 7 Stages of the Software Development Life Cycle (With Real Timelines)

Direct answer: The software development life cycle (SDLC) has 7 stages: planning, requirements analysis, design, development, testing, deployment, and maintenance. On a typical 3–6 month project, planning and requirements together take roughly 15–25% of the pre-launch timeline, design 10–15%, development 35–40%, testing 15–20%, and deployment the final 5–10%, and then maintenance runs indefinitely after launch.

The Software Development Life Cycle (SDLC), Explained

What is the SDLC? The software development life cycle is the standard sequence of stages a piece of software moves through, from the first business justification to the day it's retired: planning, requirements analysis, design, development, testing, deployment, and maintenance. Every methodology, including waterfall, agile, and hybrid, runs the same 7 stages in a different rhythm, not a different set of stages.

The SDLC isn't a framework any one vendor invented. It's closer to a checklist that exists because skipping a stage is exactly how projects fail. A team that jumps from a vague idea straight into coding is still doing "requirements analysis," just badly and by accident, usually discovered when a client rejects a finished feature that solved the wrong problem. Naming and sequencing the stages is what makes them manageable, and trackable, which matters a great deal if you're paying someone else to run them (more on that in the outsourcing section below).

Two things trip people up about the SDLC specifically:

• It's a model, not a methodology. Waterfall runs the 7 stages once, in strict order. Agile runs a compressed version of all 7 inside every sprint. Both are "doing the SDLC." They just structure the same stages differently. See the comparison table below.
• "Maintenance" is a stage, not an afterthought. It's the only stage with no fixed end date, and for most systems it consumes more of the software's lifetime budget than everything before it combined. See the sourced figures in stage 7.

Sample SDLC Timeline for a 3–6 Month Project

How is SDLC time typically split across stages? There's no universal percentage. Timeline share shifts with methodology, team size, and how well-defined the requirements already are. The table below is an illustrative template for a mid-size custom build (an internal tool, a customer portal, a first-version product) run over 3–6 months; treat it as a planning starting point, not a benchmark your project must match.

Two things to note about this template. First, the ranges overlap in agile delivery, where testing and even parts of design happen inside the same sprints as development, rather than as one long block at the end, so the percentages blend together in practice more than the table suggests. Second, projects with unclear requirements going in should expect stages 1–2 to run longer than shown here; every week spent tightening scope before development starts is cheaper than the same fix discovered mid-build (the data on why is in stage 5 below).

The 7 Stages of the SDLC, Explained

The 7 Stages of the SDLC, Explained (AI-generated illustration)

1. Planning

Goal: Confirm the project is worth doing before anyone commits real budget, covering the business case, rough scope boundaries, budget ballpark, and what "success" will be measured against. Deliverable(s): Project charter or statement of work, high-level roadmap, feasibility assessment. Who's involved: Client stakeholders/sponsor, project manager, solutions architect (for a technical feasibility read).

Planning is short on purpose. Its job isn't to answer every question. It's to answer the one question that matters before spending more money: does this project make business sense, roughly, at this scope and this budget? Projects that skip planning and jump into detailed requirements tend to discover a budget or feasibility problem much later, when it's expensive to unwind.

2. Requirements Analysis

Goal: Convert the business goal from planning into a precise, specific list of what the system must do, covering functional requirements (features, workflows, data) and non-functional requirements (performance, security, compliance, uptime). Deliverable(s): Requirements document or product backlog, user stories with acceptance criteria, a signed-off scope. Who's involved: Business analyst, project manager, client subject-matter experts (the people who actually do the work being systematized, not only their managers), solutions architect.

This is the stage with the most documented failure risk in the entire SDLC. See the data below. The work here is unglamorous: interviewing the people who'll use the system, writing down the edge cases nobody mentions until month four, and getting explicit sign-off on scope so "requirements" means the same thing to both sides of the contract. Custom builds, where the software has to mirror a specific business process rather than a generic template, live or die on how seriously this stage is taken; see our guide to custom software development for how a discovery-first process handles it.

3. Design

Goal: Turn signed-off requirements into a technical and visual blueprint before a line of production code gets written. Deliverable(s): System architecture diagram, data model, API contracts, wireframes and clickable UI/UX prototypes, finalized technology stack. Who's involved: UI/UX designer, solution architect, tech lead.

Design is where the requirements document becomes something an engineer can actually build from, and something a client can click through and react to before committing to a build. Catching a wrong workflow assumption in a clickable prototype costs an afternoon of redesign; catching the same mistake after development is a rebuild.

4. Development

Goal: Build the system to the approved design. This is the stage most people picture when they hear "software development," and consistently the longest one. Deliverable(s): Working code, typically demoed at the end of each sprint on a staging environment the client can log into. Who's involved: Developers (front-end, back-end, mobile as applicable), tech lead, project manager, often the client as a reviewer at sprint demos.

Development earns its 35–40% share of the timeline because it's where every earlier decision compounds. A clean requirements document and a clear design turn into a straightforward build; an ambiguous one turns into constant clarification requests that stall sprints. The single biggest lever teams have to keep this stage on schedule is a locked design going in and a disciplined change process for anything that comes up mid-build (see scope creep below).

5. Testing

Goal: Verify the system actually does what the requirements said it should, and find defects before users do. Deliverable(s): Test cases and test reports, a tracked bug/defect log, performance and security test results, client user-acceptance testing (UAT) sign-off. Who's involved: QA engineers, developers (fixing what QA finds), client-side UAT testers.

Testing isn't a gate at the end of development so much as it's where the cost of every earlier shortcut gets collected. The often-cited (and admittedly imprecise) figure from IBM's Systems Sciences Institute is that a bug found during development costs roughly 6x more to fix than the same bug caught during design, and one found during testing runs roughly 15x more. The exact multipliers are debated and the source methodology isn't public, but the direction (defects get exponentially more expensive the later they're caught) is confirmed by newer studies too (source: Black Duck, Cost to Fix Bugs and Defects During Each Phase of the SDLC). Practically: a QA process embedded throughout development, not bolted onto the end, is what keeps this stage from becoming the most expensive one.

6. Deployment

Goal: Release the tested system to production without breaking anything currently running, and with a way back if something goes wrong. Deliverable(s): Production release, deployment runbook, rollback plan, environment configuration, end-user or admin training materials. Who's involved: DevOps/release engineer, project manager, client-side IT (for on-prem or hybrid environments).

Deployment is short in the table above, but "short" isn't the same as "low-risk." It's the stage where a mistake is most visible, most immediately, to the most people (your live users). A deployment plan with a tested rollback path is what turns a launch-day bug into a five-minute revert instead of a five-hour outage.

7. Maintenance

Goal: Keep the system running, secure, and useful after launch, through bug fixes, security patches, performance monitoring, and the feature requests that always follow a successful release. Deliverable(s): Monitoring and uptime reports, patch releases, an SLA-based support process, a backlog of post-launch enhancements. Who's involved: A support/maintenance team (often smaller than the build team), the original dev team for anything structural, project manager.

Maintenance is the SDLC stage with no fixed length, and it's larger than most budgets assume: industry estimates built on the IEEE's long-cited "60/60 rule" put maintenance at roughly 60% of a system's total lifecycle cost, with annual maintenance commonly running 15–25% of the original development budget (source: O'Reilly, The 60/60 Rule, "97 Things Every Project Manager Should Know"). If you're budgeting a software project, the launch invoice is the down payment, not the total. Our custom software development cost guide breaks down what typically shows up after go-live.

Waterfall vs. Agile vs. Hybrid: The SDLC Model That Fits Your Project

What's the difference between waterfall, agile, and hybrid SDLC models? Waterfall runs all 7 stages once, in strict sequence, with each stage finished before the next starts. Agile compresses a mini version of all 7 stages into every 1–4 week sprint, shipping working software continuously. Hybrid, now the most common real-world choice, plans and designs up front like waterfall, then builds and tests in agile sprints.

Source: pmwares, 17th Annual State of Agile Report Summary; Pawel Rola, 18th State of Agile Report (2025) Key Insights. Figures come from self-reported vendor/practitioner surveys, not a census. Treat as directional, not exact.

The honest takeaway: pure waterfall and pure agile are both becoming less common as stated methodologies, because most real projects need waterfall's upfront clarity on budget and architecture and agile's ability to adjust mid-build without blowing up the whole plan. If a vendor insists you must pick one pure model, that's usually more about their internal process than what your project actually needs.

Where Software Projects Die Most in the SDLC

Where Software Projects Die Most in the SDLC (AI-generated illustration)

Which SDLC stage causes the most project failures? Requirements analysis is the single most-cited failure point: PMI's Pulse of the Profession research on requirements management found that 47% of unsuccessful projects fail due to poor requirements management, and organizations waste roughly 5.1% of every project dollar (about $51 million per $1 billion spent) on the same problem. Development is a close second, mainly through uncontrolled scope creep.

The broader numbers set the stakes: across a 50,000-project sample, the Standish Group's CHAOS research found only 31% of projects were fully successful, 50% were "challenged" (over budget, over time, or short of scope), and 19% failed outright. Project size mattered enormously: small projects succeeded roughly 90% of the time, versus under 10% for large projects (source: OpenCommons, CHAOS Report on IT Project Outcomes).

Layer the requirements data on top of that, and a pattern emerges (source: Watermark Learning, 3 Takeaways from PMI Pulse of the Profession, Requirements Management):

• 47% of unsuccessful projects trace back to poor requirements management, not poor coding.
• Only 20% of organizations report high requirements management maturity, meaning most teams are running this stage without a formal process at all.
• The financial waste compounds: 5.1% of every project dollar is lost to requirements failures alone, before any code is written.

Why does this one stage cause so much damage? Because errors made in requirements analysis don't surface until much later, often not until testing or even after launch, by which point the cost-to-fix curve has already made the mistake expensive. A vague requirement doesn't look like a problem in week two; it looks like a rebuilt feature in month four. The practical implication for anyone commissioning software: the discovery/requirements phase deserves real time and real domain-expert input, not a rushed kickoff call before development "gets going," however tempting it is to skip ahead to the visible part of the work.

Tracking SDLC Stages When You Outsource Development

How do I monitor SDLC progress when a vendor is running the project, not my own team? Ask for a deliverable at the end of every stage, not just a status update, and a fixed cadence for reviewing it: a signed requirements doc, a clickable prototype, a sprint demo on staging, a UAT sign-off, a deployment runbook. If a vendor can't produce a concrete artifact for a stage they say is "done," that stage isn't actually done.

Outsourcing doesn't remove any of the 7 stages. It just moves who's sitting in the room for each one, often across a time zone. That makes visibility a deliberate design choice, not something that happens by default. A few concrete checkpoints to build into any outsourced engagement:

• After planning: You should have a written charter and budget range, not a verbal "sounds good, let's start." If there's no document, there's no agreed baseline to hold the vendor to later.
• After requirements analysis: Insist on a requirements document or backlog you can actually read and sign off on, not a summary paragraph. This is the artifact most worth your time to review line by line, given the failure data above.
• During design: A clickable prototype you can click through yourself, not a static image deck. Approve it before development starts; changes here are cheap, changes mid-build are not.
• During development: Sprint demos on a staging environment you can log into anytime, on a fixed cadence (typically every 1–2 weeks). If months pass between demos, you've lost the main advantage agile and hybrid models are supposed to give you.
• During testing: A visible bug/defect log and a UAT process where your own team, not just the vendor's QA, tries to break the system before go-live.
• At deployment: A written rollback plan you've seen before launch day, not one improvised if something breaks.
• In maintenance: An SLA with defined response times and a monitoring report you receive on a schedule, not only when something is already broken.

This is also where the choice of engagement model matters. A fixed-price project pushes most of this visibility into milestone payments; a dedicated team or staff-augmentation model puts your own PM inside the same sprint cadence as the vendor's, which is usually the fastest way to get real-time SDLC visibility rather than periodic reports. Either way, the vendor you choose should be able to show you what a requirements document, a sprint demo, and a UAT sign-off from a past project actually looked like, not just describe the process in a sales call.

If what you're building is a browser-based application rather than an internal system, like a customer portal, a booking platform, or a dashboard, the same 7 stages apply, but the design and testing stages carry more UX and cross-browser weight; see our web application development services for how that shifts the process. For a broader look at how a full-service partner runs discovery, architecture, build, and support under one roof, our software development company page covers the end-to-end version of everything described here.

FAQ

What are the 7 stages of the SDLC?

The 7 stages are planning, requirements analysis, design, development, testing, deployment, and maintenance. They run in that order in a waterfall model, and in a compressed loop inside every sprint under agile or hybrid models. The stages themselves don't change, only how they're sequenced.

Which SDLC stage takes the longest?

Development typically takes the largest share of a project's pre-launch timeline, commonly 35–40% on a mid-size build, because it's where every requirement and design decision gets implemented. Maintenance, however, has no fixed end date and often costs more over a system's full lifetime than every other stage combined.

Which SDLC stage causes the most project failures?

Requirements analysis. PMI's Pulse of the Profession research found that 47% of unsuccessful projects fail due to poor requirements management, and roughly 5.1% of every project dollar is wasted on the same issue. That's more than any other single documented cause of software project failure.

What's the difference between the SDLC and agile?

The SDLC is the set of 7 stages every software project passes through; agile is one way of sequencing them, running a mini version of all 7 stages inside short, repeated sprints instead of one long sequential pass (waterfall). Agile doesn't remove any SDLC stage; it just repeats a compressed version of all of them continuously.

Do all software projects go through all 7 SDLC stages?

Yes, in some form. Even a rushed or informal project still moves through planning, some level of requirements, a design decision, building, checking the work, releasing it, and fixing it afterward. Skipping a stage on paper just means it's happening implicitly and without documentation, which is exactly the pattern behind many of the failure statistics above.

How much does going through the full SDLC cost?

It depends entirely on project scope, team location, and how many of the 7 stages the vendor handles in-house versus subcontracts. See our custom software development cost guide for 2026 price ranges by project type and region. As a rule of thumb, budget for maintenance separately: it's an ongoing cost, not a one-time line item in the original quote.

How do I know if a vendor is skipping SDLC stages to save time?

Ask for the deliverable each stage is supposed to produce, such as a requirements document, a clickable prototype, a sprint demo, a UAT report, or a deployment runbook, and check it exists and is dated appropriately relative to the project timeline. A vendor that can only describe stages verbally, without producing the artifact, is very likely compressing or skipping them.