solo-founder·9 min read·

Your first hire-or-tool decision: when to buy capacity (and when to do it yourself one more time)

You have shipped the thing. You launched it, kept a first cohort, raised the price once, built a cancel page that saves a few, found one channel that brings the next customer, and you read your number

Your first hire-or-tool decision: when to buy capacity (and when to do it yourself one more time)

You have shipped the thing. You launched it, kept a first cohort, raised the price once, built a cancel page that saves a few, found one channel that brings the next customer, and you read your numbers every Monday. Support tickets come in and you answer them. A handful of customers have started referring their mates.

And you are knackered.

This is the moment every solo founder hits somewhere between 3 and 30 paying customers. The question stops being "what should I build next" and becomes "what should I stop doing myself". The internet has a confident answer ready for you: assemble a 300-to-500-pounds-a-month "agent stack", and hire your first contractor the moment you cross 5,000 pounds in monthly revenue.

Ignore most of that. At your scale the honest default answer to "should I buy this tool or make this hire" is usually: no, do the job yourself one more time. Not forever. Just one more time, so you actually learn what the job is before you pay someone or something to do it.

Here is how to make the call without buying a stack you will spend Sundays maintaining.

A tool and a hire are the same decision

Start by collapsing two questions into one. "Should I buy this 39-pounds-a-month tool" and "should I hire a part-time VA" feel like different categories. They are not. Both are the same move: you are buying capacity to take a recurring job off your plate. One uses software, one uses a person. The decision logic is identical.

That reframe matters because it stops you reasoning about a hire as a status symbol ("real founders have a team") and a tool as a no-brainer ("it's only 39 quid"). Neither is true. A hire is not a milestone you earn; it is capacity you buy for a specific job. A tool is not free because it is cheap; it is a recurring liability you maintain forever. Same question for both: is this particular job ready to be handed over?

Most of the time, at 3 to 30 customers, it is not. Here is the test that tells you when it is.

The three-part test before you buy any capacity

Before you pay for a tool or bring in a contractor, the job has to pass all three of these. Two out of three is a no.

1. It is recurring. You do this job every week, not once. A one-off setup task does not justify ongoing capacity. If you are tempted to hire someone to do a thing once, you do not need a hire, you need an afternoon. Recurring is the whole point: you are buying back time that repeats.

2. You can specify it in a sentence or a short checklist. If you cannot write the brief, you cannot hand the job over, and you will buy the wrong thing. "Triage incoming support, tag by theme, reply to billing and login questions from the saved answers, escalate bugs to me" is a brief. "Sort out my support, I guess?" is not. The act of writing the spec is the test. If you struggle to write it, that is a signal you do not understand the job well enough yet to delegate it. Do it yourself a few more times until you can.

3. It is genuinely stealing time from the only two things that need you. As a solo founder there are exactly two jobs nobody else can do at this stage: talk to customers, and build the product. Everything else is, in principle, delegable. So the question is not "is this job annoying" (lots of jobs are annoying). It is "is this job eating the hours I should be spending with customers or in the codebase". If a task is annoying but takes 20 minutes a week, buying capacity to remove it is a bad trade. If it eats half a day that should have been a customer conversation, that is your candidate.

Pass all three and you have a real candidate for buying capacity. Now do not rush to the credit card.

Why the default is "do it yourself one more time"

Doing a job manually a few more times feels like the slow, unscalable option. At 3 to 30 customers it is actually the cheapest tuition you will ever buy.

When you do the job by hand, you learn its real shape. You find out that "support" is 80 percent the same three questions. You discover that the weekly report you were going to pay a tool to generate is actually two SQL queries. You notice that the content job you wanted to hire for is really just turning your own answers into posts, which no contractor can do as well as you can right now because the voice is yours.

That knowledge is what makes a future purchase good. The founders who buy badly are the ones who bought before they understood the job: they pick the wrong tool, they write a vague brief, the contractor produces something off, and they conclude "delegation does not work for me". It works fine. They just bought blind.

Premature buying also has a hidden cost beyond the money. Every tool you add is a thing you integrate, log into, keep secure, and migrate off later. A "300-pounds-a-month agent stack" for a 12-customer business is not leverage; it is a second product you now maintain alongside your actual product, and a data silo splitting your customer information across six dashboards. The subscription is the small cost. The maintenance and the fragmentation are the real ones.

So the default at this scale is: do it once more, on purpose, watching for the patterns. When the patterns are obvious and the job clearly passes the three-part test, then move, in this order.

The order of operations when a job is genuinely ready

Do not jump straight to "buy a tool" or "hire someone". Walk down this ladder and stop at the first rung that works.

Rung 1: Kill the job. Can you remove the need entirely? The cheapest job is the one that no longer exists. If you are spending an hour a week answering the same "how do I reset my password" question, the fix is not a support tool or a VA, it is a self-serve reset flow and one help doc. Half the jobs solo founders want to delegate should be deleted, not delegated.

Rung 2: Automate the cheap 80 percent with a small helper you build yourself. Before you pay a monthly subscription, ask whether a thin internal tool would cover most of the job. With Claude Code you can build a back-office helper in an afternoon: a scheduled export, a script that tags incoming tickets by keyword, a single authenticated internal page that shows the four numbers you check on Mondays, a generator that turns a row in Supabase into a draft. You already have the stack: Next.js, Supabase, Stripe, and Claude Code to write it. A helper you own has no monthly fee, no data silo, and does exactly what your business needs because you specced it. Keep the diff narrow and, if it touches anything near billing, run the money path in Stripe test mode before you trust it.

Rung 3: Buy an off-the-shelf tool. Only when the job is real, recurring, well-understood, and genuinely not worth building yourself. By now you can write the spec, so you can evaluate tools properly instead of buying the one with the best landing page. Reason about the price honestly: a 39-pounds-a-month tool is not 39 pounds, it is a recurring liability you maintain forever, weighed against the hours it actually saves at your current volume. At 12 customers, most "time-saving" tools save minutes and cost focus. Buy one tool, for one job, when that maths clearly works. Do not buy a stack.

Rung 4: Hire a human. Last, and as a contractor, not an employee. More on that next.

The point of the ladder is that "buy a tool" and "hire someone" are rungs 3 and 4, not rungs 1 and 2. Most founders skip straight to the bottom because it feels like progress. The leverage is at the top.

When the job needs a person: contractor before employee, always

Some jobs cannot be killed, automated, or bought as software. They need a human. At 3 to 30 customers that human is a contractor, never a full-time employee.

The first contractor a solo SaaS founder hires is almost always customer support or content, because those are the recurring, specifiable, time-stealing jobs that you cannot fully automate and should not be doing all of yourself. It is almost never engineering. You plus Claude Code still cover the build; handing the codebase to a contractor at this stage creates more review work than it removes.

Hire like this:

  • Pay by the task or the hour, project-based. Not a salary, not a retainer you cannot justify weekly.
  • Write the brief as if for yourself. If you did the job manually first (you did, see above), you already have the checklist. Hand that over.
  • Keep a documented process. The job should be replaceable. If your contractor disappears, you want to onboard the next one from a doc, not from your memory.
  • Mind the UK employment-status rules. A genuine freelancer doing project-based work on their own terms is a contractor. Someone working set hours, only for you, under your day-to-day direction, starts to look like an employee, with the IR35 and employment-rights consequences that brings. Keep your first help genuinely freelance and project-shaped, not a disguised full-time role. If in doubt, check the status properly before you scale the hours.

A contractor for the right job, with a real brief and a documented process, is leverage. A full-time hire at 15 customers is a runway-burning bet on growth you have not earned yet.

Measure whether it worked

You measure a tool or a hire the same way, because they are the same decision: did it actually free your time for customers and product, and did nothing in the money path break?

A month after you bought the capacity, ask one question: can you point at the hours it gave back, and what did you spend them on? If the honest answer is "I am not sure it changed anything", you bought wrong. Cancel the subscription or unwind the arrangement. There is no shame in it; you ran a small experiment and it failed cheaply, which is exactly how this is meant to work. If the answer is "yes, I got my Friday afternoons back and I spent them talking to customers", you bought right. Keep it, and look for the next job that passes the three-part test.

Notice what you are not measuring: you are not measuring whether the tool is "good" in the abstract, or whether the contractor is "nice". You are measuring freed founder time against a stable money path. That is the only scoreboard that matters at this stage.

When to stop, and when to graduate

At 3 to 30 customers, here is what you do not need: an org chart, a full-time hire, an "ops manager", or a 300-to-500-pounds-a-month agent stack. Every one of those is solving a 100-customer problem with a 15-customer business, and the cost is focus you cannot spare.

You graduate to real tooling and real hires when two things are both true: the manual job clearly hurts (it is eating real founder hours, week after week, and you have felt it), and you have a documented process to hand over (because you did the job yourself long enough to write one). When both are true, buying capacity is obvious and you will buy well, because you know exactly what you are buying and why.

Until then, the most valuable thing you can do with most "should I buy this" decisions is the cheapest: do the job yourself one more time, watch for the pattern, and keep your money on the only two jobs that are actually yours.

Frequently asked

At what revenue should a solo SaaS founder make their first hire?

There is no magic number, and the popular "hire a contractor at 5,000 pounds MRR" rule is too blunt. Hire when a specific job passes the three-part test (recurring, specifiable, genuinely stealing time from customers or product) and you have already tried to kill it, automate it with a small Claude Code helper, or buy a single tool for it. Revenue is a weak proxy; a passed job test is the real trigger.

Should I buy a tool or build it myself with Claude Code?

At 3 to 30 customers, try building first for most back-office jobs. A thin internal helper (a scheduled export, a ticket tagger, an internal metrics page) takes an afternoon with Claude Code on your existing Next.js and Supabase stack, has no monthly fee, and creates no data silo. Buy an off-the-shelf tool only when the job is real, recurring, well understood, and genuinely not worth building yourself. Never buy a 300-to-500-pounds-a-month "stack" at this scale.

What is the first role a solo founder should hire for?

Almost always customer support or content, because those are the recurring, specifiable jobs that you cannot fully automate and should not be doing all of yourself. It is almost never engineering at this stage; you plus Claude Code still cover the build, and handing over the codebase creates more review work than it saves.

Contractor or employee for my first hire?

Contractor, every time, at 3 to 30 customers. Pay by the task or hour on project-based work, write the brief as if for yourself, and keep a documented process so the role is replaceable. Watch the UK rules: someone working set hours only for you under your direction can be reclassified as an employee, with IR35 and employment-rights consequences. Keep first help genuinely freelance.

How do I know if a tool or hire was worth it?

A month later, point at the hours it gave back and what you spent them on. If you cannot, you bought wrong, so cancel the subscription or unwind the arrangement. If you got real founder time back and spent it on customers or product without breaking the money path, you bought right. Freed founder time against a stable money path is the only scoreboard that matters.

The newsletter

One UK business idea, every Thursday

By Tim Bland. Free.