What shipping a retired product taught me
WanderEye reached 100+ users across 9 countries. It was live on the App Store and Google Play. Then I retired it. Not because it failed, because continuing it would have been a choice to maintain something I had outgrown, and that is not the same as building something.
How WanderEye ended
The product worked. Users engaged with the landmark recognition feature. Some bought the subscription. But the engineering maintenance cost of two native apps, iOS and Android, each with their own review cycles, native module issues, and RevenueCat edge cases, was constant and growing. There was no 'done' state. There was only 'behind' or 'keeping up'.
Retirement is not failure. It is a product decision, the same kind of judgment that decides whether to build a feature or not.
What the metrics said
Retention was the problem. Users tried the landmark recognition feature once or twice, were impressed, and then did not come back. The product was a travel accessory, not a travel companion. That distinction means you get used occasionally, not habitually, which is a fundamental ceiling on subscription economics.
What I would do differently
I would define the retirement criteria before launch. Not as a failure condition, but as a product health check: if these metrics are not met by this date, we retire or pivot. Having that defined in advance removes the emotional weight from the decision and lets you move on faster.
Contents
- How WanderEye ended
- What the metrics said
- What I learned about scope
- What I would do differently