This is part of the series Startup that Failed .

The Irony of the Minimum Viable Product

Here’s a fun exercise: Take the definition of MVP ~ Minimum Viable Product ~ and tell me which word matters most.

If you said Product, congratulations, you’re me 18 months ago. If you said Viable, you’re getting warmer but still wrong. The answer, painfully obvious in retrospect, is Minimum.

But minimum is boring. Minimum doesn’t impress investors. Minimum doesn’t showcase your technical prowess. Minimum feels like giving up before you even start.

So instead of minimum, I built maximum. Or at least 80% of maximum. Before a single person paid me a dollar.

That’s not minimal. That’s called building the wrong thing for way too long.

What I Actually Did

After my failed validation phase — which I covered in Validate Ideas Early — I had enthusiasm from design partners and a functional PoC. I was riding high on compliments and feature requests.

The PoC had taken about two months. It had the basics: appointment scheduling, patient records, basic billing, basic staffing. Maybe 15-20% of what I envisioned as the complete solution.

Here’s where the textbook mistake happened.

I looked at that PoC and thought:

This is nice, but it’s not impressive. Nobody will switch their entire practice management system for this. I need to build something that’s obviously better than the incumbents.

So I made a list. A beautiful, catastrophic list:

Phase 1 (The PoC - 2 months):

  • Basic appointment scheduling
  • Simple patient records
  • Billing placeholder (internal, not supporting popular platforms)
  • Basic authentication
  • Basic staffing (management for doctors and assistants)

Phase 2 (The Real MVP - what I thought would take 4 months):

  • Advanced scheduling with recurring appointments, waitlists, automated reminders
  • Extremelly detailed patient records with full medical histories
  • Integrated billing with multiple payment processors
  • Insurance claim submissions (USA and several EU countries)
  • HIPAA and GDPR compliance infrastructure; and SoC-2 ready
  • Inventory management for dental supplies
  • Multi-provider support
  • RBAC (doctor, hygienist, receptionist, admin)
  • Native Mobile apps for iOS and Android (not just mobile web); though I didn’t get to release Android
  • Patient portal where patients could view records and book appointments
  • SMS and email notification systems
  • Reporting and analytics dashboards
  • Data export/import tools

Looking at this now, I want to reach through time and slap myself. But back then? This felt responsible. This felt like doing it right.

The Feature Creep Trap

Eric Ries, in “The Lean Startup,” warns explicitly about this. He calls it achieving failure — successfully executing a plan that leads nowhere because you’re building features nobody wants.

My excuse was obviouus: Design partners had asked for these features!

Each request seemed reasonable. Each one felt like the thing that would tip them from interested to committed.

Here’s what I didn’t understand: Feature requests are not the same as priorities. And it would be nice to have is not the same as I’ll pay for this today.

When someone says I’d switch if you had X, they’re not making a commitment. They’re making an excuse. Because if they really wanted to switch, they’d switch to the imperfect solution and lobby you to add X later.

The 80/20 Principle Applied Backwards

You know the Pareto Principle: 80% of value comes from 20% of features. Everyone knows this. I knew this.

But knowing it and believing it are different things.

I convinced myself that while 80/20 might be true for consumer apps, it didn’t apply to B2B healthcare software. The dentists needed a complete solution. They couldn’t run their practices with just 20% of the features.

This was bullshit. Complete, self-serving bullshit.

The truth? That first 20% of my PoC could have run a dental practice. Would it have been clunky? Yes. Would they have needed workarounds? Absolutely. Would some practices have said not for us? Of course.

But some, maybe even one,would have said yes. And that one would have paid. And that payment would have told me something real about the market.

Instead, I spent 16 additional months building the other 80%.

Did I mention I stopped going fly fishing?

The MVPocalypse: An 18-Month Building Marathon

Let me break down what actually happened after the PoC:

Months 3-6: Built out the core features. Recurring appointments, patient medical histories, multi-provider support. The PoC could now theoretically support a real practice.

Months 7-10: Compliance infrastructure. HIPAA, GDPR, SOC 2 Type II readiness. Encryption, audit logs, data retention policies. This was necessary!

Months 1-14: Mobile apps. Rewrote significant portions in Kotlin and Swift. Learned two new ecosystems. This was actually kind of fun, which should have been a red flag.

Months 15-18: Integration hell. Payment processors, insurance systems, SMS gateways, email services. Polish and final touches that were neither.

Throughout this entire period, I had zero paying customers. I had design partners using the beta. I had feature requests. I had we’re so excited for launch! messages.

But I had no money changing hands.

The Educational Silver Lining

Around month 12, when I started to feel the creeping dread that I might be building the wrong thing, I rationalized it.

Well, I thought, even if this doesn’t work out, I’m learning something new. That’s valuable. And I’m getting deep experience with mobile development, compliance frameworks, healthcare integrations. My resume will look amazing!

This is what Steve Blank calls a very expensive training program. And he’s right.

Yes, I learned things. Yes, my technical skills improved. But that was never the goal. The goal was to build a business. And I’d traded the objective (business) for a consolation prize (education).

If your primary consolation prize is at least I’m learning, you’ve already admitted you don’t believe in the business.

What the Experts Say

Let me share what smarter people than me have said about MVPs, all of which I ignored:

Eric Ries on MVPs

The whole point of the Lean Startup methodology is collecting maximum validated learning with the least effort. Least effort. Not most impressive effort. Not effort that showcases your skills. Least.

Ries loves telling the Zappos story — how the founder just photographed shoes at local stores, posted them online, and manually bought and shipped them when someone ordered. No inventory. No warehouse. No nothing.

That’s an MVP. My 18-month building spree? That’s the opposite.

Paul Graham on Doing Things That Don’t Scale

Graham has this famous essay where he talks about how founders need to manually recruit their first users. You can’t sit back and wait for users to discover you. You have to go hunt them down.

I did the opposite. I waited for my product to be ready before seriously pursuing paying customers. I wanted something polished enough that it would sell itself.

Products don’t sell themselves. Especially not to customers who have been using the same system for 15 years.

The Startup Genome Report on Premature Scaling

The Startup Genome folks found that premature scaling kills about 70% of startups. Startup Genome findings, page 18 . One flavor of this? Building products that are too feature-rich before you have customers.

Their research showed startups that scale prematurely burn through resources way faster than those who scale consistently with customer growth. I wasn’t burning investor cash — I was burning my own — but the principle holds. I was scaling the product before I’d scaled the customer base. But boy did I do it good!

Buffer’s Two-Page MVP

Joel Gascoigne, founder of Buffer, started with a two-page website. Page one explained the concept. Page two collected email addresses. That’s it. No product. Just a landing page. When enough people signed up, he built a bare-bones version. When people started paying, he built more. I did this backwards. I built everything, then asked people to pay.

The Launch That Wasn’t

Month 18. I’m ready to launch. The product is beautiful. It has features that none of the incumbents have. The UI is modern. The mobile app(s) are smooth. The compliance infrastructure is solid.

I announce to my design partners: We’re ready!

You can guess what happened next. The same excuses I’d heard during validation came back with new packaging. (I covered the launch disaster in detail in the validation essay — no need to relive that trauma twice.)

The short version: Out of roughly a dozen design partners, six actually started using it. Add a few random signups, and I had fewer than 50 seats sold (to date).

The broader launch yielded almost nothing. Most people abandoned during onboarding.

What I Should Have Done

Here’s the playbook I wish I’d followed:

1. Ship the PoC as the MVP

That two-month PoC? That should have been version 1.0. Not version 0.1. Not just a demo. The actual product.

It scheduled appointments. It stored patient records. It had basic billing. That’s enough to run a small dental practice if you’re willing to use workarounds for edge cases.

I should have said: Here it is. $150/month. Who’s in?

2. Get Five Paying Customers Before Building Anything Else

Not design partners. Not beta testers. Paying customers.

If I couldn’t get five practices to pay for the PoC, I’d know immediately that more features wouldn’t solve the problem. But instead, I spent 16 months building my way around the real issue: insufficient customer pain.

3. Build Features to Close Deals, Not to Impress

The only valid reason to add a feature: Customer X will pay $Y/month if we add Z.

Concrete customer. Concrete price. Concrete feature.

Everything else is just me trying to feel productive while avoiding the hard work of selling.

4. Embrace the Janky Workaround

My PoC didn’t have insurance integration. You know what’s a workaround? A practice keeps using their old system for insurance claims while using mine for everything else.

Is that ideal? No. Is it viable? Yes.

But I was too proud for janky workarounds. I wanted an all-in-one solution that was objectively better than the competition.

Pride is expensive.

5. Learn From Switchers, Not Complainers

I should have talked to practices that recently switched systems to understand what it actually takes. Those people know the switching costs, the migration pain, the internal politics.

I never did this. Because I was too busy building features for people who would never switch.

The Brutal Math of Waste

Here’s what 1,200 hours of building the 80% nobody wanted cost me:

If I’d spent those 1,200 hours selling the 20% PoC instead:

  • Realistic customers acquired: 20-50 practices (conservatively)
  • Potential MRR at 30 customers: $4,500
  • Potential ARR: $54,000

Instead, I got burnout, family strain, and exhaustion so severe I could barely function at my day job by month 18.

The real cost? I’ll never know if the PoC would have worked. I built my way past the point of learning.

The Feature Debt I Couldn’t Escape

Here’s another thing nobody tells you: Every feature you build is a commitment.

I built insurance integration. Now I have to maintain it when insurance companies change their APIs. I built iOS and Android apps. Now I have to keep them updated with OS changes. I built integrations with dozen different payment processors. Now I have to monitor six different deprecation schedules.

Feature debt is like technical debt, but worse. Technical debt is code you have to refactor. Feature debt is code you have to maintain forever, even if only three customers use it.

By building 80% of the product upfront, I committed myself to maintaining 80% of the product. For <50 users.

If I’d shipped the 20% PoC, I’d have 20% of the maintenance burden. And if it took off, I could have hired help before adding the next 20%.

The Lesson I’m Still Learning

Building things is seductive. It’s tangible progress. You can point to features and say you made that. Selling is terrifying. It’s rejection and objections and people asking for time to think about it.

So we (I) avoid selling by building. We tell ourselves we’ll get sales-ready with just a few more features.

But sales-ready is a lie. If someone won’t buy version 1.0, they probably won’t buy version 2.0 either. They’ll just have different excuses.

The only way to know if you have something worth building is to try selling it before it’s done.

This is terrifying. It feels premature. It feels like you’re setting yourself up for rejection.

But rejection at month 2 is a gift. Rejection at month 18 is a story.

The Real Lesson

The MVPocalypse taught me something painful: Impressive products don’t build businesses. Customers do.

I thought I was being responsible by building a complete solution. I thought minimum meant insufficient. I thought I needed to impress before I could sell.

I was wrong on all counts.

Minimum doesn’t mean inferior. It means learning fast.

Ship the smallest thing that solves a real problem. Get someone to pay for it. Then build more based on what you learn, not what you imagine.

The math is simple:

  • Rejection at month 2 costs you 2 months
  • Rejection at month 18 costs you 18 months and your soul

I paid the full price. You don’t have to.

Next in series: SF: The Cost Trap — How I knew it wasn’t working at month 6 but kept building for another year anyway.