Software Development Life Cycle Stages Compared

The six stages in order

Most descriptions of the software development life cycle list six stages: planning, requirements, design, build, test, and deploy with maintenance. AWS's overview of the SDLC uses the same sequence under slightly different names.

The names matter less than the hand-offs. Each stage produces something the next one depends on, and most delivery problems come from a stage that handed over something vague.

The sections below take the stages one at a time, then compare how three common models arrange them. We have been shipping software since 2007, across 500+ projects, and the pattern we see most often is that teams agree on the list of stages and disagree on when each one is finished.

Planning and requirements

Planning decides whether to build and roughly how big the work is. Requirements decide what the software must do, written precisely enough that two people would build the same thing from it.

The output you want is a short document a stranger could read. It names who uses the system, what they do in it, and what is explicitly out of scope. That last part saves the most money later.

A requirement like "users can export reports" is not finished. Ask which formats, how many rows, who is allowed to export, and what happens when the export takes ten minutes. Each answer removes a future argument.

Design

Design turns requirements into a structure: how the data is stored, how the parts talk to each other, and what the screens do. It is also where you pick the hosting platform and the main libraries.

Keep design proportional to the risk. A rarely changed internal admin screen needs a sketch. A payment flow or a multi-tenant data model needs a written design that someone other than the author has challenged.

The common failure here is designing for scale you do not have. A system built for a hundred times your current traffic costs you build time now, for load that may never arrive.

Build and test

Build is the writing of code against the design. Test checks that the result matches the requirements, and it should start while build is still going rather than after it.

Automated tests written alongside the code catch regressions cheaply. Manual and exploratory testing finds the cases nobody wrote down. If you do not have a dedicated team for this, a QA and testing partner can cover the second kind while your developers keep the first.

The trade-off is speed against confidence. Skipping test automation makes the first release faster and every later release slower.

Deploy and maintain

Deployment puts the software in front of users. Maintenance is everything after: bug fixes, dependency updates, monitoring, and the small feature requests that never stop.

Release method is a real decision. A rolling update, as described in the Kubernetes documentation, replaces instances gradually so users see no downtime, but it requires your old and new versions to work against the same database at the same time.

Maintenance is usually the longest stage by years. Budget your team's attention for it from the start, and consider DevOps consulting if releases are still manual and nervous.

How waterfall, agile and fixed-scope builds differ

The three models use the same stages but run them differently. Waterfall completes each stage once, agile repeats all of them in short cycles, and a fixed-scope MVP build runs one compressed pass against a scope agreed on day one.

None of these is the right answer everywhere. They are tools that fit different amounts of uncertainty.

Waterfall and where it still fits

Waterfall is the oldest model: requirements, design, build, test, and deploy, each finished before the next begins. It works when requirements are stable and the cost of a late change is high.

Regulated systems, hardware-linked software, and contracts with a fixed deliverable list are the usual cases. If an auditor needs to see an approved specification before any code is written, waterfall gives you the paper trail without extra effort.

The failure mode is well known. You find out the requirements were wrong at the end, when changing them is most expensive. A requirement misread in month one can sit unnoticed through eight months of building.

If you must use waterfall, shorten the distance between a requirement and a working demo of it. Even a rough prototype in the design stage exposes misunderstandings early.

Iterative and agile delivery

Agile runs all the stages in short cycles, commonly two weeks, and ships something usable at the end of each. It suits products where you learn what to build by watching people use it.

The US Government Accountability Office publishes an Agile Assessment Guide for federal programmes, which is a useful sign: even large, oversight-heavy organisations treat iterative delivery as a mainstream option.

Agile has its own failure mode. Without a firm idea of the end state, a team can iterate for a year and produce a pile of features with no coherent product. Someone must own the direction, and that person needs to be able to say no.

Fixed-scope MVP builds

A fixed-scope MVP build compresses the stages into one time-boxed pass. You agree the scope first, build only that, and ship a working product at the end of the window.

This is how our own Moonship offering works: a working MVP in 30 days against a fixed scope. The discipline is in the scoping. Anything that does not fit goes on a list for the next phase, and nothing is added mid-flight without something else leaving.

The trade-off is real. You get a usable product fast and a clear test of the idea, but you give up the flexibility to chase every new thought during the build. For a founder with a tight window and a clear core use case, that is often the right exchange.

An MVP also leaves you with decisions. Some of its shortcuts will need paying down, and the maintenance stage is where that happens.

Where the stages quietly fail

The stages rarely fail loudly. They fail at the joins, where one stage hands unfinished work to the next and nobody notices until the cost shows up.

Three joins cause most of the damage. Requirements to design fails when the requirement could be read two ways. Build to test fails when testers receive something with no description of what changed. Deploy to maintain fails when the people who built the system leave and nobody wrote down how to run it.

The fix is the same each time: make the output of each stage something the next team can check. A requirement with an example input and expected output can be tested. A release with a changelog can be diagnosed.

If you cannot tell which stage a problem started in, add a short written hand-off at each join. It costs a page and saves days.

Security across every stage

Security is a thread through the whole life cycle. It starts with threat thinking in design and continues through dependency updates in maintenance, so testing at the end is too late to be the only line of defence.

NIST's Secure Software Development Framework, SP 800-218, sets out practices grouped by purpose: preparing the organisation, protecting the software, producing well-secured software, and responding to vulnerabilities. They map onto every stage listed above rather than a single security phase.

CISA's Secure by Design guidance makes a similar argument from the vendor side: the supplier of the software should carry the burden of making it safe by default.

In practice, that means a short threat discussion during design, dependency scanning in the build, and a named person responsible for patching after launch.

Choosing a software development life cycle model for a SaaS product

For a SaaS product, an iterative model with a fixed-scope first release is the most common fit. Requirements are uncertain, users arrive gradually, and the software will be maintained for years.

Start with a time-boxed first version covering the one workflow customers pay for. Then run short cycles on what real usage shows. Multi-tenant data design and billing logic deserve more up-front design than the rest, because they are expensive to change once customers are on them.

If you are weighing this for your own product, our SaaS development service covers the full path from first release to ongoing operation. If you have no senior engineer to make these calls, a fractional CTO can own the model choice and the hand-offs between stages.

Finding the stage that is slowing you down

If delivery feels slow, one stage is usually responsible, and it is rarely the one people blame. Developers get blamed for speed when the real delay is an unclear requirement or a release process that takes a week.

Write down, for your last three releases, how long each stage took and where work waited. The longest wait is your answer. That small piece of timing data tells you whether to change the model or just fix one join.

If you want a second pair of eyes on it, the broken workflow assessment looks at how work moves through your delivery process and points to the stage where it stalls. You leave with the specific hand-off to fix first, which is more useful than a new methodology.