Support at a team of one.

LADLE is a team of one. Product, code, marketing, ops, and support all funnel to the same person. This post is specifically about support — how it's structured today, what it actually costs in hours, and what would change it.

**How it works today:**

Every email to hello@ladle.chat lands in the founder's inbox. Every one is read and answered by the founder personally, usually within 24 hours, often within a few. There's no ticketing system, no support tier, no first-line agent. The email you send is the email that gets read.

Same for the other support routes: security@ (rare, thankfully), partners@, press@, privacy@. All routes end at the same person.

**Why it's structured this way:**

At current scale, the volume is manageable — a handful of support emails per day, most of which are billing questions ("how do I cancel," "when does my renewal hit") or product questions ("how does the search toggle work"). A handful of technical bugs per week. Occasional larger conversations.

The founder-in-the-inbox model has two advantages worth defending as long as possible:

**Speed of feedback loop.** When a bug report lands, the person who can fix it reads it. There's no game of telephone between a support agent and the engineer. Response time to "we fixed it in the app, refresh" is often under an hour.

**Better product decisions.** Support conversations are the ground truth of what's broken and what's confusing. When the founder does support, product decisions incorporate that ground truth directly rather than through summaries.

**What this DOESN'T scale to:**

100+ subscribers per day of support volume. At that point the model breaks; the founder would spend all day in the inbox and none of it building.

Enterprise-level support expectations (SLAs, phone support, dedicated CSMs). If we ever sold to enterprise, that would be a different product with a different support model, and probably priced accordingly.

24/7 coverage. There isn't any. Emails at 2am get read the next morning. The status page is where you go if the site is down; the marketing page is honest about the support hours (roughly business hours, PST).

**The escape hatches:**

When support volume gets too high to handle solo, the first hire will be a support-focused person. Not "customer success" — actual support who reads the emails, answers what they can, and escalates what they can't. That's coming, not now.

When response quality degrades — when the founder can't read the emails carefully anymore — the second hire is another support person. Volume triggers hire; the trigger is roughly "the last week's emails weren't handled the way the emails from month one were handled."

Until either trigger, one inbox, one person.

**What users can do to help:**

Include specifics. "The composer isn't working" is a slower email to help with than "the composer button is disabled on the chat at /chat/abc123 as of about 3pm PT — screenshot attached, tried refresh."

Send bugs to hello@ (not a support form). No triage layer, no form fields to fill out — just an email that gets read.

If you're mid-conversation and need followup, reply on the same thread. Threading keeps context; new emails start over.

Don't be alarmed by a same-day reply from the founder. It's the model, not urgency signaling.

**What we don't do (and won't):**

Automated support responses. No canned auto-reply that says "your ticket has been received" and then goes nowhere. If we can't answer within a day, you get an actual "still working on this" reply from a human.

Chatbot on the marketing site. Ironic for an AI company, but our own product's whole promise is that it doesn't replace humans where humans do a better job. Support is one of those cases.

Tier-based support (basic users get slower response than paid). Everyone gets the same treatment. If you're on the demo, you still get read.

**The general point:**

A team of one is a constraint, not a stunt. It shapes what LADLE is and isn't. Support is one of the places where the constraint shows up positively — a founder in the inbox is a feature at small scale. The trick is knowing when it stops being a feature and becomes a bottleneck.

Not there yet. When we are, we'll write the next post.