How Do I Decide What to Build Next

These days, I’m the main user of my app, Detox Mental. For this reason, feedback is pretty straightforward: from me to myself.

But it wasn’t always like this.

A while ago, I didn’t use the app, so I was building “blindly”—guessing what users may want and building without feedback.

This proved to be a very ineffective approach because there was no way to know if new features solved real problems. As I explained in another post, the turning point was reading an essay from Y Combinator’s founder that opened my eyes to the truth: I needed to build something I liked and used, not something I imagine the market to want.

Based on the essay and my experience building something for myself, I’ve found that feedback is not only a nice-to-have, but absolutely necessary.

Applications need users to evolve. As eloquently explained by David Heinemeier Hansson:

“The way you arrive at good software is you write a little bit of software, and then you try to use it. It is in the process of using software that you discover what you really want. It’s where you discover what’s important and what’s not important.”

So that’s how I decide what to build: I use the app on a daily basis, and based on my own usage, I discover what actually matters—what’s worth building and what’s worth fixing.

For example, the main idea behind building the journaling module of Detox Mental was to have a “Socrates” within the app. It was supposed to be the main feature: if you did your journaling in Detox Mental, you could talk to Socrates about your writing.

But using the app revealed that the Socrates character was a secondary feature. I did implement it, but the main feature are the journaling Weekly Summaries, where “Socrates” lives.

As another example, I was obsessed with resolving a security issue with the audio sessions of the educational module: anyone could bypass the control preventing them from accessing paid session, and fixing this was always on the back of my mind.

But it turns out that there is currently no demand for the course, so fixing that issue was irrelevant. In contrast, there was a small problem with the navigation component that was driving my crazy each time I used the app, but which I never fixed because I was too busy building the course.

Daily usage revealed the real priority: fix the navigation issue, the blocked sessions can wait until there’s real demand.

It all boils down to having actual users testing the software and deciding what’s important through their goals, expectations and frustrations.

While there are exceptions, this is the rule of thumb that I follow in my everyday building of software, and since I started applying it, building has become more fun, productive and satisfying.