2
2 Comments

After 2 Years of Frustration, I Realized I Was Building Startups Backwards

I started my startup journey 2 years ago as a solo founder. My original process looked something like this:

I had a problem that I personally wanted solved.
I built a product around that idea.
Then I tried to find people who would use it.

As my software-building ability improved a lot, I found the biggest bottleneck in my process is step 3: finding people who would use it.

After spending a certain amount of time thinking about what the problem was, I realized that the biggest problem with my process is that I didn't focus on the people and the problems they have. I just assumed that people might have similar problems to me.

But each time I finished building, I found that I couldn't find people who were willing to use my product in their daily lives. Maybe the general problem area was real, but the specific problem I chose to solve wasn't painful enough. Or maybe my solution simply wasn't useful enough for them.

After these failures, I realized the functions and features of a product actually don't matter. What matters is finding the right problem and the right people.

Once you have the right problem and the right people (the right niche), then you just have to build a product that can solve the problem, and that's how a lean startup can succeed.

Another thing that changed is my understanding of MVPs.

When I first started doing startups, I had already heard of the MVP concept. The idea itself is easy to understand, but I found it very difficult to execute in practice.

Cutting features is actually the hardest part, because you need to clearly understand what the important problem is.

The purpose of an MVP is to focus as much as possible on the core thing that matters and simplify or remove everything else.

When you don't know what the important problem is, you start adding more and more features, hoping that they will help you gain users. But in reality, you may just be wasting time.

If people are still willing to use your product even when most of the non-essential parts are poor, incomplete, or missing, then it is a strong sign that you have identified the right problem.

I'm still learning and still struggling every day. But at least now I feel like I'm moving in the right direction.

Of course, these are just my current thoughts. Maybe my perspective will change again in the future.

on June 20, 2026
  1. 1

    Great post. I've found that building the product is often the most comfortable part for technical founders because it's something we can control. Talking to users, validating demand, and finding distribution are much harder.

    Your point that features don't matter until you've found the right problem and audience is something many of us learn the hard way. The best products often look surprisingly simple because the founders spent most of their effort understanding the problem before adding features.

  2. 1

    One thing I'd be careful about is that founders often discover one lesson that was missing and then quietly promote it to the explanation for everything that came before.

    Sometimes that's exactly right.

    Sometimes the new lesson deserves competition from a few other interpretations before it inherits that much confidence.

    That's what I found most interesting reading this.

Trending on Indie Hackers
I got my first $159 in sales after realizing I was building in silence User Avatar 53 comments Three Days Before Launch, I Let My Own Tool Tear Me Apart User Avatar 37 comments I thought I was building a news visualization tool. Users thought it was a catch-up tool. User Avatar 33 comments I got tired of rewriting the same content for 9 different platforms. So I built Repostify. User Avatar 30 comments A pattern I keep seeing in EdTech: traffic isn't usually the problem. User Avatar 23 comments I Rejected a $15K Acquisition Offer for My Multi-Agent IDE — Here's the Full Breakdown User Avatar 22 comments