The App I Stopped Building

I have a fear of heights, and it is not a mild one.

I hike. I have done it for years, and I like it more than almost anything else I do with a free weekend. And at some point those two facts stopped being compatible, because a mountain is exactly the situation where being at ease in your own body matters most, and I was not at ease.

So I built something for myself.

Kleos Breathe was a guided breathing app. The idea was narrow on purpose. When you are standing somewhere that feels too high, you are not looking for a meditation library and you are not going to read anything. You need something that tells you to breathe, tells you what is happening in your body, and asks you nothing.

It was a small app. It did the one thing. It worked.

And across the whole of its closed testing, there was effectively no engagement. Not a disappointing number. Almost nothing. Very little feedback, very little usage, and very little evidence that it had connected with anyone at all.

One day, I started looking at the testing results differently.

The problem was not a bug. The people testing it simply did not need a breathing guide.

That was harder to fix than a bug, because there was nothing in the code that was asking to be fixed.

Why it was too generic

The problem was not that breathing was useless. It was that I had built a solution to my own problem and then described it to the world as a general product.

A breathing app is not a new idea. There are thousands of them. My version could be good and competent and still have no reason for a stranger to choose it, because I had not given them a reason to pick this one.

What I had actually built was a remedy for something specific and personal.

That was useful to me. It was not automatically useful to everyone else.

The uncomfortable failure

A crash would have been a gift.

A crash has a stack trace, a device model, a reproduction path and an obvious place in the code where the reasoning went wrong. It converts directly into work, and work feels like progress.

Nobody coming back feels like nothing. It has no stack trace, it cannot be reproduced, and it survives every unit test I can write, because nothing in the code is incorrect.

It tells you the problem is not technical, and technical problems are the ones I know how to have.

This was the part that took me longest to accept. I kept looking for a reason that would let me keep building it, and the reason I wanted was a bug.

There was never going to be one.

What I actually took from it

I did not rebuild Breathe.

The decision became much easier once I stopped looking for a technical explanation that was not there.

The strange part is that the feedback we did get about the app was actually positive. The onboarding worked well, the experience was clear, and there was no obvious UX problem that explained the lack of usage.

The app could be good and still not be needed.

That distinction changed how I think about building apps.

It is very easy to ask whether an idea can be built. It is much harder to ask whether someone has a reason to use it.

Breathe answered that question for me.

I built it because I had a specific problem. I tested it with people who did not have that problem. Then I learned that making the solution better would not make the problem appear.

I still think the app was good. I just do not think that counts for much.

The gap between an app that solves my problem completely and an app nobody else needs is the most useful thing that project ever taught me.

Sometimes stopping is the product decision.