There’s a specific, uncomfortable stretch in almost every founder’s timeline: too busy to do everything well, not yet sure hiring is affordable, and worried that bringing someone else in will slow things down before it speeds them up. Nearly everyone running a real business hits this stretch. Very few think clearly through it, because the decision gets made emotionally — from burnout, or from fear — instead of from a test that actually answers the question.
The bottleneck test
Before hiring anyone, answer one question honestly: what specific activity, if it disappeared from your plate tomorrow, would let revenue grow fastest? Not “what do I dislike doing” — what’s actually constraining growth right now. If the honest answer is “nothing, I have plenty of time and things just aren’t working yet,” you don’t have a hiring problem, you have a channel or retention problem, and a hire won’t fix either. Hiring solves capacity constraints. It does nothing for a strategy that isn’t working yet — it just adds payroll to a business that hasn’t found its footing.
If the honest answer is specific — “I’m the only one answering support tickets, and it eats three hours a day I could spend on outreach” — you’ve found a real bottleneck, and it’s telling you exactly what role to hire for. This is the entire method. Founders overcomplicate hiring by imagining org charts and job titles before they’ve done this five-minute test even once.
The three roles almost every solo operator needs, in order
There’s no universal hiring order, but running a business on top of a Good Kulture engine — where the product itself needs no engineering hire to exist — tends to produce the same bottleneck sequence for most founders.
First hire: customer support or operations. This is almost always the correct first hire, because support work is time-consuming, repeatable, and — crucially — teachable from clear documentation, since the engine’s admin console and standard workflows are the same for every buyer. A support hire frees your highest-value hours (talking to prospects, refining the product experience, watching the metrics) from your lowest-leverage ones (answering the same three questions repeatedly). This role also doubles as your best source of product intuition — someone who reads every support ticket learns your customers’ pain points faster than you will from a dashboard.
Second hire: growth or sales support. Once your one channel has a proven, repeatable motion — you can describe exactly what produces a customer — a second hire can execute more of that same motion in parallel with you, rather than you being the sole bottleneck on volume. Hiring for growth before you have a proven motion just means training someone on your own unproven guesswork, which rarely goes well and is expensive to discover.
Third hire, much later: anything specialized — design, deeper technical customization, finance. By the time you need this hire, you’ll know exactly what it is, because a specific, recurring gap will have made itself obvious through the first two hires’ work. Resist naming this role in advance; let the business tell you what it needs.
Hiring without an HR department
You don’t need a formal hiring process to hire well — you need three disciplines most solo founders skip because they feel like overhead when actually they’re what prevents an expensive mistake.
Write down the job before you look for the person. Three sentences: what this person does day to day, what a good outcome looks like after 90 days, and what skill or trait is non-negotiable. This alone filters out most bad hires, because it forces you to know what you’re hiring for before a friendly, charismatic candidate talks you into believing they’re a fit.
Trial before you commit. A short paid project — a week handling real support tickets under supervision, a real (small) outreach batch — tells you more in five days than any interview will in five hours. This is easier for a solo operator to arrange than it sounds, and it protects both sides: a bad trial costs you a few hundred dollars and a clear “no,” where a bad full-time hire costs months and real money to unwind.
Document as you go, from hire number one. The reason a support hire works well from a Good Kulture engine is that the workflows are consistent and repeatable — write them down as a simple checklist the first time you do them yourself, before you ever hire, so onboarding a new person takes a day instead of two weeks of you explaining things from memory. This single habit is the difference between hiring feeling risky and hiring feeling routine by your third or fourth person.
What early hiring actually costs you, beyond salary
The real cost of an early hire usually isn’t the paycheck — it’s the training time, the mistakes while they’re ramping up, and the cash-flow risk of a fixed monthly cost against revenue that hasn’t yet proven durable. Weigh a hire against the alternative: could you solve the same bottleneck with a part-time contractor, a few hours a week, before committing to a full role? Could better documentation or a small process fix reduce the bottleneck enough to buy another few months of solo operation? Hiring is a tool for a real, measured constraint — not a milestone to hit because it feels like what a “real business” does.
The mindset shift that actually matters
The hardest part of the first hire usually isn’t logistics — it’s a founder’s instinct that no one else can do this as well as they can, at least not yet. That instinct is often literally true, and also irrelevant: the question isn’t whether you’re the best person to answer a support ticket, it’s whether your time is worth more spent somewhere else. A founder who insists on doing everything personally forever isn’t protecting quality — they’re capping the size of the business at exactly what one person’s hours can produce. Your first hire is the first real test of whether you’re building a business or building yourself a very demanding job. Pass that test, and every hire after it gets easier, because you’ll already have the documentation, the bottleneck instinct, and the trial process that made the first one work.