Tyler Denk 🐝, cofounder/ceo @ beehiiv, recently posted something that made me stop scrolling: "what not to do as a startup: cal[dot]com sold us on a feature that they internally knew they were soon deprecating." He added that his team "spent a month building" on that feature, then "spent days trying to get in contact with someone" as paying users, only to receive an "unsubscribe" after emailing the founder.

Tyler ended with a line that should be stapled to every early stage team Slack: "it's SO easy to do the little things right.. yet some startups still can't get out of their own way."

I want to expand on that, because the situation he described is not just a one-off support failure. It is a full-stack trust failure: product, communication, customer success, and leadership accountability all breaking at once.

The hidden cost of "small" support mistakes

When a vendor sells (or even casually encourages) a feature they know is about to be deprecated, the immediate damage is obvious: wasted engineering time. But the bigger cost is what happens next.

The customer now assumes your roadmap is not reliable.
They question whether your docs are current.
They wonder what else you are not saying.
They build contingency plans to replace you.

In Tyler's story, the technical problem (deprecation) quickly became a relationship problem (silence), then a credibility problem ("unsubscribe"), then an executive-level problem (founder bailing on the call and delegating to someone who could not answer hard questions).

That chain reaction is why "little things" are not little. In SaaS, customer trust compounds or it collapses.

Key insight: Deprecations do not destroy trust. Surprise deprecations plus poor communication do.

Selling a feature that is being deprecated: what went wrong

Let’s separate two scenarios:

Scenario A: Honest deprecation with clear guidance

You can still sell a product while deprecating parts of it if you are transparent:

"This endpoint will be deprecated in 90 days."
"Here is the replacement and a migration guide."
"If you build net new work, build on the new version."
"If you are blocked, here is our support SLA and an escalation path."

Customers can work with that. They can plan.

Scenario B: Deprecation known internally, not disclosed externally

This is what Tyler described: a feature was positioned as usable, while the vendor allegedly knew it would soon go away.

Even if that happened due to internal misalignment (sales did not know, support did not know, product changed plans), the customer experience is identical: they were nudged into building on sand.

If you are a startup, this is the moment to remember that "we did not intend harm" is not the same as "we managed the risk." Customers pay for outcomes, not intentions.

The support failure that turns frustration into churn

Tyler mentioned "spent days trying to get in contact with someone from their team (we're paying users)." This is where many startups get confused: they treat support responsiveness as a nice-to-have, when it is actually part of the product.

Here is the practical bar most B2B customers expect, even from small vendors:

An acknowledgment within 1 business day
A real owner assigned (not a generic inbox)
A clear next update time (even if the fix is not ready)

Silence creates a vacuum. In that vacuum, customers assume the worst: you do not care, you cannot fix it, or you are hiding something.

The founder communication trap: don’t escalate and then vanish

One of the most painful parts of Tyler's post was the leadership pattern: the founder was emailed, responded with an "unsubscribe," apologized later, then "bailed on the call" and sent a junior growth person who "dodged our questions."

Founders are not expected to personally handle every ticket. But when a situation has escalated to founder level, it is already a high-risk account moment. At that point, leadership has two jobs:

Restore trust with clarity
Set the internal standard for accountability

Delegating is fine if it is done thoughtfully. For example: "Our head of product and head of support will join this call, and I will be there for the first 10 minutes to confirm ownership and timeline." That signals seriousness.

What does not work is sending someone who cannot answer roadmap, deprecation, or remediation questions. That feels like avoidance, even if it is not meant that way.

Rule of thumb: If the customer has to ask "who can actually answer this?" you already lost a week.

A better deprecation playbook for startups

If you ship software, you will deprecate things. The goal is not to avoid deprecations. The goal is to avoid surprises and dead ends.

1) Maintain a public deprecation policy

Put this somewhere visible:

Minimum notice period (30, 60, 90 days)
What "deprecated" means (supported but not recommended, or scheduled removal)
Support guarantees during the window
Contact path for blockers

2) Add "deprecation risk" to your sales checklist

Before recommending any feature, sales and success should be able to answer:

Is this on the roadmap to change?
Is there a replacement?
Are there known limitations we should disclose?

If you are tiny, the "checklist" can be a shared doc or a single Slack channel. The point is to create a habit: do not sell what product is about to remove.

3) Communicate in layers

Customers miss emails. Make it hard to miss:

In-app banners for impacted users
Changelog notes
Direct email to admins and developers
Updated docs with a clear migration path

4) Provide migration help that matches the pain you caused

If a customer built for a month on something you are removing, you may owe more than an apology. Consider:

A working sample implementation
Office hours with an engineer
Credits for downtime or rework
Temporary extension where feasible

Not because you are "nice," but because it is cheaper than churn plus reputational damage.

Vendor management: what buyers can do to protect themselves

Tyler's post is also a reminder for teams integrating third-party SaaS:

Ask directly: "Is any part of this being deprecated in the next 6-12 months?"
Prefer vendors with public changelogs and deprecation policies
Build abstraction layers for critical integrations when possible
Track vendor SLAs and escalation contacts before you need them

This is not about being paranoid. It is about treating integrations like dependencies, because that is what they are.

The bigger lesson in Tyler Denk 🐝's point

When Tyler said, "it's SO easy to do the little things right," I read that as a challenge to every startup: the basics are your brand.

Tell the truth early.
Respond quickly.
Put a competent owner in the conversation.
Show up when you said you would.

You do not need a massive customer success org to do those things. You need standards, and you need leadership to model them.

If you are building a SaaS product, treat every deprecation and every support thread as a trust transaction. Because your customers are not only paying for features. They are paying for the confidence that you will not leave them stranded when the roadmap shifts.

This blog post expands on a viral LinkedIn post by Tyler Denk 🐝, cofounder/ceo @ beehiiv. View the original LinkedIn post →