Software Development Life Cycle (SDLC): Phases & Models

The software development life cycle (SDLC) is the structured set of phases an engineering team moves through to build and run software: planning, requirements, design, implementation, testing, deployment, and maintenance. It's the engineering view of how software actually gets made — each phase produces something the next one needs, and the whole thing loops, because software is never really done. If the product side asks "what should we build and for whom," the SDLC answers "how do we build it, prove it works, and keep it alive."

This guide is the version we'd hand a founder or a new engineer who wants the real picture, not a textbook diagram. We'll walk the phases of the SDLC, lay out the main SDLC models in a table you can actually use, clear up the lazy "SDLC vs Agile" framing, and show how we run the whole thing day to day.

What the software development life cycle is

The software development life cycle is a way of breaking "make software" into phases that each answer one question, in an order where the answers build on each other. Planning asks whether the thing is worth doing. Requirements ask what exactly it has to do. Design asks how it'll be put together. And so on down to maintenance, which asks how you keep it healthy once people depend on it. Name the phases and you've made the work legible — to the team, to the client, and to whoever inherits the codebase two years from now.

There's a subtle point that trips people up. The SDLC isn't a project schedule, and it isn't a methodology. It's the underlying anatomy of any software effort. A scrappy two-person startup and a regulated bank both move through these same phases — they just move through them at wildly different speeds and with different amounts of paperwork. The phases are the constant. The model you wrap around them, which we'll get to, is the variable.

I'll be blunt about why this matters: the SDLC exists to make the cost of a decision visible before you've paid it. A bad requirement caught while planning costs a five-minute conversation. The same bad requirement caught after deployment costs a rebuild, plus the trust you burned shipping the wrong thing. Every phase is a checkpoint where being wrong is still cheap. Skip the phase and you don't skip the cost — you just defer it to the most expensive possible moment.

The phases of the SDLC

There are seven phases most teams recognize, and a fair warning before the list: they overlap. The clean numbered sequence below is a teaching device. In real builds, design starts before requirements fully close, and testing runs alongside implementation rather than after it. What stays fixed is what each phase is responsible for.

1. Planning. Decide whether the thing is worth building and roughly what it'll take. You're scoping the problem, sizing the effort, and naming the constraints — budget, deadline, the systems you have to live with. The output is a go decision and a rough shape, not a spec. Practical tip: write down what you're explicitly not doing in v1. The deferred-scope list is worth more than the feature list, because it's the thing that keeps the build honest. Common mistake: treating planning as a formality and rushing to "real work," which is how a team commits to a deadline before anyone understands the actual scope.

2. Requirements and analysis. Pin down what the software must do, concretely enough to build against. This is where vague intent ("users should be able to manage their account") becomes specific behavior ("a user can reset a password, change email with re-verification, and close the account"). Functional requirements describe what it does; non-functional ones — performance, security, uptime — describe how well, and they're the ones teams forget until production punishes them. Common mistake: writing requirements nobody can test. If you can't say how you'd prove a requirement is met, it's a wish, not a requirement.

3. Design. Shape how the system fits together before feature code exists — the architecture, the data model, the API contracts, where logic lives, how the pieces talk. This is the phase with the most payoff in the whole life cycle. An hour spent on the data model here saves a week of migrations later, because the schema is the single hardest thing to change once everything's built on top of it. Practical tip: design the failure cases, not just the happy path. The empty state, the timeout, the half-finished transaction — those are where shipped software actually breaks.

4. Implementation. Write the production code for the design you agreed on. This is the phase people picture when they say "development," and it's usually the longest stretch on the calendar — but it goes fast precisely because the phases before it did their job. A senior team keeps the trunk shippable from the first commit rather than integrating in a panic at the end. We dig into this part for browser-based products in how to build a web app.

5. Testing. Prove the software does what the requirements said, and fails safely when it doesn't. Unit tests cover the pieces, integration tests cover the seams, and end-to-end tests cover the paths a real user walks. The mistake here isn't skipping tests outright — almost nobody does that anymore — it's bolting testing on at the end as a separate phase. Run it continuously, wired into CI/CD, and "is it ready to ship" stops being a question you dread.

6. Deployment. Get the software into production with monitoring, logging, and alerting already live. Going live should generate real telemetry, not just a public URL you cross your fingers over. Practical tip: the first deploy should happen early and often, not once at the end — a team that's deployed fifty times by launch day has turned a terrifying event into a boring one. This is also where automated pipelines earn their keep, because manual deploys are where human mistakes sneak into production.

7. Maintenance. Keep the software healthy once people rely on it — fix bugs, patch security holes, watch performance, and feed real usage back into the next round of planning. This is the phase that never ends and the one budgets quietly ignore. Most of a system's life is spent here, not in the original build. Common mistake: treating launch as the finish line. The cycle loops back to planning for a reason — what you learn in production is the best input you'll ever get for what to build next.

Every phase you skip to "save time" is a phase you'll pay for later, with interest. The SDLC doesn't slow you down — it moves the hard decisions to the moment they're cheapest to make.

The main SDLC models

Here's the distinction that clears up most of the confusion: the phases above are what you do, and the model is how you sequence them. A model doesn't add or remove phases — it decides whether you run them once or on repeat, all at once or one at a time, with or without a formal risk gate. Pick the model to match the project's risk and how stable its requirements are, not because it's fashionable.

A couple of honest opinions on that table. Most modern teams run some flavor of Agile or iterative, and they should — software requirements almost never hold still long enough for pure Waterfall to be the right call. But Waterfall and the V-model aren't relics. When you're shipping firmware for a medical device or a fintech system under audit, the documentation trail and verification rigor are the point, not bureaucracy. And spiral is the one most teams name but few actually run; in practice its risk-first thinking lives inside good Agile, sprint by sprint. Choosing a model is really choosing how much you're willing to bet that your requirements are right up front.

SDLC vs Agile (they're not the same thing)

This is the most common mix-up I hear, so let's kill it cleanly: the SDLC and Agile aren't alternatives. The SDLC is the set of phases. Agile is one model for sequencing them. Asking "should we use the SDLC or Agile?" is like asking "should we use a kitchen or a recipe?" — they're different kinds of thing, and you use both.

An Agile team still plans, gathers requirements, designs, implements, tests, and deploys. It just does all of those inside every two-week sprint instead of marching through them once over six months. Waterfall runs the same phases too — once, in a straight line. So every team that ships software is running an SDLC, named or not. The only real question is which model shapes the cadence. "We're Agile, we don't do the SDLC" usually means "we don't write the phases down," which is a different and more worrying claim. For the broader picture of how these models actually play out in practice, our software development methodologies guide goes model by model.

How we actually run the SDLC

We run an iterative, Agile-flavored cycle, and we don't pretend the phases are watertight — they overlap on purpose. The thread that holds it together is that one senior squad carries a build through every phase. No handoff between the people who design and the people who implement, which is where so much intent gets lost in translation. The engineer who shaped the data model is the one who lives with it in production, so the decisions get made by people who'll have to maintain them.

AI-native delivery changes the speed of the phases without changing what they're for. We use AI to draft requirements faster, scaffold implementation, and widen test coverage — but planning still decides what's worth building, design still owns the architecture, and a human still signs off on what ships. The phases are the guardrails that keep the speed pointed in the right direction. A first production release lands in roughly 6 to 12 weeks not because we skip phases, but because doing each one properly the first time is faster than redoing it.

One last framing. This guide is the engineering life cycle — phases and models. The product development process is its sibling on the product side, the discovery-to-iteration arc that decides what's worth building before this cycle even starts. The two interlock: product development figures out the right thing to build, and the SDLC is how we build it right. You can see both run end to end across our custom software development and product development work.