The Support Trap: Why Your Thoughtful Responses Might Be Making Things Worse

I spent six months answering every customer email for a SaaS product I built with a friend. Every single one. I'd wake up, brew coffee, and start with the inbox before writing any code. We were going to be different—we'd build loyalty through genuine human connection and actually caring about support.

Three months in, I realized I was spending 20 hours a week explaining why we couldn't fix things, why our pricing made sense, and why their feature request didn't align with our vision. The irony? The customers weren't happier. They were angrier. I'd just moved from being a faceless company to being a person who kept saying "no."

Reading through the Castro Podcasts postmortem about their support approach hit me hard because it articulated something I'd intuited but never fully processed: sometimes, thoughtful support responses are worse than no response at all.

The Pricing Complaint Trap

Let's be honest—no one emails support to tell you your pricing is great. They email because they're frustrated, and they're hoping to negotiate or find validation that they're justified in feeling ripped off.

The Castro team learned that explaining why software costs money, no matter how carefully framed, doesn't land. The user isn't looking for logic. They're looking for a discount or permission to feel wronged. A detailed justification just extends that conversation and makes them feel unheard.

I've watched this play out dozens of times. You write a thoughtful response about development costs and server infrastructure. The customer replies with something like "but it's just an app?" You're now arguing economics with someone who never wanted an economics lecture. You've lost.

The Unreplicable Bug Problem

Here's where I disagree with the Castro team slightly, but I understand their exhaustion. Bugs that users report but you can't replicate are genuinely valuable—they're production signals you'd never see in your test environment.

But the Castro point stands: what's the response? "We'll look into it"? That's hollow, and users know it. The honest answer—"I can't reproduce this, so I can't fix it"—is demoralizing for everyone involved.

I've started handling this differently. Instead of a human response to every unreplicable bug, I implemented better error tracking and created a dedicated issue form that funnels directly to our system, not to my inbox. I respond with automation when possible. When I do respond, it's genuinely useful information about what we're collecting and why.

The Real Insight: Pathological Support Patterns

The term "pathological customers" stuck with me. It's not cruel—it's observational. Some users will email endlessly once they discover you answer personally. They're not more valuable customers. Their subscription pays the same. But they extract exponentially more effort.

The Castro team realized they were optimizing for the wrong metric: engagement with support, rather than customer success or retention. Those are different things. The person who emails you twice about pricing isn't more loyal—they're just more demanding.

What I'm Doing Differently Now

I've restructured how we handle support into tiers:

• Tier 1: Automated responses for common patterns (pricing questions, general features). Clear FAQ links.
• Tier 2: System-routed bug reports that feed into our telemetry. No individual email responses unless we identify a critical issue.
• Tier 3: Actual weird edge cases and genuine account issues that need human intervention.

I respond personally to maybe 5% of what comes in, and those conversations are usually productive. The rest? They get good self-service documentation and transparency about how we route issues.

My Take

The Castro founder's mistake wasn't caring about customers—it was treating support as a relationship-building mechanism when it's actually just a problem-solving channel. You can't build loyalty through support. You build loyalty through product quality, fair pricing, and clear communication.

The hardest lesson: sometimes the best customer service is doing the work to not need support emails in the past place. Better docs. Better UX. Better onboarding. That's where your energy should go, not in thoughtfully explaining why you won't solve a problem.

What About You?

How are you handling support in your product? Are you doing the exhausting, unsatisfying work of responding to everything personally, or have you built systems that actually scale? I'm genuinely curious if anyone's found a middle ground that doesn't drain you.

Source: This post was inspired by "Castro Podcasts — Things I got wrong: Support" by Dev.to. Read the original article