--- slug: customer-support-solo-founder title: "Doing Customer Support as a Solo Founder" excerpt: "Customer support as a solo founder is the unsexy job that makes retention. Inbox patterns, the three macros that handle 80% of tickets, and when to reply by hand." primaryKeyword: "customer support solo founder" publishedAt: 2026-09-01 readingTimeMin: 7 author: "Robert Boylan" tags: - customer-support - retention - indie-dev - solo-founder - operations --- Eight users emailed you in the last 24 hours. You're also trying to ship the feature you promised would go out today. The tab in your inbox is at twelve unread; you keep meaning to "do support after lunch" and it's now 9 PM. This is the customer support state for every solo founder, eventually. The product is real enough that users have problems, and you're still one person. The instinct is to either stop building and answer everything immediately, or batch it all to one giant Saturday session and arrive at the inbox with nothing left to give. Both fail. Customer support as a solo founder is the unsexy job that quietly decides retention, and there's a sustainable shape for it that doesn't require hiring or starving the roadmap. ## What customer support actually does for an indie SaaS You're not just answering questions. Every reply is also doing four other things, whether you notice or not. It's **product feedback**. Every "how do I X" is a usability gap. Every "I expected Y" is a missed assumption. If you read your inbox like a product manager, the roadmap usually reorders itself. It's **retention work**. Users who get a fast, human reply convert into longer subscriptions and word-of-mouth at rates no marketing can match. The opposite is also true: users who get ignored quietly cancel and never tell you why. It's **a competitive advantage**. In a category dominated by chatbots and ticket queues, "the founder replied within an hour" is a feature that bigger companies cannot match. Lean into it while you can. It's **the world's best CLAUDE.md generator for your AI tools**. The most common questions tell you exactly what to document, what to clarify in the UI, and what to add to onboarding. If you think of support as a thing that gets in the way of shipping, you'll resent it. If you think of it as a thing that helps you ship better, you'll be relieved to do it. ## Where the inbox actually lives A typical indie SaaS gets support over three channels: email (the main one), in-app contact form (which dumps to email), and Twitter/X mentions. Sometimes Discord, sometimes a public Slack, sometimes a feedback widget. The principle: **consolidate to one inbox.** Pick a single tool that aggregates everything. The contenders for a solo founder: - **Just Gmail** with a `support@yourapp.com` alias forwarding to your main inbox. Free, works fine until you're at maybe 30 tickets a week. - **Help Scout** ($25/user/month). Designed for support, has macros, satisfaction surveys, the works. Standard for small teams. - **Plain** ($35/seat). Newer, cleaner, designed for technical products. - **Tabbie / Anthrop tools** are emerging. Worth checking if you start a fresh setup now. Don't overthink it. Gmail works longer than you think. Move when the volume actually hurts, not before. The cost of a real support tool isn't just dollars; it's another thing to learn and maintain. What matters more than the tool: the inbox has one consistent address, you check it on a schedule (not constantly), and you have a way to flag tickets that need real engineering work versus tickets that need a reply. ## The three macros that handle 80% of tickets For any SaaS under a thousand users, three or four reply templates cover most of the inbox. Write them once, save them somewhere accessible, and customise lightly per reply. **The "I can't log in" macro.** Roughly 25% of all support tickets, every product, forever. The reply checks the three usual causes: did the verification email land in spam, did they sign up with a different email than they remember, has the password reset arrived. Template the reply with all three checks; nine times out of ten one of them is the problem and the user resolves it themselves. **The "how do I do X" macro.** A pointer to the right help doc or feature, plus a short personal sentence. The personal sentence matters more than the link; it turns "you didn't read the docs" into "thanks for asking, here's exactly where to look." **The "I think it's broken" macro.** Asks one specific question (browser, OS, exact step taken) that gathers what you need to debug. Add a sentence acknowledging the frustration. This template buys you the information you need without sounding bureaucratic. **The "feature request" macro.** Thanks the user, says you've added it to the roadmap, and (if true) tells them you've seen it before so they know they're not alone. Don't promise dates. Don't say no flatly. "Adding to the list" is honest and lands well. Together, those four templates cover roughly 80% of the inbox for a typical indie SaaS. They take the reply from a 15-minute compose to a 90-second customise. The trap to avoid: don't just paste the macro and hit send. Personalise the first sentence. Use the user's name. Reference something specific they said. The 30 extra seconds of personalisation is what makes the reply read like a founder reply instead of a chatbot reply. ## When to reply by hand instead of by macro A macro is right for the common questions. A hand-typed reply is right when: - **The user is upset.** A macro sent to an angry user is gasoline. Slow down. Read carefully. Reply with the specifics of their case. - **The request is genuinely new.** First time you've heard about a feature or a bug? That's a thoughtful reply, with follow-up questions, not a templated brush-off. - **The user is a power user or paying for a premium tier.** Lifetime value matters. Effort scales with it. - **You can see something useful in the question that the macro misses.** A "how do I X" that hints at a deeper misunderstanding deserves the longer answer. You will know when a ticket needs the hand-typed reply because it bothers you to use the template. Trust that instinct. ## Inbox patterns that actually work Two batches a day beats constant checking. Once mid-morning, once late afternoon. Reply to everything in each batch (no "I'll get to that later" leaving the inbox). Anything that requires real engineering work gets a "thanks, I'm digging in, will update you within 24 hours" reply and a task in your tracker; the ticket goes into a "needs work" state and the inbox is otherwise empty. This is sustainable. Constant checking is not. The dopamine cost of "let me just refresh the inbox" is the same as social media; you'll think you're doing support, you'll actually be procrastinating. Set expectations in your help docs and signup emails. "We're a small team. We reply to support tickets within one business day." If you're a solo founder, write "I'm a solo founder. I reply within one day." Honesty here helps; users who know it's one person are dramatically more patient than users who think it's a faceless company. When you go on holiday, set an autoresponder that's also honest. "I'm away from [date] to [date]. Replies will be slower. For urgent billing issues, here's the auto-route." Users respect this almost universally. ## Mining the inbox for product work The job everyone forgets: every couple of weeks, scroll back through the inbox and tag patterns. If the same question appeared eight times, the UI is wrong. Don't write a help doc; fix the UI. A help doc is the second-best fix for a confusing screen; redesigning the screen is the first. If a feature request appeared from five different users, surface it on the roadmap. Even better, reply to all five at once with "you asked for X, we shipped it, here's how to use it." Those five users will be lifelong supporters. If a bug keeps coming back, write a regression test for it. The AI tools are good at this; describe the bug and what should not happen, and let Cursor or Claude Code write a test that asserts the fix sticks. [Adding features to your AI-built app over time](/blog/maintain-vibe-coded-app) covers more on the regression test pattern. The inbox is the highest-quality product feedback channel you have. It's free. It's specific. It's labelled with how angry the user is. Don't waste it. ## Specifying the support flow in the build Customer support is a part of the product, not an extra layer on top. Plan it in. Things to capture in the project spec: - The address (`support@yourapp.com`) and where it forwards to - The signup email's mention of support and the one-day reply expectation - An in-app contact form on the settings page that emails the same inbox - The autoresponder copy - A simple admin page (or just a database query) that lets you find a user by email when they write in (you'll need this constantly) If these are in the spec, the AI builds them in the initial scaffold. If they're not, you're hand-wiring "find a user by email" the night of the first ticket. [Draftlytic's project spec](/what-is-a-prd) has a notifications and constraints section where the support flow lands naturally; capture it there before you build, and the support workflow is a feature of the product instead of a fire drill. Doing customer support as a solo founder is one of those tasks you'll dread and then quietly come to like. Every reply is product feedback, retention, and a free conversation with a person who chose to use your thing. Two batches a day, four templates for the common stuff, hand-typed replies for the harder questions, and a habit of mining the inbox for patterns. That's the whole shape of it. Most of indie SaaS is patient compounding work; the inbox is the most consistent place to do that work, and the most reliable place to see it pay off.