Bates's postmortem argues that Castro's white-glove support did not translate into meaningful retention, referrals, or upgrades. Users who wrote in were already engaged power users on the tail — not the median customer whose churn actually determined the business outcome.
By submitting the postmortem and driving it to 205 points, dabluck amplified the argument that indie-dev support-as-growth wisdom deserves scrutiny. The submission framing centers Bates's blunt conclusion that relationship-building through support didn't pay off as hoped.
The editorial highlights the uncomfortable mechanic: people who email support are self-selected as the most engaged users, so their gratitude creates a visible feedback loop while the fifty silently churning users remain invisible. This selection bias corrupts the feedback signal that founders use to justify continuing to over-invest in support.
The editorial situates Bates's finding against a long tradition — Basecamp posts, Indie Hackers threads, conference talks — that treat exceptional support as the core moat of indie SaaS. It argues Bates isn't debunking the practice as a lie but exposing it as a survivorship narrative that has been mistaken for a repeatable strategy.
Oliver Bates, one of the people behind the Castro podcast app, wrote a candid postmortem on what he got wrong running the company — and the section that hit hardest on Hacker News (205 points, top of the front page) wasn't about pricing or product strategy. It was about customer support.
Castro was, for years, the podcast client people pointed at when they wanted to say "indie devs still make great software." A small team, a distinctive queue-based UX, a paying user base. Part of that reputation came from support: they answered emails personally, they dug into edge cases, they treated every ticket like a chance to turn a user into a fan. The bet — an article of faith in indie SaaS circles — was that this would compound into loyalty, word of mouth, and low churn.
Bates's blunt conclusion: it didn't. The users who wrote in and got white-glove treatment weren't meaningfully more likely to stick around, refer friends, or upgrade. The support channel was a signal about the tail — power users, edge cases, people with unusual setups — not the median customer whose retention actually determined the business.
The "support as growth engine" thesis has been repeated so often in the bootstrapper canon that it functions as received wisdom. Every Basecamp blog post, every Indie Hackers thread, every conference talk about "how we built a $1M ARR business without VC" leans on some version of *we treated customers like humans and they rewarded us*. Bates isn't saying that's a lie. He's saying it's a survivorship story dressed up as a strategy.
Here's the uncomfortable mechanic: the people who email support are the people who care enough to email support. They're already engaged. Delighting them feels like it's moving the needle because you can see the reply — "wow, thanks for the fast response!" — and you can't see the fifty users who churned that same week without ever opening the support form. Selection bias eats the feedback loop alive.
The pattern shows up everywhere once you look for it. Founders talk about how NPS from support interactions is sky-high, while their cohort retention charts quietly decay. They cite the one power user who tweeted glowingly after a bug fix, without noticing that user was already a paid annual subscriber and would have stayed anyway. Support becomes a comfort activity — real work, real gratitude, real relationships — that also happens to be measurable, unlike the harder questions about why the product isn't sticky enough for the people who never bothered to complain.
What Bates is describing is a version of the classic "you're optimizing for the users you have, not the users you're losing." The signal from support tickets tells you what your engaged users want more of. It tells you almost nothing about why someone downloaded the app, used it twice, and never came back. Those users don't file tickets. They just leave.
The HN comments on Bates's post are worth reading because they surface the counterargument — that great support is a hygiene factor, not a growth lever. It's table stakes for keeping the users you'd otherwise keep anyway; it doesn't create new retention that wouldn't have existed. That framing lines up with what the churn data seems to show: support quality prevents catastrophic exits (rage-quit users who tell their friends), but it doesn't move the base rate of "this just isn't for me."
If you're running a small SaaS or indie product, the actionable read is not "stop doing support." It's "measure whether support is doing what you think it's doing before you scale the headcount."
Concretely: segment your retention cohorts by whether users ever contacted support, and compare 6- and 12-month retention against a control of similar users who didn't. If the delta is small — and Bates's suggestion is that for most products it will be — then the support hours you're pouring in are a cost center, not a moat. That's fine. Cost centers can be worth it. But you should know which one you have.
The second implication is about where the effort should go instead. If churn is happening silently, in the first week, from users who never engaged the support surface, then the leverage is upstream: onboarding, activation, the first-week experience. Instrument the funnel where the leaks actually are. A tool like PostHog or Amplitude, wired to your billing events, will tell you more about retention drivers in an afternoon than a year of reading support tickets will.
The third — and this is the one that stings for indie devs who take pride in craft — is that the emotional payoff of great support is real but shouldn't be confused with product-market fit. Answering a heartfelt email at midnight feels like the business is working. It's often what the business does *instead* of working. If your support inbox is your primary source of "users love us" evidence, you're reading a filtered feed of your most tolerant customers.
The indie-SaaS playbook is due for a rewrite on this point. Support is a virtue, not a strategy — a way to treat people well, not a mechanism that reliably converts into growth. Bates's postmortem is useful less because it's a novel insight and more because someone who did the thing, for years, at a product people admired, is willing to say out loud that the ROI wasn't there. Expect more founders to start actually measuring this, and expect the resulting numbers to be quieter than the marketing has been.
The key point of the article is this:> In other words, the best approach for us is what most companies do.Every inexperienced entrepreneur starts with a promise that their support will not be terrible like Google, Comcast, or other big companies. And that will be their path to success.But in the
I know this isn’t a very interesting comment, but just to provide some balance to the mostly negative comments I’m seeing:It’s interesting that you did the experiment, and I appreciate you sharing your results. It all seems reasonable, even if a bit depressing.
Thinking about customer support as a ‘differentiator’ or a way to drive profit is depressing. You should simply strive to do what’s best for your customers. The sort of feedback you’re getting is golden and in the right hands can be put to use rather than be dismissed. Assuming that people who disag
When I was in college, I worked at a bakery and actually made some long-term friends by talking to customers that came into the store. I later used this job experience to get an email support job, answering questions that users had about our software plugin. Never made any long-term friends with cus
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
>I’ve rarely gotten useful answers from support from services I use. I thought if I used my own product every day, read every email and answered it thoughtfully, people would appreciate this, and it would build some degree of loyalty and appreciation.I run an app with 16,000 users and receive 2–5