The Miscalculation of Human-Centric Support

When I first acquired Castro, I operated under a specific hypothesis:

I believed that providing high-touch, human-driven support rooted in actual user experience would serve as a powerful differentiator.

My logic was simple. Most of the time, when I contact support for other services, the answers are useless. I figured if I used the product daily and responded to every single email with genuine thought and care, users would feel a sense of loyalty. I wanted them to feel that their subscription fees were funding a real person who actually cared about their experience.

As the volume of emails grew, I recruited a power user—someone who seemed to understand the app as well as I did—and paid him to help manage the queue. He was excellent at solving technical problems, but the overarching strategy still failed.

Expectation: Thoughtful answers $\rightarrow$ Customer Loyalty Reality: Thoughtful answers $\rightarrow$ User Annoyance

While we occasionally "wowed" someone with an instant fix, the majority of our honest, detailed responses were viewed as deeply unsatisfying.

Analyzing the Support Pipeline

To understand why this failed, I categorized our incoming requests. Here is the breakdown of the "support trap":

1. Subscription and Pricing Grievances

I have spent a vast amount of time thinking about our pricing model. I can explain why the app is essential, why it's worth the cost, and why the subscription model is the most sustainable way to build software.

However, in two years, I found exactly one person who was simply surprised that software costs money. For the other $99\%$, no matter how kind the explanation, the response was worse than the initial complaint. I even tried offering extra 30-day trials, but the conversion rate was low and the sentiment remained negative.

Mathematically, the probability of building rapport via pricing disputes is: $P(\text{Rapport}) \approx 0$

2. The Bug Report Spectrum

Not all bugs are created equal. I categorize them as follows:

• The "Quick Win": We know the bug, it's fixed, but the App Store hasn't distributed the update yet. These are the only emails that actually satisfy users.
• The "Ghost": We've heard it, but we can't replicate it. This is a waste of time for everyone.
• The "Low Priority": We know it exists, but it's a massive amount of work for a tiny number of users.

In the latter two cases, an honest human response—explaining why I can't or won't fix the problem today—is actually the worst thing a user can hear. We usually have better data from crash logs and telemetry than we do from these emails anyway.

3. Nuanced Intervention & General Confusion

Occasionally, we get highly specific requests (e.g., a user with two different accounts trying to merge subscription time). These are rare but necessary.

However, there is a darker side: users who are genuinely confused about how the App Store or their own Mac works. Once these users realize we provide detailed, human answers, they email more frequently. I believe Patrick McKenzie calls these pathological customers. You end up spending the most time on the people who provide the least relative value and are the hardest to satisfy.

4. Feature Requests and "The Roadmap"

This is a dangerous game. Castro is an opinionated app. If I cater to the "persnickety" power users who email me, I risk ruining the experience for new users.

If you implement one suggestion from a power user, they will likely try to send you their entire envisioned product roadmap.

Final Reflections

In hindsight, it should have been obvious: Honesty is not the same as satisfaction. Telling a user "I've thought about this and decided not to do it" is a truthful, human response, but to the user, it is a failure. Building rapport through support is a seductive idea that, in practice, often just creates a burden for the developer and a disappointment for the customer.