The spreadsheet usually has two columns. On the left is a senior engineer's base salary, say $160,000. On the right is an augmentation rate of $75 an hour, which works out to about $150,000 over a 2,000-hour year. The columns look close enough that the staff augmentation vs recruitment decision gets made on instinct. Some leaders want 'our own people', others want 'flexibility'. Both columns leave out the two variables that actually decide the question: how long the work will exist, and who holds the context when someone leaves.
I've spent eleven years on the supplier side of this decision, and I've watched it go wrong in both directions. Companies recruit permanently for what turns out to be a nine-month build. Companies augment for years, cycling through engineers, for what was always a permanent core role. My position is simple. Recruit for work that will outlive the project and that you can evaluate yourself. Augment for speed, for work with a clear horizon, and for disciplines you can't yet vet. When you augment, judge the vendor on continuity, because the rate is the least important number on the page.
Where the Side-by-Side Comparison Misleads
The standard comparison puts a base salary next to a fully loaded vendor rate. The rate already covers payroll, benefits, equipment, management overhead and the vendor's bench risk. The salary covers none of those. Employer taxes, benefits and equipment typically add 25 to 40 percent to base pay, depending on country and benefits package. That turns the $160,000 hire into $200,000 to $225,000 a year before anyone has paid a recruiter.
Then there is the recruiter. Agency fees for engineering roles commonly run 20 to 25 percent of first-year salary, or $32,000 to $40,000 on that same hire. You pay it once, but you pay it again each time the seat turns over. The comparison also treats both options as if they start delivering on the same day, and they don't. SHRM's benchmarking data has put the average time-to-fill across roles at around 44 days, and senior engineering searches usually take longer than average. Add a notice period (two weeks in the US, often one to three months in Europe) and an onboarding ramp, and a recruited senior engineer commonly merges meaningful work three to four months after the requisition opens.
None of this makes recruitment the wrong choice. It means the honest unit of comparison is cost per productive engineer-month over the period the work will actually exist. Once you compare on that basis, the answer changes depending on the situation, and the six questions below are what decide it.
The Six Questions That Decide It
1. Will This Work Exist in 24 Months?
This question comes first because it decides most cases. A product you will keep evolving for years is permanent work: the core platform, the domain logic that makes your business what it is, the system your support team escalates to at 2am. Recruit for that. A payments integration, a mobile app added alongside an existing web product, a legacy migration or a 90-day push to a launch date all have a horizon. Recruiting for a horizon means paying the recruiter, the ramp and eventually either severance or a role you invent to keep the person busy.
The common mistake is to call work permanent because it feels important. A migration is important, but it still ends. I've seen companies hire two engineers for a replatforming effort and then spend the following year looking for something for them to own. Augmenting the migration would have given them the same outcome without the stranded headcount.
2. How Many Weeks Can You Wait for the First Merged PR?
If a revenue date, a funding milestone or a contractual launch is less than a quarter away, recruitment alone can't meet it. The three-to-four-month lead time above is structural and has nothing to do with how hard your talent team works. An established augmentation partner can put vetted senior engineers into your standups within days to a couple of weeks, because those people are already employed, already reviewed and already used to joining unfamiliar codebases.
Nautical Commerce is a clean example. We took over a codebase that was already a year old and delivered against a 90-day go-live model for their marketplace-as-a-service platform. Recruiting that team in-house would have used up the whole 90 days before the first engineer had read the code. When the calendar is the constraint, augmentation is the only option that fits it.
3. Can You Evaluate This Hire Yourself?
The comparison tables skip this one, and it is where recruitment fails most quietly. If you have no senior Android engineer, you can't run a strong Android interview. Your team won't recognise a weak answer about lifecycle management or a candidate whose Kotlin is really Java with the syntax changed. The same applies to a first ML hire, a first DevOps hire or a first staff-level architect. A bad senior hire in a discipline you can't assess costs more than the fee. It costs the six months before anyone notices, plus the rework.
The better approach is to use augmentation to build the ability to evaluate hires, and then recruit. With HeyTutor, we did more than write code. We extended the founders' one-page spec into a 40-page spec, built the platform, and ran hiring, technical interviews, onboarding and coding standards as their team grew. The two models worked together: senior outside engineers set the bar the in-house hires were measured against. If you can't vet the role today, augment first and recruit once you have someone who knows what good looks like.
4. What Is the Real Cost per Productive Month Over the Horizon?
Run the numbers over the expected life of the work, not per year. Take a 12-month need. The recruited engineer costs one agency fee, about three months of lead time with little output, and nine productive months of loaded salary. The augmented engineer costs about eleven productive months at the vendor rate, with no fee and no exit cost. For a 12-month horizon, augmentation usually wins on cost per productive month even at a higher nominal annual figure.
Stretch the horizon to five years and recruitment starts to win, provided the hire stays. That condition matters. At the industry's typical annual engineering turnover of over 20 percent, a five-year seat will probably turn over at least once, and each turnover brings back the fee, the vacancy and the ramp. The long-horizon case for recruitment holds up only if your own retention holds up. Location changes the numbers as well. A nearshore partner at $50 to $99 an hour and a US agency billing twice that are different decisions, as are a San Francisco salary and a Lisbon one. Use your real figures, not the averages in someone else's comparison table.
5. Who Holds the Context When Someone Leaves?
The usual argument against augmentation is that knowledge walks out the door when the contract ends. That's true when the vendor rotates people. A partner that swaps engineers every six months charges you the ramp every six months, and that cost never shows up on an invoice. Rotation is a property of the vendor, though, and augmentation doesn't require it. An augmented engineer who stays three years holds more context than a recruited one who leaves after eighteen months.
Continuity is the mechanism this question turns on, so this is where our retention numbers matter. Our voluntary turnover runs under 5 percent a year, and average engineer tenure is about eight years. For Snapwire, we provided 10 engineers inside a 30-person engineering organisation for two and a half years, working in their Laravel, React, PostgreSQL and Elasticsearch stack. Over that period, those engineers were part of the team in every way that affects the codebase. When you evaluate an augmentation partner, ask for their tenure data and ask what happens contractually if your engineer is reassigned. That answer tells you more than the rate card.
6. Who Reviews the Code Before It Merges?
Augmentation goes wrong when outside engineers merge into your main branch with no senior review on either side. Six months later you have a codebase with two sets of conventions and nobody accountable for the join between them. Recruitment has the same risk, since a new hire with no reviewer drifts just as badly, but it gets less attention because the person is on payroll.
Decide the review path before the first engineer starts, whichever model you choose. At EltexSoft, every pull request is reviewed by at least one other senior engineer before merge, with no exceptions. That applies whether the work goes into our own repositories or a client's. AI coding tools such as Claude Code and Cursor make engineers faster, and the same rule covers them: generated code gets reviewed like any other code. If an augmentation vendor can't describe its review practice in one sentence, treat that as a signal. If your own recruitment plan doesn't name who reviews the new hire's work, it has the same gap.
The Call
Recruit when all three of these are true: the work will exist in two years, you can wait a quarter for productivity, and you have a senior in-house who can interview and onboard in that discipline. That describes the permanent core of an engineering organisation. That core should be yours, and paying the fee, the lead time and the ramp is the right investment.
Augment when any one of them is false. That covers a deadline inside the quarter, a bounded build, or a new discipline you can't yet evaluate. Augmentation also works well as the bridge, with senior outside engineers delivering now and setting the hiring bar for the in-house team that takes over later. Whichever you choose, the deciding metric is the one the two-column comparison leaves out: how many productive months you get from the same people, reviewed by someone senior, for as long as the work lasts.
If your answers point to augmentation, the engagement should be built to test continuity before you commit. Ours starts with a free discovery week, where we work through your roadmap, codebase and the actual horizon of the role. That is followed by a paid pilot with no lock-in, then two-week sprints with daily standups and the same engineers from one sprint to the next. The useful first step is to bring the role definition and your honest estimate of how long the work will last. By the end of discovery week, you'll know whether you need a partner or a requisition.
Last updated October 28, 2026