The Smallest App Worth Putting in a Store

Too small is when the app no longer completes a single useful task end to end. An MVP with one path that works beats an app with six half-finished ones, because a store reviewer, a tester and a real user all judge it on whether the thing they came to do actually finishes. The test we apply is simple: can somebody install it, do the one job, and get a result they would tell a colleague about? If yes, it is big enough. If the only way to describe it is as a preview of something better, it is not ready for a public listing and should go out through a test track instead.

Because an app update is not live when you press publish. It has to be built, signed, submitted, reviewed by the platform, released, and then downloaded by each user, many of whom have automatic updates switched off. Even when review is quick, the gap between deciding on a change and most of your users having it is days at best and weeks in practice. That is the single biggest structural difference between a mobile MVP and a web one, and it is why we build remote configuration, feature flags and server-driven content into version one rather than adding them after the first emergency.

One platform first is usually cheaper to learn from and slower to sell internally. If your audience is genuinely split across both, a cross-platform build reaching both stores on one budget is normally the better answer than sequencing them. If the audience leans clearly one way, or the app depends on hardware behaviour that differs sharply between platforms, starting with one and porting once the idea is proven avoids paying twice for a feature set you may cut. We give you the recommendation with the reasoning, including the cost of each path, before anything is committed.

A phased rollout releases a new version to a small slice of users first and widens it over several days instead of giving it to everyone at once. Both stores support a version of this. It matters far more on mobile than on the web because you cannot take a bad build back off the phones that already have it — all you can do is halt the rollout and ship a fix that then has to be reviewed and downloaded. For a first release we use it every time, watch the crash-free rate and the review stream at each step, and only widen when the numbers hold.

It should not, and this is where a lot of MVPs go wrong. Small scope is fine; missing polish is not. The icon, the screenshots, the empty states, the loading behaviour, the error messages and the first-run flow are all part of what a reviewer and a first-time user judge, and none of them are optional because the feature list is short. We would rather cut a whole feature than ship six features with unfinished states around them, and the store listing gets the same attention as the build.

You decide that before we build it, not after. We agree the one question the MVP exists to answer and the specific event that counts as success — the booking placed, the scan completed, the second session in the same week — and instrument it from the first build. Then the numbers you look at are the install-to-first-value funnel, retention at day one, day seven and day thirty, and the crash-free session rate. Without that instrumentation in version one you get downloads and opinions, which is not an answer to anything.

Frequently, yes, and we will tell you when we think so. A responsive web app has no store review, no signing, no install step, no version fragmentation and no update lag, so you can change it at lunchtime and see the effect in the afternoon. If what you are testing is whether people want the thing at all, or whether they will pay for it, that is usually the faster and cheaper experiment. An app earns its place when you need push notifications, offline use, the camera or sensors, background behaviour, a permanent spot on the home screen, or store distribution as the sales channel. If none of those apply yet, building an app first is an expensive way to learn something a web page would have told you in a fortnight.