Library://

List the users, the three tasks they must complete, what “live” means, a budget ceiling and any fixed dates. Suppliers can respond to that precisely; they can only guess at a vague idea.

Choose native when you need deep hardware access, reliable background tasks, iPhone push notifications or store discovery. Otherwise a progressive web app can be cheaper to build and update.

Look for ranges, stated assumptions, exclusions and a change process. A single precise figure for loosely defined work is a risk indicator.

Short cycles keep feedback cheap. If a cycle produces something unexpected, you lose two weeks of direction at most, not two months.

Decide upfront how heavy a page may be and how fast it must respond on a mid-range phone. Check every release against it rather than optimising in a panic later.

Tab through your main journey. Can you always see focus? Reach every control? Close dialogs with Escape? Each “no” is a defect worth logging.

Normal text needs a contrast ratio of at least 4.5:1 against its background under WCAG AA. Check brand colours early; adjusting tints is cheaper before designs are signed off.

Provide demo credentials, describe hidden features, verify every link and ensure privacy disclosures cover all SDKs. Most avoidable rejections fail on one of these.

Use MAJOR.MINOR.PATCH. Increase PATCH for fixes, MINOR for features, MAJOR for breaking changes. Keep build numbers strictly increasing.

What you did, what you expected, what happened, exact time, device/browser and whether it repeats. Attach a screenshot. Never include passwords.

Auto-renew on, payment card current, registrar notices going to a shared role mailbox, and registrar lock enabled to prevent unauthorised transfers.

When someone leaves, revoke their access to code hosting, cloud consoles, store accounts, DNS and shared vaults on the same day, and rotate any secrets they knew.