In this guide 6 sections
An app moves through discovery, design, build, testing, store review, release and updates, and at each step you owe decisions, sample data and a signed approval. Slow coding is rarely the cause of delay. Late answers, a store rejection and skipped staff testing usually are.
Discovery decides what the first version contains
Discovery is a few workshops ending in a written scope that names each user role, the tasks it must finish and the records the app reads or writes. Be concrete. Bring real order forms, price sheets and screenshots of the chat threads where work happens today.
Then cut hard. Six screens that people open daily beat thirty screens that nobody trusts. Mark each feature as needed on day one, useful later or only a wish, and accept that your main job in this phase is saying no to the rest.
- Named user roles, such as storekeeper, approver and driver
- Sample files: invoice PDFs, order sheets, customer CSV exports
- Systems to read from or write to, such as an accounting package or payment gateway
- Phone models and Android and iOS versions in use
- One named person who approves each stage
Design shows you the app before anyone builds it
Designers sketch each screen as a wireframe, then join the wireframes into a storyboard and a clickable prototype. Open it on your own phone. Tap through one real task, like raising a purchase order, and note every spot where your thumb hesitates or a label confuses you.
Put the prototype in front of three or four daily users, not just managers. A packer will spot a missing barcode field in seconds. Fixing it now costs an afternoon. Fixing it after the build costs a whole sprint, a retest and an awkward conversation about who pays.
Build runs in short cycles you can inspect
A sound team delivers a working slice every two weeks. You install a beta build through TestFlight or an Android internal track, try the login, the list screen and the first form, then reply in writing. Slow replies stall everything.
The API, the admin panel and the app are built side by side. Ask where the staging server lives, who holds the Git repository, how push notifications will be wired through Firebase and which deeplink opens which screen. Settle these early. Moving them later is slow, tedious and expensive in goodwill.
- A TestFlight build or Android APK every cycle
- A demo loaded with your real product list, not lorem ipsum
- An open-questions list with a named owner for each item
- Change requests written down, not buried in chat
Testing needs your staff, not only the developers
Developers prove the code runs. You prove the app fits the job. Give five or six staff a test build for a full week of ordinary work, and ask them to log every slip in one shared sheet.
Test bad conditions as well: a flaky signal in the loading bay, a three-year-old handset, a half-filled form, a screen that locks mid-entry. Low-end Android phones crash where flagship phones never do. Open the Crashlytics report after each session, and check that every permission prompt for camera, location or contacts explains itself, because users deny what they do not understand.
Then sign off in writing once the agreed test list passes.
Store review, release and updates are separate jobs
Register the Apple Developer and Google Play Console accounts in your company’s name before the build ends, since business verification can take days. Prepare the listing metadata, a subtitle, screenshots for each locale, a public privacy policy and a demo login for reviewers.
Reviewers reject apps for a vague privacy page, a login they cannot pass or a sign-up button that leads nowhere. Keep a buffer of at least a week. After release, read crash reports and reviews every morning, and plan an update whenever Apple or Google announces a deprecation.
Your next step: write down who holds each account, and mark the review buffer in the calendar.
- Developer accounts registered to your company
- A privacy policy at a public web address
- Screenshots in every size the stores ask for
- A demo login that needs no personal phone number
- Release notes drafted for the first update
App release readiness sheet
A single page built as a table with four columns: step, what you provide, who signs off and date. Rows cover discovery, design, build, testing, store review, release and the first update. A closing block lists each store account, its holder and its renewal date.
Open a blank worksheet to printQuestions owners ask
How long does the process take?
It depends on scope. A small internal app may take a few months, while a customer app with payments and an admin panel takes longer. Ask for a dated plan with your own approval dates marked, because those dates move the finish line too.
Do I need both an iPhone and an Android version?
Only if your users need both. Check which phones your staff or customers actually carry. One shared codebase can serve both, but each store still reviews and publishes separately.
Who owns the code?
You should. Put it in the contract, keep the repository under an account in your name and ask for build instructions so another team could take over.
What happens after launch?
Apps need fixes for faults real users find and updates as phones change. Agree a support arrangement before launch, covering who responds and how quickly.