The first person you bring on
changes what your business is.

Purpose & audience

There is a ceiling to what one person can do, and every successful solo business eventually hits it. What happens next — whether you break through, stay put deliberately, or break yourself trying — is one of the biggest decisions a founder makes.

Most of the library is about being an independent software business of one. This guide is about the possibility of becoming more than one. It covers when and whether to hire at all, what kind of help to bring on first, the crucial choice between contractors and employees, the genuinely difficult skill of delegation, how to structure a partnership without it ending badly, and the personal transformation from being the person who does the work to being the person who leads others doing it. Growing a team can multiply what your business can do — or it can multiply your problems. This guide is about doing it deliberately.

It is written for the solo founder who is stretched thin and wondering whether to bring someone on, and for the small firm taking its first steps as a real team. Everything here is generic and reusable, and the employment specifics — contracts, obligations, classifications — vary by jurisdiction and are exactly what to confirm with a professional; the principles of building a team are the same everywhere.

The core principle

The valuation guide warns against building a business that is really just you. This guide is how you stop — and it rests on a hard truth: the first hire doesn't just add capacity; it changes what you are, from a person who does the work into a person responsible for other people doing it — and that is a different job, which many excellent builders find they must consciously learn.

Two failure modes bracket this. The first is hiring too soon or badly — bringing on people before the business can support them, or without the systems to make them productive, and drowning in the cost and management overhead. The second is never letting go — staying a bottleneck forever, either refusing to hire or hiring people you never actually delegate to, so the business stays capped at your personal capacity. The path between is deliberate, well-timed growth with genuine delegation.

Where this sits in the library

You do not have to build a team. Many excellent software businesses are, and stay, one person — a legitimate and often wise choice this library respects (and Scaling — or Staying Small defends). But if you do decide to grow, doing it deliberately — at the right time, with the right first hire, and with real delegation — is the difference between a team that multiplies you and one that merely multiplies your stress.

The right time to bring someone on is a real question with a wrong answer in both directions — too early drains the business, too late caps it. Reading the signals is the first skill.

You are the bottleneck

The clearest signal that it's time to consider help is that you have become the bottleneck — there is more good work available than you can personally do, you're turning away opportunities or burning out to serve them, and the constraint on the business is no longer finding work but your own capacity to deliver it. This is a good problem, and it's the healthy reason to hire: demand exceeds what one person can supply. It's important to distinguish this from hiring out of a vague sense that a “real” business has employees, or to escape work you simply dislike — those lead to hires the business doesn't need. The sound trigger is specific and measurable: consistent, profitable demand that you genuinely cannot meet alone. When turning away good work because you have no hours left becomes a pattern, the bottleneck is you, and it's time to think seriously about help.

Can you afford it?

Wanting help and being able to afford it are different questions, and the second is where premature hires go wrong. A new person — especially an employee — is a significant, ongoing, largely fixed cost that continues whether or not the work does, and the business must be able to carry that cost reliably, not just in the best month.

The first hire is the highest-stakes one, because it sets the pattern and the business can least absorb a mistake. Choosing what role to fill first is a question of leverage.

The highest-leverage gap

The best first hire is usually the one that frees up the most of your time to do the things only you can do — the highest-leverage gap. This is often not another version of you, but someone who takes over a category of work that consumes your hours without needing your specific expertise: the administrative load, a routine part of delivery, the tasks that fill your days but don't require the founder. Handing off the work that eats your time but not your unique skill multiplies your capacity for the work that does require you — winning business, making key decisions, doing the parts customers hire you for. The question to ask is not “what job title should I add?” but “what is consuming my time that someone else could do, so I can focus on what only I can do?” That answer is usually your best first hire.

Hire the weakness or the strength?

A recurring dilemma: do you hire to cover what you're bad at, or to add more of what you're good at? Both can be right, and the choice reveals what kind of business you're building. Hiring to cover a weakness — bringing in someone strong where you're weak, whether that's a skill, or the parts of the business you neglect — shores up the business's foundations and removes a limitation. Hiring to amplify a strength — adding more capacity in what already works well — scales up your success directly. Early on, covering the gap that most constrains the business — often the unglamorous operational or delivery work you're drowning in — tends to free you fastest. But there's no universal answer; the right first hire is the one that most relieves whatever is currently holding the business back, whether that's a weakness dragging it down or a strength it can't fully exploit alone. Diagnose the actual constraint, and hire against it.

How you bring people on — as flexible contractors or committed employees — shapes your cost, your risk, and your obligations. Choosing deliberately, and getting the mechanics right, matters as much as choosing the person.

The spectrum

There is a spectrum of ways to add capacity, and the two poles carry very different trade-offs. Contractors — independent people you engage for specific work or periods — offer flexibility: you can scale them up and down with demand, they carry less fixed cost and fewer ongoing obligations, and they're often the right way to test whether you need help at all before committing. Employees offer commitment and continuity: they're more embedded, more available, more invested in the business over time, but they're a larger fixed cost and come with real legal obligations and responsibilities. Neither is better in the abstract; the right choice depends on how predictable your need is, how much commitment the role requires, and what your business can sustainably carry. Many small businesses grow sensibly by starting with contractors for flexibility, then converting to employees the roles that prove to be permanent and central.

Getting the mechanics right

Whichever you choose, the mechanics must be right — and this is where the Getting Paid guide's discipline pays off directly.

Hiring someone is easy compared to actually letting them do the work. Delegation is the skill that decides whether a team multiplies you or just watches you stay the bottleneck.

Letting go

The hardest part of building a team is not finding people — it's genuinely handing work over to them. Founders who've done everything themselves, to their own high standard, find it painful to let go: no one else will do it exactly as they would, the temptation to take it back is constant, and it feels faster to just do it yourself. But refusing to truly delegate defeats the entire purpose of hiring; you end up paying people while remaining the bottleneck, exhausted and resentful, with a team that can't actually take load off you. Letting go means accepting that others will do things differently — sometimes worse at first, sometimes eventually better — and that “good enough, done by someone else” frees you for higher-value work in a way “perfect, done by me” never can. The founder who cannot let go cannot build a team, only accumulate underused employees.

Outcomes, not tasks

Effective delegation is a specific skill, and its core is handing over outcomes rather than tasks — telling someone what needs to be achieved and why, then letting them find how, rather than dictating every step. Delegating tasks (do exactly this, this way) keeps you as the brain and them as the hands, which doesn't reduce your load or grow their capability; delegating outcomes (achieve this result) develops people who can eventually own whole areas without you. This works far better when it rests on the documentation the Valuing & Selling guide praises: when how the business works is written down rather than living only in your head, others can act on it without constantly asking you. Good delegation is giving people a clear goal, the context and resources to reach it, and the room to do it their way — then holding them to the outcome, not the method. That's how a team becomes more than extra hands.

Taking on a partner — a co-owner rather than a hire — can transform a business or destroy it. The difference usually comes down to conversations most people avoid until it's too late.

The equity conversation

A partnership — bringing someone in as a co-owner who shares in the business itself rather than being paid for work — is a fundamentally different and more permanent relationship than a hire, and it deserves far more care. The central, uncomfortable subject is equity: how ownership is divided, and what each partner contributes to earn it. This conversation is awkward — it touches money, worth, and trust — which is exactly why people rush or avoid it, and why so many partnerships sour. Have it fully and honestly, up front: what each person brings, how ownership splits, how decisions get made, how profits are shared, and — crucially — what happens if someone wants to leave, or if it doesn't work out. The unglamorous work of thinking through the ending at the beginning, when everyone is optimistic and friendly, is what protects the partnership when reality gets complicated. A partnership entered on a handshake and good vibes, with the hard questions unasked, is a dispute waiting to happen.

Get it in writing

Everything agreed in a partnership must be written down in a proper agreement — not because you distrust your partner, but precisely because you don't. Memories differ, circumstances change, and the friendliest partnership can face a moment where a large amount of money or a painful separation turns on what was agreed. A clear written agreement — covering ownership, contributions, decision-making, profit-sharing, and how a partner can exit — is what lets the relationship survive disagreement and change. This is the same principle the Getting Paid guide applies to client relationships, now with even higher stakes: the people you trust most are exactly the ones with whom clarity in writing matters most, because the cost of a misunderstanding is greatest. Never enter a partnership on an unwritten understanding, however close you are. Put it in writing while you're friends, so you can stay friends if things get hard.

Even two or three people is a culture — a way of working together that either helps or hinders. Small teams have real advantages, if you protect what makes them work.

Standards & how you work

The moment you're more than one person, the business has a way of working — standards of quality, expectations of each other, norms of communication — and that culture forms whether you shape it or not. In a tiny team, this is set far more by example than by any written policy: how you personally work, treat people, and uphold standards becomes the template others follow. Being deliberate about the standards you hold and the way you want the team to operate — even informally, even at two people — is worth the attention, because the habits a small team forms early tend to stick as it grows. You don't need an elaborate culture programme; you need to be conscious that everything you do is teaching the team how this business works, and to make sure that lesson is the one you want taught.

The reality of a tiny team

A small software team, often working remotely, has genuine advantages worth protecting: it can be close, fast, and free of the bureaucracy that slows larger organizations, with everyone able to see the whole picture and communication direct and quick. But small teams have their own realities to manage. Communication that happens naturally in a shared room needs more deliberate effort when people are distributed — keeping everyone informed, aligned, and connected takes conscious attention rather than happening by osmosis. And a small team has little slack: one person's absence or underperformance is felt immediately, so the trust and reliability of each person matters enormously. The strength of a small team — its intimacy and speed — is also its fragility, and protecting it means being intentional about communication and about who you bring into something so tightly knit. Guard the closeness that makes a small team good, and don't let distribution quietly erode it.

The final and most personal shift: the founder who builds a team gradually stops being the best builder and becomes something else — the person whose job is now other people. It's a new role, and it must be learned.

From doing to leading

As your team grows, your own job changes in a way that can feel like a loss before it feels like a gain: you spend less time doing the work you love and are good at, and more time enabling others to do it — hiring, delegating, unblocking, deciding, supporting. This is the shift from doing to leading, and it catches many founders off guard, because the work that built the business is not the work that now grows it. Some resist — clinging to the hands-on work, treating management as an annoying distraction — and cap their business at what they can personally touch. Others embrace the new role, and find that enabling a team to do great work is its own kind of craft, with its own satisfactions. There's no requirement to make this shift — staying small and hands-on is entirely valid — but if you're growing a team, recognizing that your job has genuinely changed, and choosing to get good at the new one, is what makes the growth work.

What your people need

Leading a small team well is not mysterious, but it does require giving people things you didn't need to provide when you worked alone. People do their best work when they have clarity (they understand what's expected and why), context (they know how their work fits the bigger picture, so they can make good decisions themselves), the resources to succeed (the tools, information, and authority the work requires), and the trust to do it their way (room to own their work rather than being micromanaged). Providing these is most of what good management of a small team actually is — not commanding, but creating the conditions in which capable people can do good work without you standing over them. The founders whose teams thrive are usually the ones who see their job as removing obstacles and providing clarity, rather than directing every move. Manage by enabling, and a small team of good people will often surprise you with what they can do.

The guide compressed into instruments: a readiness check before your first hire, a way to decide between a contractor and an employee, and the vocabulary of building a team.

The first-hire readiness checklist

The contractor-vs-employee decision aid

Glossary