What Your App Needs on Day One

One job, done properly

The apps people keep do one thing well. Check the job list. See the order status. Book the slot. Log the reading. Everything else is a distraction from the thing that made someone install it.

So version one is that job, complete and polished, plus the minimum around it. The temptation to add is strongest before launch and the evidence for what to add only exists after.

The four things version one genuinely needs

1. The core job, end to end. Not half of it with the rest “coming soon”.
2. Sign-in that is not a barrier. Email link or a platform sign-in beats a password nobody will remember.
3. A first-run experience. The first thirty seconds decide whether there is a second session.
4. Crash reporting and basic analytics. Shipped without these, you are guessing.

The most common version-one mistake is not a missing feature. It is an empty first screen that tells a new user nothing about what to do next.

The first-run problem

A new user opens an app with no data. A job list with no jobs, an order screen with no orders. It looks broken even when it is working perfectly.

• Every empty state explains what will appear here and how to make it happen
• One clear action on the first screen
• Permissions requested when they are needed, with a reason — never all at launch
• A skippable tour, if any — a forced one loses people

What can wait

• Settings screens nobody has asked for
• In-app messaging, unless it is the product
• Social features — sharing, following, comments
• Dark mode, unless your users work at night, in which case it is essential
• Tablet layouts, unless tablets are the deployment
• Offline, unless the field requires it

Each of these appears in most first-version briefs and each can be added later against evidence. Shipping without them is how you get to evidence.

Things that look optional and are not

1. A force-update mechanism. The ability to require an update when a bad version is out. Trivial to build up front, impossible to add retrospectively to installed copies.
2. Remote configuration. Turning a feature off without a store release has saved more than one launch week.
3. A support route. A way to contact you from inside the app, with the version and device attached.
4. Session and error logging. When a user says “it did not work”, you need to see what happened.

These four cost a few days and are the difference between fixing a launch problem in an afternoon and waiting three days for a review.

How we decide the cut

For every proposed feature: what happens if it is not in version one? If the answer is that a user is inconvenienced, it waits. If the answer is that they cannot complete the core job, it stays.

Then, before launch, we watch five real users complete the core job on their own phones without help. Every version-one scope has been improved by that session, usually by removing something rather than adding.

Frequently asked questions