Every custom software engagement we take on begins the same way: we sit with the people who do the work and watch what actually happens, rather than what the process document says happens.
The workaround is the requirement
The most valuable thing in any discovery session is the workaround. When somebody keeps a spreadsheet alongside the system they were given, that spreadsheet is a specification nobody wrote down. It tells you precisely where the official tool stopped being useful.
We collect those, and they usually become the backbone of the first release.
What the first release has to prove
A first release is not a smaller version of the finished product. It is an argument. It should prove the single most contested assumption in the project, and it should do it with real users and real data.
- If the assumption is that people will adopt a new flow, the release has to put the new flow in front of them.
- If the assumption is that the data is clean enough, the release has to run on the real data.
Then it has to be maintainable
Discovery, engineering and support sitting with one team is not an organisational preference. It is what keeps the reasoning intact. Decisions made in week one are still understood in month twelve, and that is what separates a custom build that ages well from one that becomes a rewrite.