Take a leaflet.

Write down the single job your first version must do, the person it does it for, and how you will know it worked. Anything that does not serve those three lines goes into a 'later' list. Most first versions need sign-in, the core journey, a way to get help and nothing else.

Choose web when you need reach and fast iteration; cross-platform when you need store presence on both platforms at reasonable cost; native when performance, hardware access or platform-specific polish is the product. Changing later is possible but expensive, so decide with your next two years in mind.

Support dynamic text sizes, give every control a screen-reader label, keep contrast at WCAG AA or better, never use colour alone to convey meaning, and make touch targets at least 44 by 44 points. Test with VoiceOver and TalkBack before launch, not after.

Your first two screenshots do most of the work. Show the core benefit in plain words, keep the description honest, and match the privacy declarations precisely to what the app and its SDKs collect. Mismatches are a common cause of rejection.

Plan for ongoing costs: annual developer accounts, hosting, third-party services, and time each year to update for new iOS and Android releases. A rough rule many teams use is to set aside a meaningful share of the build cost per year for maintenance — ask us to estimate yours.

If your app handles personal data you are usually the controller. Know what you collect and why, publish a clear privacy notice, get consent where PECR requires it (for example non-essential cookies or similar storage), and choose processors with suitable contracts. The ICO website has practical guidance for small organisations.