When to hire engineers, and when to buy sprint capacity
We sell sprint capacity, so treat the recommendation with the scepticism it deserves. The honest position is that hiring is correct more often than vendors like us admit, and that the mistake most funded teams make is not choosing wrongly but choosing before the question is answerable.
The decision also gets made under conditions that guarantee a poor answer: shortly after a raise, with a board expecting visible progress, and with a roadmap that has not yet met a real user. Those are precisely the conditions under which hiring feels safest and is least reversible.
The decision is usually framed as cost. It is not really a cost question, but the cost question is worth settling first because the numbers people compare are the wrong ones.
The number on the offer letter is not the cost
A senior full-stack engineer's salary is somewhere between half and two-thirds of what the role actually costs in the first year. The remainder is employer contributions, equipment, tooling seats, recruiter fees, and the founder or lead time spent on sourcing, interviewing and onboarding, which is real even though it never appears on a budget line.
Founder time is the item most consistently left out. Sourcing, screening, four rounds of interviews and a reference check is somewhere between forty and eighty hours spread across two months, most of it belonging to whoever is also responsible for revenue. Costing that at zero is what makes the hiring option look cheaper than it is.
The figure also ignores the cost of a hire that does not work out, which happens more often than anyone plans for. A mis-hire discovered at month four costs the salary paid, the recruiting spent, the management attention consumed, and then the search restarts from zero with two quarters gone.
Set against that, a year of continuous sprint capacity is comparable and sometimes higher. Anyone telling you outsourcing is straightforwardly cheaper is selling. What differs is not the annual figure but its shape, and the shape is what matters when your runway is finite and your roadmap is not yet settled.
Shape means two things here. The first is commitment: a salary is a twelve-month decision made on month-one information, while sprint capacity is a one-week decision you can stop making. The second is timing: hiring costs arrive months before the output does, while sprint capacity produces output in the same week it is paid for.
Ramp is the line item nobody budgets
A senior engineer joining an unfamiliar codebase is at a fraction of their eventual output for the first two months and consumes someone else's time to get there. That is normal and it is not a criticism of anyone. It is simply a cost that arrives before any of the value does, and it arrives at the moment a funded team can least afford a quiet quarter.
It is worth being precise about what ramp actually consists of, because it is not the new engineer being slow. It is the accumulation of context nobody has written down: which parts of the system are load-bearing, why a particular abstraction exists, who to ask about billing, and which tests fail for unrelated reasons. A well-documented codebase shortens it. Nothing eliminates it.
The other cost hidden in that first bar is your existing team. Onboarding is not free for them either. Every question answered is an interruption, and a senior engineer supporting a new joiner loses something like a fifth of their own output for the first month, which means the team gets slower before it gets faster.
Three questions that actually decide it
Is the work permanent? Some work never ends: your core product surface, the domain logic that is genuinely your business, the systems you will be maintaining in five years. That belongs in-house eventually, and the sooner the better. Other work is a project with a completion date, a migration, an integration, a platform move. Hiring permanently for temporary work leaves you with a team shaped for a problem you have already solved.
The reverse error is real too, and less discussed. Buying capacity for permanent, core work means the understanding of your most important system lives outside the company. We say so when we see it, usually around the third or fourth sprint, because a client who never hires is a client who will one day have a difficult transition.
Can you define the role? Write the job description. If it names one clear specialism, hire. If it reads like four people, you do not yet know what you need, and the version of that role you hire will be wrong within two quarters. Buy capacity, learn what the work actually demands, then write the description from evidence.
There is a useful diagnostic in the attempt itself. If writing the job description takes an afternoon and produces something you would be happy to publish, you know what you need. If it takes three attempts and still lists two specialisms plus "comfortable with ambiguity", you are describing a hope rather than a role.
What does a lost quarter cost? If the roadmap has a date on it, a customer commitment, a renewal, a raise, then five months of search and ramp is not a neutral choice. If there is no date, take the time and hire well.
Ask them in that order, because the first two can make the third irrelevant. Permanent, well-defined work should be hired for even under time pressure, since the alternative is buying capacity indefinitely for something that belongs inside the company.
Hire for the work that defines your company. Buy capacity for the work that merely has to get done.
Where each one is obviously right
Hybrid arrangements work better than either column suggests. A common shape is one senior in-house engineer who owns the architecture and the review process, with sprint capacity running volume alongside. The employee provides continuity and institutional memory; the sprint team provides throughput that can be turned up and down without a redundancy conversation.
The sequence that works
Buy capacity while the roadmap is still an argument. Ship enough to find out which parts of it were right. Then hire against what you learned, into a codebase that already exists and a role you can now describe in one sentence. Candidates interview better against a real product than against a plan, and the first hire inherits something rather than starting from an empty repository.
It changes the hiring conversation as well. A candidate can read the code, see a real roadmap and understand what they would own, which is a substantially better pitch than a description of intentions. The strongest engineers ask what has already been built, and having an answer is worth more than most of what a job advert can say.
The failure mode we see most often is the reverse: hiring three people against a roadmap that changes in month four, then spending month five deciding what to do with a team built for the previous plan. That is an expensive way to learn something a quarter of sprint work would have told you.
If you are in the middle of this decision now, the cheapest next step is to write the job description before doing anything else. If it comes out clean, hire, and we would tell you the same on a call. If it does not, the roadmap is not settled enough to hire against yet, and that is worth knowing before an offer goes out.
