You Don't Need a Support Team Yet. You Need a Shared Inbox and a Rotation.

Every founder I've worked with hits the same wall around the same time. Customer questions start landing in the founder's personal inbox. Then in a Slack channel. Then in three Slack channels, a WhatsApp thread, and a Notion page nobody updates. It feels chaotic, so the instinct kicks in: hire a support person to make the chaos go away.

Resist it.

If you have fewer than twenty engineers, you almost certainly don't have a support problem. You have a routing problem and a discipline problem. Those are cheap to fix. A dedicated support hire is not, and hiring one too early quietly removes the single most valuable thing you have at this stage: engineers who actually know what your customers are struggling with.

I've built support functions from nothing more than once. The pattern that works early is boring and almost free. A shared inbox, a rotation, and an SLA you can genuinely meet. That's it. Let me walk through why, and how to know when the boring setup has run out of road.

Keeping engineers close to customers is a feature, not a bug

Here's the thing nobody tells you. In the early days, the friction of engineers handling support is doing real work for you.

When an engineer answers a customer ticket, they feel the bug. Not a Jira summary three days later with the urgency sanded off. They feel it directly: the customer is confused by the same onboarding step, again, and now it's their afternoon being eaten by it. That feeling is the most reliable prioritisation signal a young product has. It cuts through roadmap debates faster than any planning meeting.

Hire a support person too early and you build a wall. The support person becomes a shock absorber. They get good at calming customers down and writing apologetic replies, which means the underlying problem stops hurting the people who could actually fix it. The ticket volume stays high, but it goes quiet inside the company. You've optimised for the symptom and hidden the disease.

I've watched this happen. A team hires support at eight engineers because tickets feel overwhelming. Six months later the product still has the same five recurring issues, because nobody on the engineering side ever felt enough pain to kill them. The support person, meanwhile, is drowning, and the obvious "solution" is to hire a second support person. Now you have a department papering over bugs that two days of engineering would have eliminated.

Early support contact is market research you are getting for free. Don't outsource it before you've extracted the value.

What the setup actually looks like

You need three things. None of them require new headcount.

A shared inbox

One address. support@ or help@. Every customer-facing channel funnels into it. The founder's personal inbox stops being a support queue today. The scattered Slack channels get a pinned message that says "for anything that needs a fix, email support@."

Use a real shared inbox tool, not a forwarding rule. Something like Front, Help Scout, or even a shared Gmail with assignment if you're scrappy. The non-negotiable features are simple:

• Assignment, so a ticket has exactly one owner and you can see it.
• Status, so you know what's open, what's waiting on the customer, and what's done.
• Visible history, so the next person doesn't ask the customer something they already answered.

That's the whole requirement. Resist anyone trying to sell you a full ticketing platform with workflows and macros and CSAT surveys. You don't have the volume to justify the configuration time, and you'll spend two weeks tuning a system that should take an afternoon.

A rotation

Pick one engineer per week to be on support. That's the on-call person for customer issues. They triage the shared inbox, answer what they can, and pull in whoever owns the relevant code for the rest.

A few rules that make this survivable:

• The on-call engineer's sprint commitment is cut roughly in half for that week. Support is their job this week, not a tax on top of their real job. If you don't formally lighten their load, the rotation becomes punishment and people start dreading it.
• One person, one week. Long enough to see patterns, short enough that nobody burns out. Daily rotations are too choppy; people never get context.
• It includes the founders and the senior people. Especially early. If the CTO is too important to do a support week, that's a culture signal everyone reads correctly, and the rotation dies.

The rotation does something a dedicated hire can't: it spreads customer knowledge across the whole team. Everyone learns where the product is sharp. Everyone develops an instinct for what breaks. That instinct compounds.

An SLA you can actually meet

The most common mistake here is promising "we respond within one hour" because it sounds impressive, then missing it constantly and training your customers to distrust you. A missed SLA is worse than no SLA.

Set something you can hit on your worst day, not your best one. Early on that might be:

• First response within one business day for normal issues.
• Within a few hours for anything that blocks a customer from using the product.
• Immediately, paged, all-hands for an outage. That's a separate track and you should treat it as such.

Notice the SLA is about first response, not resolution. You can almost always reply quickly to say "I've got this, looking now." What you can't always do is fix it in an hour. Promise the thing you control.

Write it down. Put it where the on-call engineer can see it. Then actually measure whether you're hitting it, even if "measuring" is just eyeballing the inbox on Friday. The number matters less than the honesty.

Be honest about the failure mode of hiring too early

Let me be blunt about what hiring support too early actually costs, because the downside is bigger than people expect.

You're not just spending a salary. You're inserting a layer between your engineers and your customers at exactly the moment that connection is most valuable. You're giving your team permission to stop caring about support quality, because "that's the support person's job now." And you're hiring into an undefined role, because at eight engineers you don't yet know what good support looks like for your product. The person you hire will invent the role themselves, and you'll inherit whatever they build, whether or not it fits.

There's also a morale trap on the other side. The support hire arrives expecting a function, a process, a manager. Instead they get a firehose, no documentation, and engineers who treat them as a deflection shield. They burn out or leave inside a year, and now you've got attrition on top of the original problem.

The honest version is this: a support hire is the right move when you have enough volume and pattern to define the job clearly before the person walks in. If you can't write that job down today with real specifics, you're not ready.

The signals that say "now hire someone"

The rotation is not forever. It's the right answer until it isn't, and the transition is real. Here's what tells me a team has outgrown engineers-on-call. You usually see several of these at once, not just one.

Support is eating more than 20% of engineering time, consistently. One engineer at half-capacity each week is a known, planned cost. When the on-call person is fully consumed and spilling over to others, the rotation has stopped being a tax and become the job. Track this even roughly. The day it crosses 20% and stays there, start the conversation.

Response times are slipping and you're missing the SLA you set. Not once during a launch week. Consistently. When your achievable, honest SLA is being missed because there's simply too much volume for the rotation to absorb, the model is out of headroom.

The same person keeps absorbing it. Watch for the engineer who quietly answers everything because they can't stand seeing customers wait. They're doing you a short-term favour and a long-term disservice, because they're hiding the true cost of support inside their own unpaid overtime. When one person has effectively become your support team without the title, you already needed to hire. You're just doing it by accident, badly.

Context-switching is visibly wrecking focus. A rotation works because one person eats the interruptions so everyone else can build. When tickets are urgent and frequent enough that the on-call person can't hold a single thought, and the spillover is dragging others out of deep work too, the protective function of the rotation has broken.

The questions have gone repetitive and operational, not diagnostic. Early support is mostly "this is broken" and "is this a bug?" — engineering questions. When the inbox shifts to "how do I do X," "can you reset my account," "where's my invoice" — that's a support job, not an engineering one. Repetitive operational volume is the clearest sign that a dedicated, non-engineering person would do this better and cheaper than your engineers.

When you see three or four of these together, hire. Not before.

And when you do hire, resist the urge to immediately wall support off from engineering entirely. The handoff is its own discipline — how you keep that customer signal flowing back to the people building the product even after support is a real function. That's a whole topic on its own, and getting it wrong undoes everything the rotation taught you. But that's a problem for later. You have to earn it first.

The bottom line

A shared inbox, a rotation, and an SLA you can actually meet will carry you a remarkably long way. Further than most founders believe.

The setup is almost free, it takes an afternoon to stand up, and it does something no early support hire can: it keeps your engineers feeling the friction your customers feel. That friction is data. It's the cheapest, highest-quality product feedback you will ever get, and the moment you hire it away, it goes quiet.

So don't reach for headcount when the inbox gets noisy. Reach for routing and discipline first. Run the rotation honestly, set an SLA you respect, and watch for the signals. When three or four of them show up together, you'll know — not because it feels chaotic, but because you've measured that the model has genuinely run out of road.

Until then, the boring setup is the right one. Let your engineers stay close to the people they're building for. It's a feature, not a bug.