The feature I built for myself that nobody asked for.
by•
I built something last quarter that no customer requested. I built it because it annoyed me, and I assumed if it annoyed me it probably annoyed everyone.
It flopped. Almost nobody uses it. The people who do love it, which is a sentence I've written before and probably will again.
But the strange part is that building it made me understand my own product better, and the architecture I wrote for it ended up making everything else faster. So it was a failure on the surface and a win underneath, and I can't tell if that counts as a success or if I'm just rationalizing.
Have you built something for yourself that flopped publicly but paid off privately? And how do you decide whether to keep something like that around?
12 views
Replies
I think building it still taught you a lot even if it didn’t work out 😅 What would you do differently next time?
Hi. All features I implement currently flop since I have no users yet - which is not quite the same I guess. But I still started knowing this was a likely outcome because I will and am learning things.
I learned in courses and books that the agile/ lean way would be to first do a test before shipping a new feature and only shipping it if the test is positive.
By now I came to the conclusion that these methods assume one has a lot of users one can do tests on and a lot of people working on the project with different ideas. As solo dev, its your product and while I understand that keeping unused features out of it keeps it easier and cheaper to maintain, there are still things that I myself want to have in my product.
Mine is invisible to users on purpose. Every tappable control in my app has a stable name, and every tap and every branch that quietly gives up writes a plain line into a log file on the device, which the user can share from Settings. Nobody asked for it and nobody will ever praise it. But when someone writes "it didn't work", I can see exactly what they pressed and where the app gave up, instead of guessing. I'd say your test for keeping something is whether it makes the rest of the product cheaper to build or support. If it does, its usage numbers are the wrong measure, it's paying rent somewhere else.