CodeMaster / 23 September 2026
Before building a system, name the problem.
The best place to start is not a feature list. It is understanding the work that currently takes too much effort.
Start with an ordinary working day
Follow one process from beginning to end. Who starts it? Which data is required? Where is the same information entered twice?
Separate the problem from the first idea
“We need an app” is a proposed solution. “We cannot tell which document is current” is a problem that can be investigated.
Make the direction tangible
A demonstration lets the team discuss specific behaviour before committing to the full build.
Agree on what done means
Scope should include permissions, data, integrations, errors, deployment and acceptance, not just screens.
Evaluate the result, not the feature count
The useful question is whether work became easier and more reliable.