The software development process has three stages: a short written plan, working software delivered early, and support after launch. In practice that breaks into eight steps: describe the problem, agree a written plan, build the riskiest part first, review a working link, repeat in small rounds, test, launch, and keep maintaining what was built.
We build software for clients and we build it for ourselves. About half of what we make, we also run, which changes how you think about process. A step that looks tidy on a diagram and produces nothing you can click on does not survive long when you are the one waiting for the product.
So our process is short. It has three stages: a written plan, working software early, and staying on after launch. Everything below is those three stages broken into the steps you will see as a client.
None of this is exotic. The value is in doing the dull steps every time, including the ones that are tempting to skip when a deadline is close.
What are the stages of the software development process?
The software development process has three stages: planning, building, and running. Planning produces a short written plan with a fixed scope. Building produces working software you can use from the first weeks. Running covers hosting, monitoring, fixes, and new features after launch. Each stage ends with something you can read or click.
That last point is the test we apply to any process. If a stage ends with a meeting and nothing else, it was not a stage. A plan is a document. A build is a link. Running is a system that stays up and a person who answers.
What are the steps, in order?
A typical build runs through eight steps: describe the problem, receive a written plan, agree on scope, see a first working version, give feedback in rounds, test, launch, and maintain. The first three are planning, the next three are building, and the last two are running.
- You describe the problem. Not the solution. "Our staff retype the same client details into four documents" is more useful than "we need a portal".
- We reply with a short written plan. What we would build, what we would leave out, what it costs, and how long it takes. One page, plain language.
- We agree on scope. The plan is fixed once both sides accept it. Changes after that are welcome, and they are handled as changes, not absorbed quietly.
- You get a working link early. In the first week or two you can click on something real. It will be rough.
- You tell us where we got it wrong. Short rounds of build, review, and correction. We wrote a separate guide on how to give feedback to developers so this step goes quickly.
- We test. Automated checks on every change, and a person using the thing the way a customer would.
- We launch. Domain, redirects, forms, and monitoring are checked on the day, not assumed.
- We stay. Hosting, monitoring, fixes, and the next feature.
Why start with a written plan instead of a long specification?
A short written plan is better than a long specification because people read it. One page forces a decision about what matters, names what is out of scope, and gives both sides something to point at later. Long specifications are often signed without being read, then contradicted by the first working version.
The most useful line in a plan is usually in the "leave out" section. Deciding that a feature waits for a second phase is what keeps the first phase deliverable. We cover that in more detail in our post on how to prevent scope creep.
Larger projects sometimes need more than a page before anyone can commit to a number. That extra work has a name, and we explain it in what a discovery phase is.
Why show working software so early?
Showing working software early finds misunderstandings while they are cheap to fix. A client who clicks through a rough version in week two will notice a wrong assumption that no document would have exposed. The same mistake found a month later has other work built on top of it.
We learned this on our own products. CaseCobra is practice management software for criminal defense firms, and its motion engine is the descendant of a smaller internal tool. That tool assembled court filings from case data, and it worked well enough that we rebuilt it as a native part of the larger product. A small version in real use showed what was worth building properly.
An early link also changes the conversation. Feedback on a screen is specific. Feedback on a description is a guess about what the description means.
How is the software tested before launch?
Software is tested before launch with automated checks that run on every change and with manual review by a person. Automated checks catch code that breaks existing behavior. Manual review catches things that work correctly and still confuse a customer. Both are needed, and neither replaces the other.
On CoverageCobra, our marketplace for court appearance coverage, a change cannot be merged until type checks, lint, the test suite, and a full build all pass. That rule is enforced by the tooling, not by memory. There is more on this in how software is tested before launch.
What happens after the software launches?
After launch, software needs hosting, monitoring, fixes, and continued development. Something will break that nobody predicted, a customer will ask for a feature that makes obvious sense, and the services your software depends on will change. Launch is the start of the period in which the software earns its keep.
This is the stage most often left out of a quote. Ask about it before you sign with anyone: who hosts it, who gets the alert when it fails, and how fixes are requested. We would rather the people answering be the people who wrote the code, which is why we stay.
Frequently asked questions
Do I need to be technical to work through this process?
No. Your job is to know your business and say plainly what is wrong with the thing in front of you. The plan is written in plain language, and reviews happen on a working link, not in code.
Is this agile or waterfall?
It borrows from both. The scope is written and agreed up front, which is closer to waterfall. The build happens in short rounds with working software at each one, which is closer to agile. The labels matter less than having both a plan and early feedback.
How much of my time will a project take?
Expect the most involvement at the start, when the plan is written, and at each review round. Between rounds there is usually little for you to do. Slow feedback is the most common cause of a slow project, so quick replies matter more than long meetings.
What should I prepare before the first conversation?
A description of the problem, who has it, and what they do about it today. Examples help: the spreadsheet, the form, the email that gets sent by hand. You do not need a feature list.
Can the plan change once work has started?
Yes. A change gets written down, sized, and either swapped for something else or added to the cost and timeline. What should not happen is a change that nobody recorded.
If you have a problem you can describe in a paragraph, that is enough to start. Send it to us and we will reply with a plan.