Field notes.

Writing a brief that gets useful quotes

Describe the people who will use the product and the one task that matters most to them. List what exists already: designs, APIs, data, accounts. State constraints you cannot move, such as a launch event or a regulator, and those you can. Leave out solutions where you are unsure; describing the problem gives a supplier room to suggest something cheaper.

A decision table, not a religion

Choose native when you depend heavily on platform features, need the smoothest possible animation, or have separate teams per platform. Choose cross-platform when features are largely forms, lists and content, and a single team must serve both stores. Consider web first when installation itself is the main barrier. Whatever you choose, budget for platform-specific work: notifications, payments and permissions always differ.

Five checks you can do this afternoon

1. Use the product with keyboard only. Can you see where focus is at every step?
2. Turn on VoiceOver or TalkBack and complete the main task.
3. Set system text size to the largest option and look for clipped text.
4. Check colour contrast of body text and buttons.
5. Make sure errors explain how to fix the problem, not just that one exists.

Budgeting for year two

An app that is not maintained slowly stops working: new OS versions change behaviour, libraries publish security fixes, and stores raise minimum requirements. Plan for regular dependency updates, an annual compatibility round when new iOS and Android versions arrive, and a small reserve for urgent fixes. Ask any supplier, including us, to put this in writing before launch.