What people do when an app stops working.
- Kind
- Essay, 2026
- Read
- 4 min
- Written by
- Claude writes every post here. Each one starts as a long interview: I talk through what happened and what I think, it keeps asking until it has the whole story, and then it writes it in my voice and style. The thinking is mine. The typing is not.
Every Monday morning in 2020, I read what store associates had sent us about the app we build at NewStore and sorted it into categories. Some of the messages were only a word or two: “white screen”, “desperate”.
They came through a short survey I wrote about on Medium at the time. When someone closes the app and immediately reopens it, we assume something went wrong, and a pop-up asks what happened. I thought the next step was a better survey, one that would guide people to describe the problem.
The survey is still in the app. What I’d missed is that the most useful thing about it was never what people typed. It was the restart itself.
It was just normal for them
The idea came from an engineer on the team, and it came from what people do when an app seems stuck: “It looks like the app has a problem. Let me quickly close and reopen it.”
On store visits I saw how ordinary that was. “It was just normal for them to do it. Something hung and they just restarted.”
Someone who thinks of a restart as normal has no reason to mention it. It doesn’t become a complaint, and it won’t come up in a survey. But it can be counted, so we counted it: how often someone closes the app and reopens it within 15 seconds, out of all sessions. At times that was above 8%, which was way too high.
One restart, several teams
So I made it a company-wide goal, to improve our UX and customer satisfaction. It had to be company-wide, because a restart doesn’t belong to one team. Take login: one team owned the UI, another owned the authentication. Collaboration between teams is always a challenge when you need something solved, and the alignment and sync took time.
What helped was that the number told us where to look. The events that fired last before a restart pointed to culprits like issues on login, so we started there. Where retailers have the survey switched on, people were also telling us what had gone wrong, and the engineering team looked into those reports too.
The events couldn’t show everything. Network issues didn’t appear in them, and neither did memory, because associates leave their phones and the app on for days or weeks. Those we found on store visits, through what we observed and through logging.
We got it down
In December 2025 the rate was 5.59%. In October 2026 it was 1.73%.
| Dec 2025 | 5.59% |
|---|---|
| Jan 2026 | 4.31% |
| Feb 2026 | 3.51% |
| Mar 2026 | 3.11% |
| Apr 2026 | 2.73% |
| May 2026 | 2.57% |
| Jun 2026 | 2.48% |
| Jul 2026 | 2.32% |
| Aug 2026 | 2.18% |
| Sep 2026 | 1.96% |
| Oct 2026 | 1.73% |
I’m counting from December on purpose. The rate was higher before that, but the biggest step down came with a release that also touched the code detecting restarts, so I’ve left that step out.
Since then we’ve fixed freezes, crashes and login problems, and when two versions ran side by side, the newer one was lower at most of the retailers running both. We also upgraded the platform and the analytics SDK along the way, and startup time affects whether a restart lands inside the 15 seconds, so not all of the fall has to be fixes.
The rate is now tracked across all stores and by retailer. When it goes over a threshold, a warning fires and we follow up with the store manager.
Build it in from day one
If you’re starting an app today, build this in from day one, so you see how often people struggle with it. Otherwise that stays hidden. It’s also a great leading indicator. A survey is a lagging one.
In 2020 I read “desperate” on a Monday morning and thought the survey needed better questions. The person had already told us something before they typed a word: they’d closed the app and opened it again.