If you have never commissioned software before, the process can feel deliberately opaque. It is not complicated. It is four stages, and most failures happen because one of them was skipped.
A. Discovery#
We sit with the people who will actually use the system, not only the person paying for it.
This matters more than it sounds. The person buying software describes the process as it is supposed to work. The person doing the job every day knows the exceptions, the local rules, and the workaround that exists because the official process does not fit reality.
Off-the-shelf software makes you change your process to fit the product. Custom software should do the opposite. That is only possible if discovery captured the exceptions.
Output: a requirement document you can read and disagree with.
B. Design#
Wireframes and a clickable prototype, before a line of production code exists.
The purpose is to make disagreement cheap. Changing a screen in a prototype takes minutes. Changing it after the database, the API and the front end have been built takes days and touches three things.
Output: wireframes, a clickable prototype, and a design system.
C. Build#
Short cycles, with something working to look at at the end of each one.
The failure mode here is the long silence: three months of "it's going well" followed by a reveal that does not match what anyone expected. Frequent demos are not a formality. They are how you catch a misunderstanding while it is still small.
Output: working software, deployed somewhere you can use it.
D. Handover#
This is the stage most often treated as an afterthought, and it is the one that decides whether you own the result.
Handover should include:
- Source code in your repository
- Architecture diagram and database schema
- Environment setup guide and deployment runbook
- An admin user guide and a training session
- A warranty period on defects
- A named engineer who knows the system
Where projects actually go wrong#
In our experience, in roughly this order:
- Scope was never written down. Everyone agreed verbally, and everyone remembered something different.
- Discovery only talked to management. The system does not match how the work is done.
- No demos until the end. A small misunderstanding compounded for months.
- Handover was assumed. The software works, but nobody outside the vendor can maintain or deploy it.
- Running cost was never discussed. The build was affordable; operating it was not.
None of these are technical problems. All of them are avoidable by agreeing things in writing early.
If you want to talk through what this looks like for a specific project, describe the problem and we will tell you which parts apply.