What is the software development life cycle?
The software development life cycle, often shortened to SDLC, is the sequence of stages a piece of software passes through from the first idea to the day it is retired. Every description you will find online lists roughly the same steps: plan, design, build, test, release and maintain. Most of those descriptions are written for students or for engineers.
This one is written for the person commissioning the software. If you are a business owner reading a proposal, a founder choosing an agency, or an operations manager asked to "sign off" on something, the useful question is not what the textbook says each stage is. It is what you have to decide, what you should receive, and what usually goes wrong at that point.
We build custom software, websites and automations, so some of this describes our own process. We will say where we are describing ours and where we are describing the general picture, because agencies differ and you should be able to tell the difference.
A short note on honesty: no life cycle model guarantees a good result. The stages are a way of making risk visible early, when changing your mind costs little, instead of late, when it costs a lot. That is the whole point of them.
What are the stages of the SDLC?
Different sources split the cycle into five, six or seven stages. The naming varies, the substance does not. Here is the version we use when we explain a project to a client.
- Discovery and planning. Understanding the problem, the people involved and the constraints. The output is a clear scope.
- Requirements and design. Turning the scope into specific behaviour, screens, data and architecture. The output is something you can react to before code exists.
- Development. Building the product, usually in short cycles. The output is working software you can use.
- Testing. Checking that it works, that it is secure enough and that it does what the business needs. The output is evidence, not an opinion.
- Deployment. Putting it on real infrastructure with real accounts and real users. The output is a live product.
- Maintenance. Keeping it secure, working and relevant. The output is a product that is still useful a year later.
Government digital teams use a similar shape under different names. The GOV.UK Service Manual describes discovery, alpha, beta and live phases, with each phase designed to reduce a specific kind of risk before more money is committed. The vocabulary is different but the logic is the same: learn cheaply first, build expensively later.
What does the client do at each stage?
This is the part most guides leave out, and it is where most delays begin. Here is what is typically asked of you, stage by stage.
Discovery and planning
You explain how the work happens today, including the awkward parts nobody has written down. Who enters the data? Where does it go wrong? Which spreadsheet is the real one? A good team will ask to watch the process, not only hear it described, because people describe the intended process and perform the actual one.
You also decide the outcome you want. "A better system" is not an outcome. "Cut the time to produce a monthly report from two days to two hours" is one. You name the person who can say yes or no on your side. Projects with three people who each can say no move slowly.
What you should receive: a written scope, a list of what is deliberately left out, a timeline in phases and a clear statement of how changes are handled. If you are comparing proposals, our guide to comparing software development quotes explains how to read the differences.
Requirements and design
You review designs and say what is wrong with them. This sounds easy and is not, because people are often better at spotting problems in a working screen than in a drawing. A good design stage gives you clickable screens or a prototype so your feedback is based on something you can touch.
You also confirm the rules. Who can see what? What happens when a payment fails? Who approves a refund? These rules are cheap to settle on paper and expensive to discover in code.
What you should receive: designs or a prototype, a list of the main features with plain-English descriptions, and a view of the technical choices, including where the software will run and who will own the accounts.
Development
In an agile project you see progress every week or two. In a traditional project you may see nothing for weeks and then a lot at once. Neither is automatically better, but the first makes problems visible earlier.
Your job during the build is to be available. Questions come up daily: what should happen if a customer has two phone numbers? Teams that can get an answer within a day move at full speed. Teams that wait a week for each answer stall.
What you should receive: a working build you can click through, a short progress report each week, and a running list of what is done, what is in progress and what has moved. We run our builds in sprints with a weekly demo so you are looking at real software, not a status slide.
Testing
Two kinds of testing happen, and clients often only know about one. The developer's team tests that the software works: no crashes, no broken calculations, no security holes. You then test that it does the job: can the person at the front desk actually complete a booking in under a minute? That second check is called user acceptance testing, or UAT. If you have been asked to "do UAT" and are not sure what that involves, our explanation of what UAT is in software development walks through it.
What you should receive: a list of what was tested, the issues found and how they were resolved, and a clear definition of what "accepted" means for payment and handover.
Deployment
The software moves from a test environment to the real one. Data is migrated, accounts are connected, users are trained and the old way of working is switched off or run in parallel for a short time. This is the stage where small details matter: who has the admin login, where the backups go, what happens if the site goes down at night.
What you should receive: a live product, documentation, training, and the accounts for hosting, the domain and any third-party services registered in your name. The ownership question is easier to settle at the start than at the end.
Maintenance
Software that is live is never finished. Operating systems update, libraries get security fixes, laws change and your business changes. Maintenance is not a sign that something was built badly; it is the normal cost of owning software. Ask what the support period covers, how fast critical issues are handled and what happens after the period ends. Our note on what support startups need after launch covers what a sensible plan includes.
Waterfall, agile or V-model: which suits a fixed budget?
The "model" in an SDLC model is the order in which the stages happen. Three come up most often.
Waterfall
Each stage finishes before the next begins: all the requirements first, then all the design, then all the code, then all the testing. It is easy to understand and easy to price, because everything is specified up front. Its weakness is that you learn whether the software is right only at the end, when it is expensive to change.
Waterfall works well when the requirements really are known and stable, such as a regulated process that must follow a fixed specification.
Agile
Work happens in short cycles, often one or two weeks. At the end of each cycle there is something working to review. The plan changes as you learn. The Agile Manifesto states the preference as working software over comprehensive documentation and responding to change over following a plan.
Agile works well when the product is new, the users are unsure what they need and the best way to find out is to put something in front of them. Its weakness for buyers is that "we will adapt as we go" can sound like an open-ended bill. A fixed-scope, fixed-price agile project resolves that: the scope is agreed, the build runs in sprints, and a change to scope is priced before it starts.
V-model
The V-model is a variant of waterfall in which every design stage is paired with a testing stage: requirements are matched with acceptance testing, system design with system testing, and so on. It is popular where proof of testing matters, such as medical, automotive or safety-related software.
Which should you choose?
For a business building an internal system or a first product, a blend usually wins. Agree the scope and budget up front, as in waterfall, so you know what you are paying for. Then build in short cycles with real demos, as in agile, so surprises appear in week two rather than month five. If your industry demands formal test evidence, borrow the V-model's pairing of each requirement with a matching test.
The model matters less than whether the team shows you working software regularly and tells you early when something is slipping.
How long does each stage take?
There is no honest universal figure, because the answer depends on how complicated your process is, how many people use the software and how quickly decisions are made. What we can give is the shape we plan around for a focused custom build: one to two weeks understanding the real workflow, including the undocumented steps people do from memory; about two weeks on architecture and interface design; four to eight weeks of build in sprints with a weekly demo; then a week of launch, documentation and training. Larger systems extend the build stage most.
A first product is usually shorter and narrower. For what that looks like, see our answer on how long it takes to build an MVP.
Be cautious of any estimate that does not mention your own time. Reviews, test data, access to systems and sign-offs all sit on your side of the clock. A project that needs a decision within two days will take twice as long if decisions take four.
Where do software projects usually go wrong?
Most failures are not technical. They come from a small set of repeating patterns.
- A vague scope. "A portal for customers" can mean ten screens or a hundred. Write down what is in and what is out.
- Late feedback. If the first time the real users see the software is the final week, every problem is expensive.
- Changing scope without changing the plan. Adding features is fine. Adding them without re-pricing and re-dating the plan is how budgets double quietly.
- Testing squeezed at the end. When the build runs late, testing is the stage that gets cut. Insist on a fixed testing window.
- No owner on the client side. If nobody can approve decisions quickly, the team waits.
- Skipping maintenance planning. The software launches, nobody owns it and six months later a security update breaks something.
- Building the whole thing before checking anyone wants it. This is the reason a first version should be small, and why it helps to validate the idea before commissioning a build.
A useful habit is to ask, at the end of every stage, "what would make us stop or change direction now?" Teams that ask this out loud catch problems while they are still cheap.
What should you receive at handover?
At the end of the project you should hold everything needed to keep the software running without the team that built it. That list is short, and worth writing into the contract.
- The source code, in a repository registered to you, with its history.
- The accounts: hosting, domain, databases, email and any third-party services, in your name.
- Documentation: how to run it, how it is deployed, where each secret and key lives, and who to call.
- Training for the people who will use and administer it.
- A written support period, with what it covers and how problems are reported.
- A list of known issues and a short roadmap for the next version.
If any of these is missing, you are renting the software, not owning it. The best time to discover that is before the contract is signed.
What happens after launch?
Launch is the beginning of learning, not the end of the project. Real users behave differently from test users. The first weeks show which features matter, which are ignored and which confuse people. Plan a short review a month or two after launch to look at what the software is actually doing for the business and decide what to change.
Maintenance has three parts. Corrective work fixes defects. Adaptive work keeps the software running as its environment changes, such as new browser versions, new payment rules or updated libraries. Improvement work adds or changes features. Support plans usually cover the first two and price the third separately, which is a sensible split as long as you know where the line is.
Support periods vary with the size of the build. We typically agree a period of a few months for a small first product and up to twelve months for larger custom software, and we write down what is included. Whatever a vendor offers, get the length, the response time and the scope in writing.
A simple checklist for the next proposal you read
When a proposal arrives, you do not need to read the technical sections to judge it. Check these instead.
- Does it describe phases, with what you receive at the end of each?
- Is there a written scope with an explicit list of what is not included?
- Will you see working software regularly, not just a final delivery?
- Is there a dedicated testing stage and a clear definition of acceptance?
- Does it say who owns the code and accounts?
- Is the support period stated, along with what it covers?
- Does it say how changes are requested, priced and scheduled?
A proposal that answers these clearly has probably been written by a team that has delivered before. One that answers none of them is asking you to trust it on faith.
If you are weighing agencies, our guide on how to choose a custom software development company covers the wider questions, and our custom software service page shows how we work.
The short version
The software development life cycle is not a technical ritual. It is a way of splitting a large, uncertain piece of work into stages where each one reduces a specific risk. As the client, your part is to make decisions quickly, test with real tasks and insist on seeing working software early. The team's part is to make risk visible and to tell you the truth when the plan changes.
Pick a model that fits your uncertainty, ask for the six handover items, and keep a named person on your side who can say yes or no. Those habits do more for a project than any choice between waterfall and agile.
