A founder once walked me through a product that wasn't live yet.

The architecture diagram looked like a subway map of a city that didn't exist. Microservices. Event buses. A design system with more components than users. A pricing page with four tiers and zero customers.

He asked what I thought.

I said, “This is a beautiful empty restaurant.”

He laughed. Then he didn't.

That conversation stuck with me because I've been in that restaurant. I've built the kitchen, plated the specials, polished the cutlery — and then realized nobody knew the doors were open. Sometimes the doors weren't open at all.

Most SaaS products don't die in the market.

They die in the building.

Quietly. Respectably. Surrounded by good intentions and unfinished Jira tickets.

The Comfortable Lie We Tell Ourselves

There's a story founders love.

It goes like this: if we just get the product right — the features, the polish, the “experience” — customers will come. Distribution is a later problem. Sales is something you hire for after product-market fit. Marketing is for people who can't build.

It's a comfortable lie.

It lets engineers keep engineering. It lets designers keep designing. It lets everyone avoid the uncomfortable part of software: putting something imperfect in front of a stranger and asking for money.

I've watched teams spend months refining onboarding flows for users who don't exist yet. I've seen roadmaps with eighteen months of features and zero hours reserved for finding the first ten customers. I've sat in meetings where people argued about dark mode before anyone had signed up.

It's like rehearsing a play for an empty theater and calling it progress because the lighting cues are perfect.

What Actually Kills Products Early

When people talk about “failed startups,” they imagine dramatic collapses. Funding runs out. A competitor eats lunch. The market shifts.

That's the loud death.

The quiet death is more common.

The product never meets a real customer. Or it meets five friends who are too polite to say it's confusing. Or it launches to a landing page that collects emails into a spreadsheet nobody opens.

I've built enough software — client work, internal tools, product experiments — to recognize the pattern.

Death by abstraction.
You build for “users” instead of a person with a name, a budget, and a Tuesday afternoon problem.

Death by completeness.
You refuse to ship until it feels finished. Finished is a feeling, not a milestone. Feeling finished is how products miss the market window and call it quality.

Death by infrastructure.
You spend the first quarter on auth providers, observability, multi-tenant isolation, and CI pipelines that could deploy to Mars. Your competitor ships an ugly Notion form and starts learning.

Death by roadmap.
The backlog becomes a museum of good ideas. Every idea deserves a ticket. Every ticket deserves a sprint. Nobody asks which ticket gets a customer to say yes.

Death by demo culture.
The product looks great in a walkthrough. It collapses in unsupervised hands. You optimize for applause in meetings instead of outcomes in the wild.

None of these require a villain. They only require a team that loves building more than it loves being useful.

Websites vs. Systems (And Why That Distinction Matters)

Early in my career, a lot of work looked like “build us a website.”

A brochure. A contact form. Maybe a blog. Ship it, invoice it, move on.

Then the requests changed.

“Can this connect to our inventory?”
“Can sales see the same pipeline operations sees?”
“Can we stop copying numbers between three tools every Friday?”

People weren't asking for pages. They were asking for systems that made the business less stupid.

That shift taught me something that applies brutally to SaaS:

A product that doesn't change a workflow is decoration.

Decoration can be pretty. Decoration rarely become businesses.

If your SaaS doesn't remove a painful step, compress a handoff, or make money movement clearer, you don't have a product. You have a portfolio piece with a login screen.

I care less about how modern the stack looks and more about whether Tuesday gets easier for the person paying the bill.

The First Customer Is Not a Vanity Metric

People treat “first customer” like a ceremonial ribbon cutting.

It's not.

The first customer is the first time reality gets a vote.

Before that, every assumption is fan fiction:

• They'll understand this navigation.
• They'll pay this price.
• They'll migrate their data.
• They'll care about this feature as much as we do.

After the first customer, you get bruises. Useful bruises.

You learn which screens they ignore. Which emails they never open. Which “critical” feature they work around with Excel because your version is slower than their ugly spreadsheet.

I've seen products get dramatically better in two weeks of real usage than in two months of internal debate. Not because the team got smarter overnight — because the feedback finally had consequences.

No customer means no consequences. No consequences means you can stay wrong forever and still feel productive.

Minimum Is a Discipline, Not a Phase

We ruined the word MVP.

It used to mean: the smallest thing that can test a valuable hypothesis with a real user.

Now it often means: version 0.9 of the dream product, missing only the features we ran out of time for.

That's not minimum. That's late.

A real minimum product answers one sharp question.

Not twelve.

If your MVP needs a guided tour, three integrations, role-based permissions, and a dashboard with charts before anyone can get value, you didn't build an MVP. You built a first release and called it humble.

I like a simpler test:

If this disappeared tomorrow, would anyone change how they work this week?

If the honest answer is no, you're still in prototype theater.

Features Are Not Traction

This one hurts because builders love features.

Features feel like progress. You can screenshot them. You can put them in a changelog. You can demo them.

Customers don't buy your changelog.

They buy a better Tuesday.

I've watched teams celebrate shipping a notification system while the core workflow still required a human to copy values between screens. I've watched “AI-powered” labels get added to products that still couldn't generate a correct invoice.

It's the product equivalent of renovating the balcony while the foundation leaks.

The question isn't “what else can we add?”

It's “what is still making the customer hesitate?”

Sometimes the answer is a missing feature. Often it's onboarding, trust, pricing clarity, migration pain, or the fact that nobody knows you exist.

Shipping another feature to avoid selling is a very expensive coping mechanism.

The Distribution Blind Spot

Engineers are trained to believe the hard part is construction.

In SaaS, construction is often the easy part.

The hard part is attention, trust, and habit.

Who will hear about this?
Why will they believe you?
What makes them switch from the ugly tool that already works?

I've seen technically inferior products win because they were embedded in a community, sold by someone who understood the buyer's language, or simply available when the pain was acute.

And I've seen elegant products die unread, like novels left in a drawer.

If your roadmap has fifty engineering tasks and zero distribution experiments, you're not building a business. You're building a private museum of craftsmanship.

Agency Work Taught Me the Same Lesson Differently

When you build for clients, reality arrives earlier.

There's a contract. There's a deadline. There's someone asking, “When can we use this?”

That pressure is uncomfortable. It's also clarifying.

Client work forces a bias toward usefulness. Not always toward elegance — sometimes toward compromises I still wince at — but toward software that has to earn its keep in an existing business.

Product work can float longer in imagination. Especially if you're funding it yourself or with patient capital. Imagination is wonderful. Unbounded imagination is how you spend a year polishing a ghost.

The best product teams steal the useful paranoia of client delivery:

Ship something real.
Put it in the path of real work.
Measure whether the work got better.

Then decide what deserves to exist next.

What “Alive” Looks Like Before Scale

A product can be alive long before it's big.

Alive looks like:

• One customer using it without you sitting next to them
• One workflow that no longer needs a workaround
• One payment that wasn't a favor from a friend
• One complaint that is specific enough to fix

Dead looks like:

• Endless private betas with no urgency
• Feature debates with no usage data
• A landing page older than the product's learning
• A team that talks more about architecture than adoption

I'd rather have a crude tool with three paying users than a refined platform with a waitlist of vaguely interested LinkedIn connections.

Waitlists flatter. Customers constrain. Constraints make products honest.

How I Decide What to Build First Now

Over years of shipping — client systems, internal tools, product experiments — my ordering changed.

I used to start with structure: database schema, auth, admin panel, design system.

Now I start with the moment of value.

What is the first screenshot a customer would send a colleague and say, “This saved me an hour”?

Build toward that moment. Starve everything else until that moment works.

Auth can be boring.
Billing can be manual at first.
Settings can wait.
The perfect empty state can wait.

The value moment cannot wait.

If you can't describe the value moment in one sentence that a non-technical buyer understands, you're not ready for a roadmap. You're ready for more conversations.

The Irony of Modern Product Building

We have better tools than ever.

Faster frameworks. Better hosting. AI that scaffolds screens in minutes. Design kits. Component libraries. Analytics out of the box.

And somehow, products still die before their first customer.

Because tools accelerated building.

They did not accelerate courage.

Courage is showing the unfinished thing. Charging before you feel ready. Asking a stranger what's broken instead of asking your team what's missing. Deleting the clever feature that only impresses other builders.

The stack got faster. The avoidance got faster too.

You can now avoid the market at unprecedented velocity.

A Practical Anti-Death Checklist

If you're building SaaS right now, steal this and put it on the wall:

1. Name the first customer type in one sentence. Not “SMBs.” A role, a context, a pain.
2. Define the value moment. The before/after that makes payment feel rational.
3. Ship the thinnest path to that moment. Everything else is optional until then.
4. Talk to humans weekly. Not surveys. Conversations. Watch them struggle.
5. Sell before you scale. If you can't explain why it's worth money, more features won't invent the reason.
6. Protect learning time. Every week without contact with reality is a week compounding fiction.

This isn't romantic. It's survival.

What I Believe Now

I don't believe every product needs to become a unicorn.

I do believe every product needs a reason to exist outside the builder's head.

Software that never meets a customer isn't a startup. It's a very elaborate hobby with cloud bills.

There's nothing wrong with hobbies. Just don't confuse them with companies.

The first job of a SaaS product is not to look complete.

It's to become necessary to someone.

Necessary enough that they come back.
Necessary enough that they complain when it breaks.
Necessary enough that they pay.

Everything after that is growth.

Everything before that is rehearsal.

The Takeaway

Don't build a palace before you've sold your first lemonade.

Most SaaS products don't fail because the market is cruel.

They fail because they never give the market a chance to be honest.