You’ve signed off on a new hire. The role is open, the budget is approved, and the plan is to bring the build in-house. On paper it’s the responsible choice - you’ll own the capability, keep the knowledge in the building, and avoid paying agency margins. In practice, the first line of working software is still four months away, and that gap is the part that never makes it onto the spreadsheet.
This is one of the most consequential decisions a founder or CTO makes, and it’s almost always framed too narrowly. The question gets reduced to “contractor day rate versus salary,” when the real comparison is between two completely different things: long-term capacity and a finished deliverable. Get the framing right and the decision usually makes itself.
The ramp is the real cost
A salary is easy to model. You know the number, you can forecast it, and it goes neatly into a plan. The ramp is the part nobody budgets for, because it’s harder to see.
Recruiting a senior developer in any competitive tech market is rarely quick. Writing the spec, screening, interviewing, and closing a strong candidate takes weeks at best - and that’s before notice periods, which routinely run one to three months. Then comes onboarding: learning your codebase, your domain, your tooling, your team’s conventions and the undocumented reasons things are the way they are. Realistically, you’re three to four months from the offer letter to the point where that person is shipping work that genuinely moves the roadmap.
For most of that window, you’re paying full cost for partial output, and your timeline is sliding the whole time. If there’s a launch date, a funding milestone or a customer commitment on the other side, that delay is often the single most expensive line item in the whole decision. It just never gets written down, because “time we waited to start” doesn’t have a cell on the spreadsheet.
What you’re actually choosing between
Strip away the framing and there are two distinct options, each suited to a different situation.
Hiring buys you long-term capacity. It’s the right move when the work is permanent, central to your product, and something you’ll need to own and evolve for years. A core product engineer who’ll be shaping your architecture for the next three years should almost certainly be an employee. The ramp cost is real, but you’re amortising it over a long relationship.
A scoped build buys you a finished deliverable on a fixed timeline. It’s the right move when you have a defined outcome - an MVP, a specific module, an integration, a modernisation - that needs to exist before your next hire is even productive. You’re not buying capacity; you’re buying a result, with the delivery risk sitting with the partner rather than with you.
These aren’t really competitors. Most teams we work with need both: a build to clear the immediate deliverable, and hiring to own what comes after. Treating it as an either/or is what creates the false economy.
The hidden costs on both sides
Neither option is free of risk, and an honest comparison names both sets.
The risks of defaulting to hiring are the ones above - the ramp, the timeline slip, and the real possibility that the hire doesn’t work out and you restart the clock. There’s also opportunity cost: the months your existing team spends interviewing instead of building.
The risks of an outside build are different but just as real, and worth saying plainly. A poorly scoped engagement leads to arguments about what “done” means. A partner who goes quiet leaves you worse off than when you started. Knowledge can walk out the door at handover if the work isn’t documented. These are the exact failures that make people wary of agencies in the first place - which is precisely why how a partner handles scope, communication and handover matters more than their day rate.
The point isn’t that one option is safe and the other risky. It’s that the risks are different in kind, and you should choose the set you’re better positioned to manage.
A simple test
Before defaulting to a job posting, ask three questions:
- Is the outcome defined enough to scope and estimate? If you can write down what “finished” looks like, a build is on the table. If the work is still being discovered week to week, you probably need capacity, not a contract.
- Does it need to ship before a new hire could realistically be productive? If the deadline lands inside the next four months, hiring alone won’t meet it.
- Is it a one-time build or a permanent capability? One-time deliverables favour a scoped partner. Permanent, core capabilities favour hiring.
If the answers point to “defined, urgent, and one-time,” a scoped engagement will almost always get you there faster and with less risk. If they point to “evolving, ongoing, and core,” hire - and accept the ramp as the cost of ownership.
Why parallel beats sequential
The most expensive version of this decision is treating it as sequential: post the role, wait, hope the hire lands, then start building. Every week of that is a week of nothing shipped.
The version that works runs the two in parallel. You scope the urgent deliverable to an experienced partner so it ships on a fixed timeline, and you use the months you’d otherwise have spent waiting to hire deliberately - for the person who’ll own the product long-term, not the one firefighting a deadline. By the time your new engineer is ramped, there’s a working product for them to take ownership of, with the early, riskiest decisions already made and validated.
This is how we run most engagements. A clear scope, a dedicated project manager, weekly demos of working software, and around four hours of daily overlap with your team’s hours mean the build moves at pace while your hiring runs its own course. Across 200+ projects, the pattern holds: the build clears the deadline, and the hire inherits momentum instead of a blank page.
The bottom line
Build versus hire isn’t a question of which is cheaper per hour. It’s a question of what you’re actually buying - capacity or a deliverable - and what your timeline can absorb. Model the ramp honestly, name the risks on both sides, and in most cases you’ll find the answer is “both, in parallel,” not “one instead of the other.”
If you’re weighing a build against an open req right now, it’s worth a 20-minute call to pressure-test which one fits the work in front of you - and whether running them together gets you there faster.