A founder we talk to almost every quarter has the same spreadsheet open: a senior engineer’s salary, a recruiter’s fee, and a launch date that keeps sliding right. The number that never makes it onto that spreadsheet is the one that matters most: the 10-14 weeks between “we made an offer” and “this person is actually shipping independently.” That gap is where most early-stage hiring decisions quietly go wrong.
This isn’t an argument that hiring in-house is a mistake. It’s the opposite, sometimes. But the comparison only works if you use real numbers instead of the ones everyone defaults to, which is a headline salary versus an invoice. Here’s the fuller math, broken out at the points where the decision actually flips.
What an in-house hire really costs before month one
Salary is the smallest line item, not the biggest. A loaded cost for one senior engineer typically includes:
- Base salary plus statutory benefits and payroll overhead, usually adding 20-30% on top of salary
- Recruiter or platform fees, or the founder’s own time spent sourcing and interviewing, which is not free even when no invoice is generated
- Equipment, tooling licenses, and any relocation or remote-work stipend
- Management overhead: someone senior enough to review this person’s code has to spend real hours doing it, especially in month one
Then there’s ramp time, which is the part everyone underestimates. A strong hire still needs weeks to understand the codebase, the product decisions baked into it, and the tooling before their output is trustworthy without heavy review. During that stretch you’re paying full salary for partial output. None of this is a knock on the hire; it’s just what onboarding costs, and it applies whether you hire a junior or a principal engineer.
The 6, 12, and 24-month picture
At 6 months, a new in-house hire is usually still net-negative once you account for ramp time and the management hours spent reviewing their work. A fixed-scope engagement with an outside team, by contrast, is built around a defined deliverable and a defined timeline from day one — there’s no ramp period baked into your cost, because the team is already fluent in shipping production code before the engagement starts.
At 12 months, the math starts to depend entirely on what you actually needed. If the work was a single well-defined build — a mobile app, an admin console, a backend service — a fixed-scope engagement has usually already delivered it, and you’re not carrying a salary line for work that’s finished. If instead you need continuous product iteration, a dedicated in-house owner starts to look better, because they’re accumulating institutional knowledge that compounds instead of resetting.
At 24 months, the crossover is usually clear. Sustained, evolving product work with unpredictable scope favors an in-house team, full stop — the fixed-scope model isn’t designed for open-ended ownership, and pretending otherwise leads to scope creep and change-order fatigue on both sides. But a lot of teams get to 24 months having paid two full years of loaded salary for a product that could have shipped as a defined engagement at 6 months, with the in-house hire brought on afterward to own and extend something that already works.
Where a freelancer or generic agency changes the math
The honest comparison isn’t just in-house versus consultancy — it’s also consultancy versus freelancer versus larger agency, and this is where a lot of budgets get burned without anyone noticing.
A single freelancer is often cheap and fast to start, but you’re back to a ramp-and-review problem if anything goes wrong, because there’s no second engineer who already knows the codebase to catch it. A larger agency solves that redundancy problem but usually adds account managers and layers of communication between you and the person actually writing the code, which shows up as both cost and slower iteration.
What tends to actually work for founders trying to unstick a stalled build or ship a first production version is direct access to the engineers doing the work, a scope that’s honest about what exists today versus what still needs to be built, and evidence in the form of shipped, working software rather than a pitch deck.
How to decide, practically
A few questions cut through most of the indecision:
- Is there a defined deliverable with a real end state, or is this ongoing product ownership with no fixed scope?
- Can you currently give a new senior hire enough technical direction to review their work critically, or would you be trusting output you can’t fully evaluate?
- Is the immediate need to ship something specific, or to build long-term internal capability?
If the answer leans toward “defined deliverable, need it shipped, don’t yet have the internal expertise to direct or review a hire,” a fixed-scope engagement usually wins on both cost and risk through the first 12 months. If the answer leans toward “this is core to the product and will never stop evolving,” start budgeting for the hire now, even if it takes a few extra months to get right.
This is roughly the calculation we walk through with most people who reach out to orithLabs — not everyone needs what we do, and we’ll say so directly if a straight hire makes more sense for where you are. When the fit is a defined build, a stalled codebase that needs a second set of eyes, or an AI feature that needs to be integrated without turning into a security liability, that’s the work we do day to day, and Crumb Count and Kompete are there to look at as evidence rather than take our word for it.