When to hire your first tech: what has to change operationally before you do

Most one-person and two-person MSPs think about their first hire as a revenue question: can I afford another salary. That's a real constraint, but it's usually not the binding one. The binding one is operational: if everything about how you run client accounts lives in your head, a new hire's first month is spent learning to think like you, not doing billable work.

A more useful signal than "can I afford it"

• You are the single point of context for every client — if you're out for a week, tickets wait for you specifically, not for "the team," because there is no team's worth of shared context yet.
• Client-specific knowledge — network layouts, past incidents, who's allowed to approve what — lives in your memory, a notes app, or a folder structure only you fully understand.
• You're turning down work not because you lack the skill, but because there are only so many hours in a week that one person can be the tech, the biller, and the security officer at once.
• These are the signals worth watching. Revenue tells you whether you can pay someone; these tell you whether a new hire will be productive in week two instead of week eight.

What has to exist before a second person is useful, not just busy

• A shared system of record — one place where a ticket, a device, and a client's history live, instead of your personal notes app and their institutional memory of "just ask the boss."
• Documentation attached to the account or device it describes, not filed in a separate wiki a new hire has to be told to check.
• Role-based access that's actually scoped — a new tech gets exactly the access their role needs on day one, not your login shared over Slack because setting up a second account felt like overhead.
• SLAs and priority definitions written down somewhere, so "this is urgent" means the same thing to a new hire as it does to you, without a phone call to confirm.

Hiring before you've systemized turns training into a bottleneck instead of a multiplier — the new person waits on you for context you never wrote down.

This is a big part of why we built role-based access, IT documentation attached to the record it describes, and a real staff portal into Nexus from the start, rather than as an "enterprise tier" bolted on once a team gets big. A platform that only starts helping once you have five techs isn't helping you decide whether to hire the second one — see the platform page for how the pieces fit together at any team size, including one.