✦ Buying, cost and process
The software development process, explained without the jargon
The software development life cycle is the sequence a piece of software goes through from idea to daily use: discovery, design, build, testing, release and ongoing support. Understanding it tells you what you're paying for at each stage and where a project usually goes wrong.
Haystak · 11 August 2026 · Updated 11 August 2026 · 8 min read
The software development life cycle (SDLC) is the set of stages a piece of software passes through: working out what's needed, designing how it will work, building it, testing it, releasing it, and then keeping it running and improving it. Every credible supplier follows some version of this, whether they name the stages or not.
For a business owner signing off a project, the value of knowing the cycle isn't academic. It tells you what should exist before code gets written, what a demo halfway through actually proves, and why a system that seems finished still needs a support budget afterwards.
The stages of the software development life cycle
Different companies use different names, but the substance is consistent. Here's the version we use, and what should exist at the end of each stage.
| Stage | What happens | What you should have at the end |
|---|---|---|
| Discovery | Understanding the problem, the users, the current process, constraints and budget | A written brief or requirements document, agreed scope |
| Design | Screens, data structure, and how the system fits with what you already run | Wireframes or prototypes you've reviewed and signed off |
| Build | Developers write the software against the agreed design | Working software, delivered in stages you can see |
| Testing | Checking it does what was specified, and trying to break it | A test log and a list of fixed defects |
| Release | Moving the system into live use, migrating data, training staff | Live software, staff who know how to use it |
| Maintenance | Fixing issues, applying security updates, small improvements | A support agreement and a backlog of future changes |
The stages aren't always strictly sequential. Depending on the methodology you use, build and testing might run in short repeated cycles rather than as one long block. But the substance of each stage doesn't change.
Why the discovery stage matters more than the build
Most software problems trace back to a discovery stage that was rushed or skipped. If nobody wrote down what the system actually needs to do, testing has nothing to test against, and 'finished' becomes a matter of opinion.
A proper discovery produces a document - sometimes called a software requirements specification - that lists what the system must do, who uses it, and what 'done' looks like for each feature. It doesn't need to be hundreds of pages. It needs to be specific enough that two different developers would build the same thing from it.
How long does each stage take?
This varies hugely with the size of the system, but as a rough shape for a mid-sized business system (say, three to six months end to end):
- Discovery - typically 5–15% of the total timeline. Skimping here costs more later than it saves now.
- Design - 10–20%. Longer if the system replaces something staff already rely on daily.
- Build - usually the largest single share, 40–60%.
- Testing - 10–20%, though it should be happening continuously through the build, not just at the end.
- Release and handover - 5–10%, plus training time that's easy to underestimate.
Maintenance isn't a percentage of the build - it's ongoing. See our guide to software maintenance for what that should include and how it's usually priced.
Waterfall, agile, and why the difference matters to you
The life cycle stages above are the same regardless of methodology - the difference is whether you go through them once, in order, or repeatedly in short cycles. Waterfall does the whole cycle once; agile repeats a compressed version of it every couple of weeks, showing you working software as it goes.
We cover the trade-offs properly in agile vs waterfall, but the short version for a business software project: agile suits most bespoke work because it surfaces misunderstandings early, while waterfall suits fixed, well-understood scopes where change is unwelcome, such as regulatory systems.
What should you actually see at each stage?
As the person signing off the budget, you shouldn't need to read code or test scripts. You should expect to see specific artefacts at each handover point.
- 01After discovery - a written brief you've read and agreed, not a verbal summary in an email.
- 02After design - clickable wireframes or screen mock-ups you can walk through with your own staff before build starts.
- 03During build - working software at regular intervals (weekly or fortnightly), not a single reveal at the end.
- 04After testing - a plain list of what was tested and what was found, not just 'all tests passed'.
- 05After release - a short handover document: how to raise a support ticket, who owns what, and what the maintenance arrangement covers.
Where projects usually go off track
The most common failure isn't bad code. It's scope drifting during the build stage because discovery left gaps, and nobody controlling the change with a proper process. A software development contract worth signing will set out how changes to scope get agreed and costed, so this doesn't happen by accident.
The NIST and ISO bodies both publish standards touching software life cycle processes for organisations that need a formal quality framework (ISO/IEC/IEEE 12207 is the relevant one), but for most businesses the discipline matters more than the paperwork: agree what's being built, show progress often, and control changes in writing.
If you want to see how we run each of these stages in practice, our how we work page sets out the full process end to end. If you're ready to talk about a specific project, get in touch and we'll tell you honestly which stage you need to start at.
✦ Where this fits
More on this from us: how we run a project.