•
7 min read
In my previous attempts I started with the app. This time I'm starting with the problem.

As I mentioned in the previous post, I’m starting a Build in Public mixed with Learn in Public, and I’ll be documenting my journey building a product from scratch until I reach the first 100 users. Here’s how it will work: I’ll post on my Twitter about the day-to-day of this journey, the decisions I make, and what I’m studying. Here on the blog, I’ll write more polished and structured posts about what I’ve learned, sharing results and, at least once a week, bringing more robust product updates.

So to kick off this new product, I decided to look for references, articles, and videos from founders and indie hackers to understand their process, how they found a problem, how they validated it, and how they structured it. I believe this is the main stage, and the one I kept getting wrong before. The goal now is not to mess this up again.

The main insight from this research was clear: you shouldn’t start with the idea, but with the problem. Before, I kept coming up with app ideas. I thought, for example, about Stamp: a really cool map to share my travels with friends. But I had no clarity on what real pain I was trying to solve. When we shift the focus to the problem, we can go deeper into what’s actually needed, talk to potential users, and understand how they feel before designing the right solution.

The ideal is to solve a problem you have yourself. By being the first user of your product and owning that niche, development flows more naturally and motivation stays high. It’s also worth targeting a super-niched market, off the radar of big players. With AI advancing, large companies launch features at record speed and dominate the mass market with ease.

Think about the current market: there are dozens of business management and e-commerce apps. But what if you built a tool focused exclusively on calculating cost price and production time for crochet artisans? Anyone who lives off that work knows how hard it is to price the time spent on each stitch and the centimeters of yarn lost. While big financial software serves traditional industries and ignores the complexity of manual work, you build something tailored to your own routine. It’s a chance to solve the exact pain of a huge community that tech giants consider “too small” to pay attention to.

But how do you know if the problem you found is worth it? To find out if you’re facing a real pain that needs a solution, ask yourself these four questions:

  • Does it cost time and/or money? (Pains that hit your wallet or your clock are the most urgent).
  • Does it happen frequently and repeatedly? (Is it a recurring problem or something that only happens once a year?).
  • Does it take a long time to solve? (Every time it happens, does it require a lengthy effort to fix?).
  • Do people improvise solutions in their daily lives? (Do they already try to get by with complex spreadsheets, WhatsApp groups, or notes apps?).

If you answered yes to all of them, congratulations you just found a gold mine. But you don’t necessarily need to say yes to every single one; if your problem has 2 or 3 “yes” answers, you already have enough validation to build a product people will actually want to use.

So following these insights, I decided to list all the problems I have in my daily life and filter which ones truly fit what we talked about above, something I enjoy, niched, off the radar of big players, and a daily pain.

My fiancée and I have two dogs: Peter and Berlin. We split all their responsibilities, but we face a classic daily problem, she leaves and I have no idea if the dogs have already eaten. And the worst part is they always act like they’re starving, even after they’ve already eaten lol. Beyond feeding, we also have to remember to give meds on time, vaccine dates, flea treatment, deworming, it’s a lot to keep track of and we don’t have a centralized place to manage it. Everything is scattered across WhatsApp conversations.

Based on that, I determined my ICP (Ideal Customer Profile). With that defined, the next step is to validate the problem. Using the methodology from The Mom Test, I’ll investigate people’s real behavior: how they handle this routine today, what workarounds they use, and whether they actually put effort into solving this pain.

In parallel, I started mapping the market. I identified 9 competitors that, although they don’t serve exactly the same ICP, solve similar problems. I’ll analyze them one by one and classify them as direct, adjacent, and similar competitors.

The goal of this analysis isn’t just to list features, but to understand each one’s positioning, how they solve the pain, what their distribution model is, and most importantly, the bottlenecks and main user complaints. It’s precisely in these weak spots of competitors where the gold for my differentiation lies. I want to understand why people choose these solutions and, more importantly, why they abandon them.

To keep my journey transparent with you, these are my goals for the week:

  • Exchange experiences: Talk to founders who have already built their apps and reached their first users, to understand what worked, what didn’t, and pick up practical tips.
  • Define positioning and MVP: Based on the competitor analysis, outline my differentiation and list the must-have features for the first version of the app, leaving the rest for later.
  • Validate with potential users: Talk to my ICP before writing a single line of code. Since my dog goes to daycare every week, I know it’s full of potential users. I’ll take the opportunity when picking up Peter and Berlin to talk to these people, applying The Mom Test techniques.

Readings and references that helped me in this stage

If you’re also in the phase of finding or validating a problem for your next project: