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. If you can fit it on a sticky note, better still.
2. Name the users
List the types of people who will use it: office staff, engineers on site, customers, suppliers. Each type often needs a slightly different view, so it is useful to spot this early. If you cannot name five specific people who will log in on day one, the project is probably not ready.
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. Think single workflow, one user type, one screen that matters.
4. Decide where the data lives
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. Pick a system of record for customers, for orders, for invoices. Everything else keeps in sync with it.
5. Avoid the feature list trap
- Resist adding "while we are at it" features in the first version
- Park nice-to-haves in a separate list, dated so you do not forget them
- Ship, use it for two weeks, then review with 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 per day. That is how you know it worked, and that is how you know when it is time to invest in version two.
7. Write a one-page scope, not a spec
A good developer does not need 60 pages. One page that covers the problem, the users, the first-release feature list, the system of record, and the success measure is plenty. If the developer asks for more, they probably have not read the page yet.