(3/3) Staff Augmentation Sells Capacity. Forward Deployment Sells the Landing.

Two engineers, same seniority, same stack, same time zone. One arrives through classic staff augmentation at a clean day rate. The other arrives forward-deployed — with a prepared day one, a delivery structure behind them, and an exit designed before they start — at a rate that is not always higher, but is never itemized the same way. Procurement will compare the two numbers in a spreadsheet, and the spreadsheet will be wrong, because the two prices don't buy the same thing. Staff augmentation sells you capacity. The forward-deployed model sells you the landing.

This is the third post in a series: the first argued that AI pilots die in deployment, not in the model; the second walked through what a forward-deployed engineer's week contains. This one is about money — where each model's cost actually sits, and when each is the right purchase. I run a company that sells both, so read this knowing the diagnosing party sells a cure. My defense is that I'm going to tell you when the cheaper one is the correct answer.

The day rate is the visible price; the model decides the invisible one

A staff augmentation rate is honest about what it covers: a vetted person's time, integrated into your management. Everything else stays on your side of the table, and it has real cost even when no invoice itemizes it:

• Onboarding. Somebody on your team prepares access, context and the first week — or nobody does, and you pay in the engineer's idle days instead. Industry onboarding-to-productivity estimates run from weeks to months; even taking the optimistic end, an unprepared first month at a senior rate is a four-figure write-off per hire.
• Management attention. The weekly one-on-one, the performance conversation, the scope negotiation with stakeholders. If your engineering managers have slack, this is nearly free. If they're the bottleneck — and in most scale-ups they are — it's the most expensive line nobody prices.
• The wobble. When the engagement dips at week seven, detection and correction are yours. Caught early, it's a conversation; caught at the quarter review, it's a lost quarter.
• The ending. Offboarding, knowledge transfer, credential cleanup. Handled well, a week of someone's time. Handled by default — that is, not at all — it's the audit finding you inherit a year later.

The forward-deployed price folds those four items into the engagement: onboarding prepared before day one, a delivery manager where the project warrants one, double-sided check-ins that catch the wobble while it's still a conversation, and a handover that ends in documentation and a safe delete rather than a shrug. In the doctrine's terms: find, deploy, sustain, hand over — priced as one arc.

Where the money goes is risk transfer, not margin

The fair question: is the difference real structure or just packaging? Concretely, what the arc buys is a shift of risk from your side of the table to the provider's. The clearest instrument is the guarantee: if the fit is wrong inside the first 30 days, we present a substitute within 7, at no added cost. Price that as an option, the way you'd price any insurance. A mis-hire detected at week three under plain capacity means restarting a search — with a marketplace, weeks; with internal recruiting, the 40-plus-day median the industry keeps reporting — while the roadmap slips daily. Under the arc, the same event costs seven days and zero euros. You're not paying a premium for politeness; you're paying for who absorbs the tail event.

The same logic runs through the smaller commitments. The prepared day one transfers the idle-first-week risk. The check-in cadence transfers the detection risk. The designed ending transfers the audit risk. None of this changes the median engagement — and the honest math has to include the base rates that keep both models viable: nearshore seniority at 26–71% below an equivalent local hire, with zero recruiting fee in our case. The arc is an allocation question layered on top of that baseline, not a different market.

When plain staff augmentation is the right buy

Here's the section a vendor post would skip. Staff augmentation is the correct purchase — not the budget compromise, the correct purchase — when three things are true:

1. The need is capacity, not a mission. You're adding a fifth backend engineer to a team with a healthy backlog. There is no "landing" to design because there is no defined end; the work is the ongoing product.
2. Your management structure has room. Real onboarding, weekly one-on-ones, a tech lead with attention to spare. If you already run the arc internally, buying it again from a vendor is paying twice for the same structure.
3. Your leaver process is real. Access reviews on a schedule, offboarding with a checklist and a sign-off. Plenty of engineering orgs — usually the ones that have been through a SOC 2 audit — genuinely have this.

If all three hold, congratulations: you are the deployment structure, and what you need from a partner is exactly what staff augmentation sells — a vetted senior person, fast, at a sane rate. We've compared the sourcing models in detail elsewhere; the short version is that the model is honest about its scope.

When the mission needs the doctrine

Invert the three conditions and the economics invert with them. The doctrine earns its price when:

1. The engagement is a mission with a P&L line. Ship the AI workflow into production, land the migration, stand up the platform. Missions have endings, and an ending that isn't designed is a cost that hasn't been booked yet.
2. The environment is regulated or audit-bound. Under DORA, the EU AI Act, or a SOC 2 renewal, an external engagement that ends without a deprovisioning trail isn't a loose end — it's a finding. The handover-as-deliverable stops being a nicety and becomes the compliance artifact.
3. Management attention is your scarcest resource. The scale-up pattern I see most: the team can absorb the code of one more engineer but not the management of one more engagement. Renting the structure is cheaper than burning your tech lead's remaining slack — that slack is what's keeping your existing team retained.

The asymmetry to notice: getting it wrong in one direction costs a modest premium for structure you didn't strictly need. Getting it wrong in the other direction — buying naked capacity for a mission in a regulated environment with no management slack — is how the tail events from the first section land on your side of the table, all at once, at the worst time.

What I'd put in the spreadsheet

Since procurement will make a spreadsheet anyway, make it an honest one:

1. Price the first month at 50% productivity under plain capacity unless someone owns day-one preparation by name.
2. Price your manager's hours at their loaded cost, times the four-to-six weekly hours a real external engagement consumes.
3. Price the mis-hire option: probability times restart time times daily roadmap slip. Then read the provider's guarantee fine print — in days and euros, as I've suggested asking before.
4. Price the ending: a week of documented handover against the expected cost of an audit finding. If you're regulated, this line decides the comparison on its own.
5. Then compare day rates — last, because it's the only line that was ever going to be visible anyway.

Capacity and landings are both legitimate products, and over a decade of engagements I've bought and sold both without regret; the expensive mistake — the only one I've watched cost someone a quarter — is buying one while needing the other. If the thing on your roadmap is a mission — with a defined end, a P&L line, and no spare management to run it — that's the engagement we deploy engineers into.