The Factory Problem with Customer Support — How to Support 220 Apps

The standard support model for a SaaS is: headcount scales with customer count. 1 CS rep per 200-500 customers. At the scale of 220 apps with (eventually) tens of thousands of customers, we would need a team of 20+ CS people.

We have two founders. Jess handles crafts, I handle software. Neither of us is a full-time support person. This has to work a different way.

The Three Rules

Everything about how we handle support flows from three rules:

1. Most apps never generate tickets. This is the single most important fact. If every app generated 1 ticket/month per paying customer, we'd be dead. Most apps generate near-zero tickets because the apps are simple, do one thing, and don't break.
2. Self-host users get no support. Not "bad support." None. Their channel is GitHub issues, which are public, low-urgency, and async. If they pay $0, we owe them $0 of synchronous support.
3. Hosted Pro customers get email support only. No phone. No chat. No SLA. We respond within 1-2 business days. That's the contract.

These rules are stated clearly on every pricing page. Customers who need phone support or 4-hour SLA don't buy. Customers who are fine with async email do.

The Triage System

Every support email hits tim@dangercorn.net or support@dangercorn.net. Our triage is automated via a classifier that runs in dcch:

class SupportClassification(BaseModel):
    vertical: str           # which app
    urgency: str            # "critical", "high", "normal", "low"
    category: str           # "billing", "bug", "feature-request", "how-to", "spam"
    suggested_response: str # if "how-to", a drafted response

response = dcch.complete(
    system=SUPPORT_TRIAGE_PROMPT,
    messages=[...email body...],
    json_format=SupportClassification,
)

Every incoming email gets classified. Urgency "critical" (data loss, payment issue) pings my phone. Urgency "high" (significant bug) goes to Discord for me to see within an hour. Urgency "normal" waits for my 7 AM and 7 PM triage passes. Urgency "low" and spam get filed without alerting me.

This simple triage removes most of the cognitive load. I'm not seeing every support email; I'm seeing the ones that matter, in the order they matter.

Response Templates

For every common question across the portfolio, we have a canned response. "How do I restore a backup?" "How do I change my AUTH_PASSWORD?" "My Stripe webhook isn't firing." There are ~45 canned responses covering 70% of incoming tickets.

The Claude-assisted draft from the triage step often pulls from these templates. I review it, tweak it if needed, send. Average response time from classification to send: 3-5 minutes.

Self-Host Support Scaling

Self-host users don't get email support — but many of them still want help. Their channel is GitHub issues on the public repo for their vertical. This has several effects:

• Public resolution. The next person with the same issue searches the issues and finds it. The answer scales.
• Community help. Other self-host users help each other. I see issues resolved by strangers who've hit the same thing.
• Bug surfacing. Real bugs surface in public, which puts pressure on us to fix them. It also means we can't quietly ignore them.

This is the same pattern every open-source project uses. It scales sub-linearly because the knowledge base self-grows.

The Long Tail

Support volume is heavily concentrated. Across the portfolio, the top 5 apps generate 40% of tickets. The bottom 100 apps generate maybe 5% combined. When we add a new app, we're adding close to zero support volume.

The verticals that generate the most tickets:

1. dentaldesk — highest-stakes data, highest-value users, highest question-density.
2. breweryops — TTB reporting is critical; any error generates immediate urgency.
3. vacaypro — STR hosts are operational-anxiety users; every weird thing is a question.
4. agentdesk — real estate transactions have real money tied to timing.
5. inkbook — deposit disputes are both rare and high-urgency.

These five verticals get more careful documentation, more pre-flight validation in the code, and more proactive health-check alerts than the median vertical. Putting attention where tickets come from is the highest-leverage support optimization.

Proactive Monitoring

Every Hosted Pro instance has health checks that ping our monitoring endpoint on Johnny-5. If an instance is unreachable for 5 minutes, I get alerted before the customer does. "Your vacaypro is back up; it was down for about 6 minutes. Cause was X. Sorry for the inconvenience" — sent proactively — converts a potential angry ticket into gratitude.

About 60% of incidents are caught and notified before the customer noticed. The other 40%, we respond to inbound. Both groups get the same quality of acknowledgment, just different timing.

Feature Request Handling

Feature requests are the biggest source of volume we push back on. Every request gets:

1. Logged in the vertical's roadmap document.
2. Acknowledged to the requester with "thanks, we'll consider it."
3. Implemented only if it shows up 3+ times across customers, OR if I/Jess use the feature ourselves.

This sounds cold. It's disciplined. Most features that sound great in one email fade on scrutiny. The ones that matter recur.

Refund Policy

No-questions refund for the first 30 days. After 30 days, pro-rated refund for the unused portion of the month. After 60 days, no refund unless there's a bug that made the product not work.

Cost to the business: negligible. Refund rate across the portfolio: under 2%. The policy exists because a customer who asks for a refund and gets stonewalled is a customer who writes a bad review. Paying $39 to avoid a bad review is obvious math.

The Saturday Test

Every Saturday, I spend 2 hours on support. If I can clear the weekend's inbox in 2 hours, the system is working. If it's taking 4+ hours, the system is breaking somewhere — usually a specific vertical generating unusual volume — and I need to fix the root cause that week.

This is my load indicator. It's not perfect, but it catches problems before they compound.

Customer support at portfolio scale is not about responding faster. It's about needing to respond less. Documentation, templates, automation, and thoughtful product design remove tickets before they're filed.

Related

Hosted vs self-host economics. The 220-app thesis. The Claude wrapper that powers triage.

The Cultural Piece

Nothing in this post is technical. The triage system is small. The templates are obvious. The proactive monitoring is standard. What's hard about supporting 220 apps with 2 founders is the discipline — the willingness to say no to feature requests that don't recur, to set explicit expectations on response time, to refund customers rather than fight, to keep documentation current. The technical side is easy; the cultural side is where most teams collapse.

What protects the culture: writing this stuff down. The pricing-page promises ("email support, 1-2 business day response") are real contracts. Customers who buy in know what they're signing up for. Customers who need more either pay for an upgrade tier or, more often, find a different vendor. Both outcomes are correct.

The hardest part isn't supporting the customers we have. It's saying no to the customers we shouldn't take in the first place.