1. Start with the pain, not the solution
Write down the process you want to replace. Who does it, how often, and where it breaks. A sharp description of the problem is worth more than a long list of features.
2. Name the users
List the types of people who will use it: office staff, fitters on site, customers, suppliers. Each type often needs a slightly different view, so it is useful to spot this early.
3. Pick the smallest useful first version
The version your team will pilot is nearly always smaller than you first think. Aim for the least you can build that still saves real time on day one.
4. Make one key decision: where does the data live?
If you already use spreadsheets, accounting software, or a CRM, plan how the app talks to them. Duplicated data across tools is the classic reason projects stall.
5. Avoid the feature list trap
- Resist adding "while we're at it" features in the first version
- Park nice-to-haves in a separate list, dated so you don't forget them
- Ship, use it for two weeks, then review with the real experience in hand
6. Decide how you will measure it
Before the build starts, pick one thing the app should change: time saved per week, errors avoided, enquiries handled. That is how you know it worked.