Software development process stages are usually listed as requirements, design, build, testing, deployment, and maintenance, in that order, as if each one gets equal attention on a real project. In practice, one stage is the one most commonly compressed or skipped entirely, and it's also the one whose absence costs the most once the software is live. This guide covers the stages as they're supposed to run, the one that quietly doesn't, and why that gap costs more than it looks like at the time.
Software Development Process Stages, Listed
The classic list: requirements through maintenance. The classic academic list of software development process stages runs requirements, design, build, testing, deployment, and maintenance. It's accurate as far as it goes, and it's also written for software in general, not for a project one business commissions from an outside team.
Burhani's actual sequence: discovery, scope and quote, design, build and review, integrate and release, support. Our actual application development sequence runs a little differently: discovery, scope and quote, design, build and review, integrate and release, and support. The steps in software development cycle terms are similar, but the commercial reality- a scope has to be agreed and quoted before anything gets built- changes the order and the emphasis. These SDLC stages exist inside a real engagement, not a diagram, and the difference matters more than it looks on paper.
Why the two lists don't quite match. The classic list describes what happens to the software. Burhani's sequence describes what happens between two parties, a client and an engineering team, who need to agree on scope, cost, and acceptance criteria before the classic stages can even start. Neither list is wrong. They're answering slightly different questions, and conflating them is part of why so many generic software development steps articles feel disconnected from how a real commissioned project actually runs, leaving a founder to work out the commercial side on their own.
The One Most Companies Skip, and Why It's Expensive to Skip
Discovery gets compressed most often because it produces no visible output. No screens. No working code. Just questions, and questions don't feel like progress to someone waiting for a demo. That's a human bias, not a technical one, and it shows up on almost every project that runs into trouble later, regardless of how experienced the team building it is.
That instinct is expensive. Boehm and Basili's peer-reviewed finding shows that fixing a problem after delivery is often around 100 times more expensive than catching it during requirements and design on large projects, closer to five times on smaller ones. Skipping discovery doesn't remove that cost. It moves it later in the project and multiplies it.
What discovery actually protects against. The mid-project scope changes that derail a timeline almost always trace back to something discovery would have caught: a workflow nobody mapped, an existing system nobody asked about, a stakeholder whose requirements never made it into the brief. None of these is the classic software development steps most guides talk about- requirements, design, build- but they're exactly what discovery exists to surface before the more visible stages begin. A day spent in discovery asking an uncomfortable question is almost always cheaper than a week spent rebuilding around the answer later.
Stage by Stage: What Each One Requires, and What Gets Skipped
Here's what each stage actually requires, and what tends to get cut when time is short.
Discovery
What it actually requires: Mapping the current workflow, the people involved, existing systems
What gets skipped, and the cost: Skipped as a formality; costs show up as mid-project scope changes
Design
What it actually requires: Deciding the data model, interface, and integration points
What gets skipped, and the cost: Skipped by building before decisions are settled; costs show up as rework
Build and review
What it actually requires: Working software reviewed as it's built
What gets skipped, and the cost: Skipped by deferring all review to one acceptance test; costs show up as a late batch of fixes
Testing
What it actually requires: Testing against the actual workflow, not just the code
What gets skipped, and the cost: Skipped by testing only the happy path; costs show up as production issues
Deployment
What it actually requires: A defined release and rollback plan
What gets skipped, and the cost: Skipped by treating deployment as an afterthought; costs show up as downtime
Maintenance
What it actually requires: An agreed plan for fixes, updates, and support
What gets skipped, and the cost: Skipped by assuming the project ends at launch
Reading the table as a whole. Every row after discovery describes a cost that shows up later. That's the pattern worth noticing: almost none of these software development process stages fail loudly in the moment they're skipped. They fail quietly, weeks or months downstream, in a way that's easy to blame on the wrong stage entirely. A production issue traced back to untested edge cases often actually started as a discovery gap nobody connected to the outcome.
Where Iteration Fits
Iteration inside a stage vs. iteration across stages. Iteration isn't really a separate stage on this list. It's a way of moving through design, build, and test in smaller loops instead of one long pass. Reviewing working software early, before every feature is finished, catches a wrong assumption while it's still cheap to fix, which is the same logic that makes discovery worth protecting in the first place. A team that iterates well but skipped discovery is still just iterating toward the wrong target, faster.
Where iteration doesn't help. Iterating faster through build and test doesn't compensate for a discovery stage that was skipped. A team can run the tightest two-week sprints in the world and still build the wrong thing quickly if nobody mapped the actual workflow first. Iteration improves how well the later software development process stages run; it doesn't replace the earlier one.
Where Burhani Fits
Our actual sequence is discovery, scope and quote, design, build and review, integrate and release, and support. Timelines get agreed per project rather than promised as a universal schedule, since a five-screen tool and a system replacing three existing processes don't take the same number of weeks, and pretending otherwise upfront just sets up a disappointing conversation later.
get in touch before the next stage starts.
FAQs on Software Development Process Stages
Straightforward answers to the questions people actually search for around software development process stages.
What are the stages of software development?
The classic stages are requirements, design, build, testing, deployment, and maintenance. A commissioned project typically follows a related but distinct sequence: discovery, scope and quote, design, build and review, integrate and release, and support, shaped by the fact that a scope has to be agreed before work starts.
What is the difference between the classic SDLC and how a real project runs?
The classic SDLC describes software development stages in general. A real, commissioned project adds commercial steps around them, scoping and quoting before design, review built into the build stage rather than saved for the end, and an agreed support plan rather than an assumed one. The difference isn't cosmetic; it changes when money and decisions actually get committed.
Why does the discovery stage get skipped so often?
Discovery produces no visible output, no screens or working code, just questions and a mapped-out workflow. That makes it easy to compress under time pressure, even though the cost of a decision made without proper discovery tends to be far higher than the time discovery would have taken. The visible stages get protected precisely because they're visible; discovery has to be protected deliberately, since nothing about it defends itself.
What happens if testing only covers the happy path?
Testing only the happy path means the software gets tested on how it's supposed to be used, not how it's actually used. Edge cases, unusual data, and real user behaviour surface after launch instead, usually as production issues that are more disruptive and more expensive to fix than the same issue caught during testing, and harder to reproduce once real users are involved instead of a clean test script.
How long does each stage take?
There's no universal answer. A stage's length depends on the size and complexity of the project, and an agreed, dated plan for a specific engagement is more useful than a generic timeline that doesn't reflect what's actually being built. Anyone offering a fixed number before discovery has happened is quoting a guess, not a plan.
The Bottom Line
These stages aren't followed evenly in practice, and discovery is the one worth protecting. Skipping it doesn't save time. It moves the cost later and makes it bigger, and by the time that cost shows up, it's usually mislabeled as a design problem, a testing gap, or bad luck, instead of what it actually was.
Talk to our team about the current workflow and what's already built, before deciding how much discovery your project actually needs to protect.
