Descriptions of the software development process usually list the same stages in the same order and leave the reader knowing nothing they could act on. The stages are not the useful part. What matters is the artifact each stage has to hand to the next, because that artifact is the only way to check from outside whether the stage actually happened.
A stage that produces nothing you can inspect did not happen, whatever the status report says. What follows is each stage described by its output, and by the specific way it fails when it is skipped.
Discovery: produces a scope with an exclusion list
Discovery ends with a written statement of what will be built, in what order, on what timeline, and explicitly what will not be built. The last part carries most of the value. A list of included features is agreeable and constrains nothing, while a list of exclusions forces the disagreements to surface while they are still free to resolve.
Discovery also has to produce a data model, or at least a sketch of one. If nobody can draw the entities in your business and how they relate after a week of conversations, the complexity has not been understood, and it will be discovered later at full price.
Our own discovery runs five to ten days and ends with a statement of work carrying fixed pricing, assumptions, exclusions and risks. Scope is fixed before price, in that order.
Skipped discovery looks like: an estimate expressed in screens, agreement that feels easy, and a first month of building during which the requirements keep changing in ways that surprise everyone.
Architecture: produces the decisions that are expensive to reverse
Architecture is not a diagram. It is the short list of choices that would be costly to change later: where data lives, what the system of record is, how identity and permissions work, and which external systems have to agree with each other.
Most architecture documents fail by describing everything at equal weight. The useful version names the three or four decisions that are hard to undo and says why each was made, so that when one turns out wrong, the reasoning is visible and the cost of changing it can be judged.
Skipped architecture looks like: a system that works until the second user role arrives, then requires rework across every screen.
Build: produces working software in a real environment, continuously
The output of a build stage is not code. It is deployed, running software that someone outside the team can look at, and it should exist within the first week even when it barely does anything.
The reason is that everything genuinely painful about a project lives in the gap between a developer's machine and a real environment. Secrets, permissions, network access, the integration whose sandbox behaves differently from its production, the data that turns out to be inaccessible. Encountering those in week one is a small cost. Encountering them in the final week is what makes projects overrun.
Our builds run two to four weeks with staging in the first week and visible progress every few days. Reusing proven components for authentication, billing, email, background jobs and deployment is what makes that possible, since none of that work is specific to any client.
Skipped continuous deployment looks like: steady progress reports followed by a final phase where the timeline moves repeatedly.
Testing: produces a description of what is now guaranteed
The useful output of testing is a statement of which behaviors are now protected against future change. Test counts and coverage percentages describe effort rather than protection.
The parts worth protecting are the ones where being wrong is expensive and where a person would not notice quickly: money calculations, permissions, anything that writes to an external system, and anything that decides what a user is allowed to see. Interface details rarely justify the same rigor, because a person notices immediately when a button moves.
Skipped testing looks like: the second and third changes to a feature costing more than the first, and eventually a team reluctant to touch working code.
Deployment and handover: produces something someone else can operate
The end of a project is not a demonstration. It is another team being able to run, change and deploy the software without the people who built it.
Concretely: the code in your repository, deployments you control, credentials and accounts in your name, a runbook covering the things that break and what to do about them, and a walkthrough with the people who will inherit it. Our handover is exactly this, and ownership includes the model accounts and prompts as well as the code.
Skipped handover looks like: a working product you cannot change without going back to the people who built it, which is a commercial arrangement rather than an accident.
Operation: produces a decision every month about what changes
Software that stops changing while the business keeps changing becomes an obstacle within a year. The operating stage produces a recurring decision about what to change next, informed by what users are actually doing.
This is also where dependencies get updated and where integrations get repaired when the systems on the other end change, which they do without asking. Retainers for this run $2,000 to $6,000 per month with us, depending on how much the product is still moving.
Why the size of the project matters more than the method
The Standish Group's CHAOS research reports 31 percent of software projects successful, 50 percent challenged and 19 percent failed. Underneath that, small projects succeeded around 90 percent of the time and large projects less than 10 percent.
That gap is larger than the difference any process choice produces. The named success factors were user involvement, executive support and a clear statement of requirements, none of which are methodology and all of which get harder to maintain the longer a project runs.
The practical reading is that choosing a smaller first release does more for your odds than choosing a better process. Process quality matters, and it matters much less than scope discipline.
Frequently asked questions
What are the stages of the software development process?
Commonly discovery, architecture, build, testing, deployment and operation. The stage names matter less than the artifact each produces: a scope with exclusions, the decisions that are expensive to reverse, deployed software, a statement of what is protected, an operable handover, and a recurring change decision.
How long should each stage take?
Our discovery runs five to ten days and builds run two to four weeks, with staging in the first week. Longer discovery is usually a sign that the scope has not been cut, and longer builds usually mean the first release still contains things that could have waited.
Is agile better than waterfall?
The difference between them is smaller than the difference between a large project and a small one, according to the Standish size data. Both work when the scope is small and the people who will use the software are involved. Neither rescues a project that is too big.
What should I receive at the end of a project?
Code in your own repository, deployments you control, accounts and credentials in your name, a runbook, and a walkthrough with whoever will maintain it. Anything less means you own a product you cannot change.
How do I tell if a stage is being skipped?
Ask for the artifact. If discovery is finished, ask for the exclusion list. If the build is underway, ask for the staging URL. A stage with no inspectable output is a stage you are paying for and not receiving.
Where to start
If you are about to commission a build and want the scope settled before the money moves, that is what our audit produces. It starts at $3,000 and the fee is credited toward the build.