The Complete Custom Software Development Process

Discovery is where a vague business problem — "our dispatch process is chaotic" — becomes a specific, written brief that both sides can hold each other to. That means mapping the current workflow as it actually happens (not as the process document says it should happen), naming every user role that will touch the system, and agreeing acceptance criteria: the specific, checkable conditions that determine whether a feature is genuinely finished.

Imagine a logistics company wanting a fleet-dispatch and delivery-tracking tool. Discovery for that business means sitting with the dispatcher who currently juggles phone calls and a whiteboard, understanding what information they need at the moment they assign a driver, and writing down exactly what "a successful dispatch" looks like in the new system — not assuming it, because the dispatcher's actual workflow rarely matches the org chart's version of it.

This stage should end with a written document both sides sign off on, however informal — because everything that follows gets measured against it, and a disagreement about scope six weeks into the build is far more expensive to resolve than one caught here.

Design translates the discovery document into something concrete: wireframes or a clickable prototype for the interfaces, a data model for how information will be stored and connected, and a technical architecture that accounts for how the system needs to scale and what it needs to integrate with. This is the point where a business person can meaningfully react to what the software will actually look like and feel like to use, before any of it is expensive to change.

Good design at this stage also makes explicit decisions that are easy to skip past: what happens when two dispatchers try to assign the same driver at once, what a partial data sync looks like if the mobile app briefly loses signal, who can see what. These aren't edge cases to defer — they're exactly the kind of decision that's cheap to make on a wireframe and expensive to retrofit into working code.

A well-run build doesn't disappear for months and reappear with a finished product — it delivers working increments on a regular cadence (commonly every one to two weeks) that a client stakeholder actually reviews, not just a status report. This is what makes "we'll see it at the end" the wrong expectation to set: if the dispatch tool's driver-assignment screen is reviewable in week four, a misunderstanding about how it should behave gets caught in week four, not week fourteen.

The review itself only works if the same person attends consistently — a different reviewer each sprint tends to relitigate earlier decisions rather than build on them, which slows the whole process down without improving quality.

Testing checks both that individual features work as specified and that the whole system holds together under realistic use — what happens with a full day's worth of real dispatch volume, not five test records. Migration, where existing data (past deliveries, driver records, customer addresses) moves into the new system, deserves the same rigour: a migration that looks successful because the record counts match can still have silently mismatched or corrupted fields that only surface once someone relies on that data.

Deployment for anything running a live operation should be staged rather than a single cutover moment — running the new system alongside the old process for a short overlap period, so a problem is caught while the old process is still available as a fallback, is worth the extra week it costs.

Software that works technically but that no one was trained to use properly fails in exactly the same way as software with a genuine bug — the business doesn't get the benefit it paid for. Training should be role-specific (what the dispatcher needs is different from what a driver or an ops manager needs) and should happen close enough to go-live that people don't forget it before they use it.

After go-live, changes keep coming — a workflow that looked right on paper turns out to need a tweak once real dispatchers use it daily. A defined, agreed process for requesting, estimating and approving these changes (rather than an open-ended "let us know if anything's wrong") is what keeps the relationship functional in the months after launch.