Why I Still Do Customer Support Myself
Six products, no support team, every ticket comes to me. I could change that. I haven't, and the reasoning is more specific than just budget.
Every support request across six products comes to me directly. No ticketing system with tiers, no contractor triaging the easy ones, no canned-response bot filtering what reaches me. I could change that — the budget case for outsourcing at least the simple stuff is real, and I've thought about it more than once. I haven't done it, and the reasoning is more specific than "I can't afford help."
What Doing It Myself Actually Catches
The complaint that's really a design problem. A support request phrased as "how do I do X" is sometimes actually telling you that X shouldn't require asking in the first place. A support person working from a script answers the literal question and closes the ticket. Answering it myself means I notice, fairly often, that the real fix isn't a better answer — it's removing the reason someone had to ask.
The pattern across products that a single ticket queue would never surface. Because I'm the one reading every message across all six products, I notice when the same category of confusion shows up in two unrelated apps — which usually means it's not a product-specific issue, it's a pattern in how I tend to build a certain kind of interaction, and that's a different, more useful thing to learn than fixing either instance individually.
Tone that a canned response can't read. Some support messages are a minor annoyance. Some are someone genuinely frustrated after multiple failed attempts to make something work. Those need different responses, and reading that difference correctly is exactly the judgment call a first-tier support process is usually built to skip past in the name of speed.
What It Actually Costs
I won't pretend this scales cleanly, because it doesn't. A rough week across six products is a genuinely rough week, and there's no tier absorbing the overflow when volume spikes. I've had stretches where support took a real bite out of time I'd rather have spent building, and there's a version of this where a contractor handling the routine 80% would free up meaningful hours.
Why I Haven't Made That Trade
The honest answer is that the 80% that looks routine is exactly where the design-problem signal and the cross-product pattern actually live. A support layer optimized for fast resolution is optimized to make the routine stuff disappear quickly, which is precisely the thing I don't want to happen to it, because disappearing quickly is different from actually being addressed. The routine tickets aren't noise I need filtered out. They're the input I'd be giving up.
There's also a smaller, less structural reason: the person who emails a solo indie studio and gets a reply from the actual person who built the thing has a different relationship to the product than someone routed through a ticket system. I don't know how to put a number on that, but I've had enough people mention it unprompted that I believe it's real, and it's not something a well-run support tier reproduces even when it's doing its job well.
Where I'd Actually Draw the Line
I'm not against getting help with this forever — if volume genuinely outgrows what one person reading everything can sustain, that's a real constraint I'd have to solve for. What I'd resist is outsourcing the routine tickets specifically because they're routine, while keeping the interesting ones for myself. That split assumes the routine ones aren't worth my attention, and that's exactly the assumption I think is wrong.
The Bottom Line
Doing support myself across six products isn't a cost-saving measure I haven't gotten around to fixing. It's a deliberate choice to keep the channel that surfaces design problems, cross-product patterns, and real tone open, even though it's genuinely expensive some weeks. The routine tickets look like the ones worth delegating first. They're actually the ones I'd miss the most.