This is apart of the series Startup that Failed .

The Problem with Problems

Here’s the thing about building startups — everyone talks about solving problems. But there’s a massive difference between a problem existing and a problem worth solving. And an even bigger gap between a problem worth solving and a problem someone will actually pay to solve.

I learned this the hard way. Or did I learn it at all? That’s the existential dread that keeps me up at night.

What I Did

As with any naive tech-centric maniac, I’ve jumped into solving an issue before first addressing if there is even a market need for it.

It all started with me in a dentist chair, listening to his complaints about outdated shit software from 2000’s, and his lack of mobility. Not to speak lack of integrations, and how difficult some solutions are to use.

This felt like gold. A captive audience (literally captive, I was in the chair) complaining about real pain points. So I did what any reasonable person would do: I created a list of everything he used, reached out to a few more dentists in different countries, and compared the findings.

The Research Phase ~ How I Fooled Myself

Over 40 days, I interviewed roughly a dozen dental practices. The pattern was clear, everyone reported identical issues:

  • Legacy software from the early 2000s with interfaces that looked like Windows XP threw up
  • Zero mobility - everything tied to a single desktop machine
  • No integrations between different tools (billing, scheduling, patient records all separate)
  • Painful onboarding process for staff
  • Compliance headaches

I thought I was being thorough. I thought I was doing customer discovery right. I was asking about their problems, taking notes, finding patterns. I even recorded some of the conversations to analyze later.

Here’s what I was actually doing wrong: I was collecting complaints, not validating willingness to change.

See, people love complaining. It costs them nothing. It feels good. They get to vent to someone who actually listens. But complaining about a problem is not the same as being willing to invest time, money, and effort into solving it.

I should have been asking different questions:

  • What have you tried to fix this?
  • How much is this costing you in real terms?
  • If I could solve this tomorrow, what would you be willing to pay?
  • When was the last time you looked for a solution?

Instead, I nodded sympathetically and moved to building.

DUMDUM - should have asked these, now I’m close to tattooing them so I don’t repeat the same mistake, ever.

The PoC Trap

After my 40-day validation phase, I decided to build a quick PoC. I invited a few of those offices to become my design partners.

Design partners. God, I loved that term. It made me feel like I was doing Y Combinator-approved customer development. In reality, I was recruiting an unpaid QA team who had no skin in the game.

The PoC took me about two months of nights and weekends. I showed it to my design partners. They loved it. Or at least, they said they did. They gave me tons of feedback:

  • This would be great if it had X
  • Love this, but could you add Y?
  • This is so much better than what we use now!

There was a single user — not even a design partner, just someone I’d shown it to — who said she finds it difficult to migrate and ditch her old habits. JUST A SINGLE USER. She was honest. She said look, this is nice, but I’ve been using my current system for 19 years. My entire staff knows it. The pain of switching… There’s no solution in this world to justify that.

I should have heard alarm bells. Instead, I heard an outlier. I even was mad, imagine how egocentric I was?!

The Enthusiasm Trap

At this point, things were looking good. Everyone seemed satisfied, even ecstatic with what they saw. I had a Notion board full of positive feedback. Screenshots of happy reactions. A few partners were even rushing me for a public release so that they can finally start using it day to day.

This narrative led me to scope out an MVP and hit the ground running. When I wasn’t working my 9-to-5, I was tinkering with my new baby.

What I failed to understand: Enthusiasm is not commitment. Compliments are not currency.

I never asked anyone for money. Not a pre-order. Not a deposit. Not a commitment to switch by a certain date. I was too afraid of the rejection. Too afraid that asking for money would ruin the relationship with my design partners.

This is the classic mistake. In The Mom Test (a book I read after this disaster), Rob Fitzpatrick puts it perfectly: Compliments are the fool’s gold of customer development.

People will be nice to you. They’ll say your idea is great. They’ll say they’d use it. But until money changes hands—or at the very least, until they commit to a concrete action with a timeline—you have nothing.

The Building Phase (Or: Polishing a Product Nobody Asked For)

To skip a few months which I’ll cover in other essays: PoC → mini-MVP → MMVP → first public release.

I spent nearly 18 months building. Nights, weekends, vacation days. My wife and kiddos barely saw me. My friends stopped inviting me to things because they knew I’d say no.

The product I launched was genuinely impressive from a technical standpoint:

  • Fully aligned with both USA and EU laws (HIPAA, GDPR, you name it)
  • A combination of features where each feature is almost a standalone product on itself (appointment scheduling, patient records, billing, inventory management, reporting, communications)
  • Robust Security & Encryption (AES-256, end-to-end encryption for patient data, SOC 2 Type II ready)
  • Modern, responsive UI that worked on mobile, tablet, and desktop (beta)
  • Integration capabilities with major payment processors and insurance systems

I was so proud of it. I thought, “Finally, dentists will have a modern solution.”

The Launch (Or: Reality Hitting Like a Freight Train)

What did it get me? Insomnia and burnout, and not a lot of users.

At the moment of writing, I’m still under 50 users. Most of them are from my initial design partner pool. Only a handful are paying anything close to what the product is worth.

My design partners had a thousand reasons why they couldn’t switch yet:

  • We need to finish this quarter with our current system
  • Our accountant needs time to adjust
  • Can you add just one more feature first?
  • The team needs more training

Translation: They were never going to switch. They liked the idea of a better solution. They liked being involved in the design process. They liked complaining about their current tools. But the pain wasn’t acute enough to justify the hassle of change.

Here’s the brutal truth: I built a painkiller for a headache when people wanted a painkiller for a migraine. The pain was real, but it wasn’t urgent.

What I Should Have Done Instead

I should have pulled the tooth myself, instead of going to fix it on that specifc day. Jokes aside, this would have been a better route.

1. Ask for Money Earlier

After those first 40 days of research, I should have said: Great, you’ve identified all these problems. Would you pay $200/month for a solution? Can I get a $500 deposit today to reserve a spot in the beta?

If they said no, I’d know the problem wasn’t painful enough. If they said yes, I’d have actual validation and runway to build properly.

2. Look for the Hair-on-Fire Customer

I talked to dentists who complained about their software. I should have been looking for dentists who were actively searching for alternatives. Who had tried multiple solutions in the past year. Who had allocated budget for this problem.

Those are the early adopters. Not the people who nod along when you describe the problem.

3. Validate the Switching Cost

The hardest part of any B2B SaaS isn’t building the product—it’s getting people to switch from what they’re currently using. Even if it’s terrible.

I should have explicitly asked: Walk me through what it would take for you to switch systems. Who needs to approve it? What’s the migration process? What could go wrong?

If they can’t answer these questions concisely, they haven’t thought seriously about switching. Which means they won’t.

4. Build Less, Validate More

I built 80% of the product before I had a single paying customer. I should have built 20% and gotten 10 paying customers first.

Ship a barely functional version that solves the most acute pain point. If people won’t pay for that, they won’t pay for the “complete” version either.

5. Talk to People Who Already Switched

I should have found dental practices that recently switched software systems and asked them:

  • What finally made you switch?
  • What was the process like?
  • What do you wish you’d known?
  • How did you justify the cost and disruption?

These people have already crossed the chasm. They can tell you what it actually takes.

The Bitter Lesson

The most painful part isn’t the wasted time or money. It’s that I thought I was doing validation right. I’d read the blog posts. I’d watched the Y Combinator videos. I talked to customers, found patterns, built iteratively.

But I’d confused research with validation. Research is learning about a problem. Validation is confirming people will pay you to solve it.

There’s a massive difference.

If you’re building something right now, ask yourself: Do you have validation, or do you just have research and enthusiasm?

Because I had plenty of both. And it got me nowhere.

Next in series: SF: The 80% That Nobody Asked For — How I spent 18 months building features nobody wanted because “minimum” felt like giving up.