The software development process, step by step

The software development process steps

Names vary from one team to another, but almost every project goes through these phases, in this order:

1. DiscoveryUnderstand the business problem, the people who will use the software, the current process and what success looks like.
2. RequirementsWrite down what the software must do: features, rules, users, data, integrations and anything it must not do.
3. DesignPlan the screens and flows, usually as clickable mockups, and the technical structure behind them.
4. DevelopmentBuild the software, ideally in short rounds that produce something you can log into and review.
5. TestingCheck that everything works as written, on the devices and browsers people use, with realistic data.
6. LaunchMove real data in, train users, set up hosting and monitoring, and switch on.
7. Maintenance and improvementFix issues, keep everything updated and secure, and add changes as the business learns.

The discovery phase in software development

Discovery is the step people are most tempted to skip, and the one that saves the most money. It is a short period, often a few days to a few weeks depending on the size of the project, where the team learns how your business works before deciding what to build.

Good discovery usually includes interviews with the people who will use the software, a walkthrough of the current process including spreadsheets and workarounds, a list of the systems the software needs to connect to, a rough priority order for features, and a first estimate. The output is a written summary you can read and correct. Some teams charge for discovery separately, which is reasonable, since the results are useful even if you choose a different builder.

Waterfall, agile and what most teams actually do

• Waterfall: each phase is finished before the next starts. Predictable on paper, but you see working software late, and mistakes in early phases are expensive to fix.
• Agile: the work is split into short cycles, often one to two weeks, each producing working software. You see progress early and can change priorities, but the final scope is less fixed.
• In practice: most small and mid-sized projects mix the two. Discovery, requirements and design are done up front so the big picture is clear, then development and testing happen in short rounds you review.

Your role as the business owner

• In discovery: explain how the business really works, including the messy parts.
• In requirements: read the written scope carefully and say what is missing or wrong.
• In design: click through the mockups with the people who will use the software, and give feedback before code is written.
• In development: review each round promptly and keep one person as the decision-maker.
• In testing: try it with real scenarios and data, not just the happy path.
• At launch: make time for training and for running old and new side by side if needed.
• After launch: keep a list of what works, what does not and what you want next.

Where software projects usually go wrong

• Skipping discovery and finding out halfway through that the software does not match the process.
• Requirements that live in someone’s head or a chat thread instead of a shared document.
• No design step, so the first time anyone sees the screens is after they have been built.
• Months of building with nothing to review, then a big reveal that misses the mark.
• Testing squeezed in at the end because the build ran late.
• Launch treated as the finish line, with no plan or budget for upkeep.

How long each phase takes

Timing depends almost entirely on the size of the project, so be wary of anyone who quotes it without understanding your needs. As a rough pattern, discovery, requirements and design together often take a fraction of the total time, development takes the largest share, and testing runs alongside development rather than only at the end. Maintenance continues for as long as the software is in use. Spending more time early usually shortens the expensive middle.