BOLD INSIGHTS
It’s not when the features work. It’s when the app has survived people trying to use it the way real people actually use things carelessly, impatiently, on bad networks, with low battery, mid-distraction. “Ready” isn’t a feeling. It’s a checklist most teams don’t talk about until something slips past them.
I spend most of my time building mobile apps, not breaking them. But working closely with QA changed how I think about the word “done.” Here’s what I’ve learned actually separates an app that works from an app that’s ready.
It works the way it’s supposed to
This is the obvious one, and it’s usually where teams stop. Every button does what it says, every flow completes, every screen loads. Functional correctness is the floor, not the finish line. If this is the only box you’ve checked, you’ve confirmed the app works in the best-case scenario which, for real users, is rarely the scenario that happens.
It survives real conditions, not just your test environment
This is where things usually get uncomfortable, especially for mobile teams. An app that behaves perfectly on your dev phone, on office Wi-Fi, in a quiet testing session, can fall apart the moment it meets the real world: a three-year-old Android device, a spotty 3G connection, a phone call interrupting the app mid-transaction, the user switching apps and coming back ten minutes later.
I’ve shipped features that worked flawlessly every time I tested them and then watched QA break them in minutes by simply switching networks mid-flow or backgrounding the app at the wrong moment. Those aren’t edge cases. They’re Tuesday, for most users.
It holds up under real usage, not a clean demo run
A demo is a controlled performance. Real usage is chaos, hundreds or thousands of people doing unpredictable things at unpredictable times, sometimes all at once. An app that’s never been tested under load has only proven it works when nobody’s really using it yet. Performance testing before launch isn’t optional polish; it’s the difference between a smooth first week and a support inbox on fire.
It fails safely when something goes wrong
Things will break in production. That’s not a failure of testing it’s a certainty. What matters is what happens next. Does the app crash and lose the user’s data, or does it recover gracefully with a clear message? Does one broken API call take down the whole session, or does it fail quietly in its own corner?
Teams that test well before launch aren’t just checking that things work they’re deliberately trying to break things, so they know how the app behaves when it fails instead of finding out from a user’s one-star review.
Someone other than the builder has actually tried to break it
This might be the most important one, and it’s the hardest to do yourself. When you build something, you test it the way you expect it to be used because you already know how it’s supposed to work. Real testing means someone approaches it without that assumption: tapping things out of order, entering the wrong input on purpose, doing the thing you didn’t think to check.
I learned this the direct way. I built a form flow I was confident was solid validated inputs, clean error states, the works. QA found a way to submit it twice by tapping fast on a slow connection, creating duplicate records in the backend. Nothing in my testing would have caught that, because I wasn’t trying to break my own logic. That’s not a knock on the developer, it’s exactly why testing can’t be a step the builder does alone.
So how do teams actually answer this question?
Not with a gut feeling. In practice, it comes down to a process: structured testing passes across functionality, devices, and edge cases; a QA sign-off that isn’t a rubber stamp; and often a staged rollout, so the app meets a smaller slice of real users before it meets everyone. Each stage exists to catch something the previous one couldn’t.
This is the same standard we hold ourselves to on every project we test not “does it work,” but “has this actually been challenged before real users get to it.”
The real answer
An app is ready to launch when it has been challenged beyond the happy path, tested under realistic conditions, and shown to recover when things go wrong. “It works on my device” is not readiness. It’s where testing begins.
