BuildingMobileAppsPeopleKeep:LessonsFromShippingOurOwnGames

Downloads are easy. Day two is hard.

Getting someone to install an app is only the first step. Most apps lose the majority of new users within the first few days, and the reasons are rarely technical. Publishing our own games — MadyMaze, MadyTap and Cheezy Escape — put us on the other side of that problem, owning every decision from the first screen to the store listing. Here is what we learned, and what we now bring to every client app.

1. The first 30 seconds decide everything

People don't read tutorials. In MadyMaze the first level is the tutorial: one finger, one ball, one obvious goal. The rules for fog, darkness and monsters only arrive once the basic move feels natural.

• Show, don't explain: teach through the first real task, not a carousel of slides.
• Delay sign-up: let people experience value before asking for an account — or don't ask at all.
• Make the second session obvious: a daily challenge, a saved draft, a half-finished level. Give people a reason to come back.

2. Offline is a feature, not an edge case

Cheezy Escape plays fully offline, and progress is saved on the device. That decision removed a whole category of support emails. The same applies to business apps: field teams, drivers and warehouse staff spend a surprising amount of time without a stable connection.

Designing offline-first means storing data locally, syncing when a connection returns and handling conflicts deliberately. It's more work up front — and far cheaper than rebuilding an app that falls apart in a basement or a rural road.

3. Measure behaviour, not vanity

Download counts feel good and tell you very little. The questions that actually shape a product are about behaviour:

• Where do people stop during their first session?
• Which level, screen or form has an unusual drop-off?
• What do returning users do that one-time users don't?
• Which crashes affect the most people, not just the most recent ones?

We instrument events from the first build, keep analytics privacy-respecting and say clearly in the privacy policy what is collected and why. Balancing a game — or a checkout flow — without data is guesswork.

4. Performance is part of the design

A reaction game like MadyTap is unforgiving: if a tap registers late, the game feels unfair. That discipline carries over to every app we build. Fast launch, smooth scrolling and instant feedback on every touch are what make an app feel trustworthy, long before anyone notices the visual design.

5. The store listing is a product too

App Store Optimisation is product work, not an afterthought. The icon, the first two screenshots and the first line of the description decide whether someone installs. We treat them like a landing page: clear promise, real gameplay or real screens, and a message that matches what the app actually does.

• Lead with the outcome, not the feature list.
• Use real screens, framed to tell a story in two swipes.
• Keep privacy labels, support and privacy pages accurate and easy to find — reviewers and users both check.

6. Releases should be boring

Store review, staged rollouts and version support mean you can't hot-fix a mobile app the way you fix a website. A predictable release process — automated builds, a test checklist for critical flows, and remote configuration for things that change often — turns launches from stressful events into routine ones.

What this means for client work

Every app we build for a client benefits from the lessons of the ones we publish ourselves: onboarding that respects people's time, offline behaviour that holds up in the real world, analytics that answer real questions and releases that don't keep anyone up at night. If you're planning a mobile app, that's the conversation we'd like to start with.