This idea is not mine. Somebody handed it to me, and he was quite annoyed when he did it.
A few weeks ago I was writing a post to find testers for a small training app I built. Before posting, I read the community for a while, which is what you are supposed to do. Near the top there was a post from a member who had had enough: everyone is building workout apps or money apps, can nobody think of anything else. It had upvotes. People agreed with him.
I did not post. (I wrote about closing that channel when I published the pilot — here.) But the complaint stayed with me, because he was right, and because “everyone builds the same thing” is a product question, not a matter of taste.
So here is the question I have been sitting with. Why does every category end up building the same feature?
The same product, over and over
Look at fitness apps. They all do the same thing. Log your workout. Log your weight. See a chart. Keep a streak. The difference between them is the design and the price, not what the product actually does.
Look at personal finance apps. Same shape. Connect your accounts, sort your transactions, see where the money went last month. Again: a very good record of the past.
Both categories built the same feature. And in both, the hard part is still missing. What and why this scope of exercises should I train tomorrow . What should I do about the money I just spent.
The usual answer is that tracking is easier to build. That is true. It is also not enough. Plenty of hard things get built. Something else is stopping teams here.
A record cannot be wrong the way a recommendation can
A tracker describes what already happened. If it shows the wrong number, that is a data problem. A sensor misfired. A transaction went into the wrong category. Someone typed the wrong thing. It is annoying, but the user knows what really happened, so they fix it and move on. Nobody’s judgment is being tested.
A recommendation is a different thing. It says: do this next. If it is wrong, it is not a data error. It is a judgment error. And the user does not see it as a bug. They see it as the product being wrong about them.
Give someone a starting weight that is too heavy and they fail the set, or they get hurt. Tell someone to cut a spending category they cannot really cut, and they stop trusting everything else you say. In both cases the product made a claim about that specific person, and the claim did not fit their life.
So the decision layer is not only harder to build. It is harder to ship. Someone has to be willing to be wrong in front of the user, again and again.
That is a different kind of hard. Building something technically difficult is an engineering problem. Being wrong in public and standing behind it is an ownership problem.
Nobody quits a workout log because it disagreed with them. Logs do not disagree. Plans do.
Tracking also demos perfectly
There is a second reason, and it is quieter.
A tracker cannot disappoint you in a demo. You open it, you log something, the chart moves. It looks finished in thirty seconds, and it looks the same to everyone watching. A decision layer needs weeks to prove itself, with one person at a time. In a demo, all you can do is describe it.
So the tracking feature is easier to build, easier to show, easier to price, and it never has to defend itself. Give a team a deadline and an investor meeting, and most of them will build that. Not because they are lazy. Because it is the only part of the product that is guaranteed to work on the day you need to show it.
That is where it becomes a trap. Every team makes the same sensible choice. And the category fills up with products that are well made and almost identical. Nobody stands out, because everyone avoided the same risk.
What I did in my own product
The training app I mentioned at the start — I built it mostly to solve my own problem, and to learn what AI-assisted development actually feels like.
Then I got to the part that decides what you should do. Which exercises, in what order, at what starting weight. That is where the ownership question stopped being theory. If the app tells someone to start at a weight that is too heavy, that is not a bug report. That is me, being wrong about a person I have never met, in a place where it can hurt them.
I could have avoided it. A log would have been easier, safer, and nobody would have complained. I built the deciding part anyway, because it was the only part I actually needed, and because a training app that will not tell you what to train is not solving the problem.
I am not claiming I got it right. I am saying I decided to be the one who is wrong when it is wrong.
The question worth asking
If you work in a category where every product looks the same, ask why the empty space is empty.
Sometimes it really is too hard to build. Often it is not. Often it is empty because filling it would mean giving your users an opinion — and an opinion can be wrong in a way that a chart never is.
That is a decision about how much risk your product is willing to carry. It is worth making on purpose, instead of ending up there because everyone picked the safest feature at the same time.
Leave a Reply