The software development lifecycle is the sequence of stages a software project moves through, from first idea to ongoing use. It usually covers discovery and planning, requirements, design, build, testing, deployment and maintenance, giving a project a clear, repeatable shape that everyone involved can follow.
What the software development lifecycle is
The software development lifecycle, often shortened to SDLC, is simply the path a piece of software follows from an idea in someone's head to a working tool people use every day. It breaks that path into named stages, so a large, hard-to-picture undertaking becomes a series of smaller, understandable steps.
It is a structure, not a piece of technology. The international standard for software life cycle processes, ISO/IEC/IEEE 12207, sets out a common framework precisely so that buyers, suppliers and developers share one vocabulary for the work. A good supplier will be able to tell you, in plain words, which stage your project is in and what comes next.
For a non-technical buyer, that shared structure is the point. You do not need to write code to commission software well, but you do need to know the shape of the journey you are paying for.
The stages of the lifecycle
The exact names differ between suppliers, but most lifecycles cover the same seven stages in roughly this order. Each one is a topic in its own right, and several have their own Eaglepedia entry.
- Discovery and planning: the early stage where the supplier learns your business, your goals and your constraints, and the project's purpose and rough scope are agreed. See the discovery phase.
- Requirements: turning "what we want" into a clear, written list of what the software must do and how well it must perform. See functional vs non-functional requirements.
- Design: deciding how the software will be built and how it will look and behave, including screens, data and the technical structure underneath.
- Build: the development work itself, where the agreed design is turned into working software by the engineering team.
- Testing: checking the software does what it should and is reliable, including the final check you carry out yourself. See user acceptance testing (UAT).
- Deployment and launch: releasing the finished software so real users can use it, and handing it over to your team.
- Maintenance and support: the ongoing work that keeps the software secure, working and useful after launch. See software maintenance and support.
Some suppliers add a discovery proof of concept before the main build, to test a risky idea cheaply first. Our entry on what a proof of concept is explains when that is worth doing.
Agile and Waterfall: two ways through the lifecycle
The stages above describe what happens. They do not say in what order, or how many times, those stages run. That is decided by the delivery method, and the two best-known are Waterfall and Agile.
Put simply, Waterfall runs the stages once, in a straight line: finish requirements, then design, then build and so on. Agile repeats short cycles, each one a small slice of the whole lifecycle, so working software appears early and often. The UK government's Service Manual sets out how public-sector teams deliver digitally using an agile, iterative approach.
The choice affects how you see progress, how change is handled and how the work is priced, so it is worth understanding before you commission. Our buyer's guide to Agile vs Waterfall explains how the stages are sequenced under each, and which suits which kind of project.
Why the lifecycle matters to a non-technical buyer
Knowing the stages turns a software project from something that happens to you into something you can follow and steer. At any point you can ask which stage the work is in, what that stage should produce and whether it is on track. That is real control, and it does not require a technical background.
The lifecycle also tells you when to do your part. Requirements is when your input shapes the build most cheaply; testing is when you must check the software against what you asked for; maintenance is the cost that continues after launch. Knowing this helps you spend attention and budget where they count.
It also makes risks easier to spot. When new requests keep arriving after the requirements stage is signed off, that is scope creep, and recognising it early is far cheaper than discovering it at launch. A clear lifecycle gives every stage a defined end, which is what makes sign-off and payment fair to both sides.
A clear process is what a good supplier gives you Understanding the lifecycle helps you ask the right questions; working with a supplier who follows one openly is what makes a project predictable. Our bespoke software development service walks you through every stage in plain English, from discovery to long-term support, so you always know where your project stands.
