How to scope a useful first version of custom software

Custom software is easier to plan when the first release has a clear job. Instead of starting with a list of screens, choose one workflow that currently causes delays, duplication, or mistakes. Describe how it should work from the first input to the final outcome.

Follow the work end to end

Choose a real example: receiving a request, assigning it, collecting information, approving the work, and closing the task. Note who is involved at each step. The first version should handle a complete useful journey, even if it serves a small team initially.

Include the less visible requirements

Permissions, exports, error handling, and recovery can matter as much as the main interface. Record where the data comes from, who may see it, and what happens when an integration is unavailable. Make account ownership and access part of the brief from the start.

Separate essentials from possibilities

• Identify the work needed to complete the chosen workflow.
• List exceptions that must be handled at launch.
• Move convenience features to a later review list.
• Agree on acceptance examples before implementation.
• Include time for testing with the people who will use it.

Plan for learning after release

A first release is an opportunity to observe real use. Collect specific feedback: which step was unclear, what information was missing, or where someone still returned to a spreadsheet. Prioritize the next changes around those findings.

Ask for a clear handover covering documentation, agreed access, support, and how changes will be estimated. The aim is a maintainable tool with a useful starting point, rather than a large feature list that is difficult to finish.