Every scale-up hits the same wall: the roadmap needs more .NET capacity than the team has, and there are three ways to buy it — hire, augment, or engage a boutique on a sprint basis. Each model is genuinely correct for someone. This page is about working out which one is correct for you.

One disclosure before the table: we sell one of these three models. We’ve tried to write the comparison we would want to read if we were the buyer — which means two of the sections below are concessions.

The three models at a glance

	In-house team	Sprint-based boutique	Staff augmentation
Unit of purchase	FTE, annual	2-week sprint	Contractor-month
Effective cost	$130K–$180K/yr loaded per senior dev	From $4,800 per sprint	~$40–$120/hr depending on region
Time to productive work	3–6 months (recruit + onboard)	1–2 weeks	2–6 weeks
Commitment	Permanent, plus notice periods	One sprint minimum; pause anytime	Typically 3–12-month contracts
Who directs the work day-to-day	You	The boutique’s principal, against your priorities	You
Knowledge retention	Highest — it stays on payroll	Explicit hand-off deliverables	Leaves with the contractor
Scaling down	Layoffs — slow and painful	Skip the next sprint	Contract notice period
AI tooling	Whatever you build or procure	Brought, installed, and left behind	The contractor’s personal setup

Where an in-house team wins

Long-term IP retention. Every hour an employee spends in your codebase compounds into institutional knowledge that stays on payroll. No hand-off document — however good — matches the engineer who wrote the subsystem still being in the room two years later.

Deep domain knowledge. If your product’s complexity lives in the domain rather than the plumbing — actuarial logic, market microstructure, clinical workflows — an in-house team’s slow accumulation of context is the asset, and it is not outsourceable.

Recruitment defensibility. An owned team is something you can show an acquirer or an auditor. “Six engineers, four years median tenure” answers a due-diligence question that “we have a great agency” does not.

If the work is permanent and core-differentiating, hire. Nothing below argues otherwise.

Where staff augmentation wins

Raw hourly rate. Offshore and nearshore augmentation at $40–$60/hr undercuts both an in-house loaded cost and any boutique’s sprint price. If the constraint is a hard cost floor and the work is well-specified, augmentation is the honest answer.

Scale flexibility. Five contractors this quarter, two the next — augmentation flexes headcount faster than hiring and with less ceremony than renegotiating an engagement. Organizations with strong internal tech leadership, mature processes, and a management layer with spare capacity can absorb that flexibility and get exactly what they pay for: hands.

The catch is in that last word. Augmentation supplies capacity, not judgment — the direction, review, and integration overhead stays with you, and it is rarely priced into the comparison spreadsheet.

Where the sprint-based boutique wins

Time-to-value. A sprint starts 1–2 weeks after the kickoff call. A hire starts producing net-positive work three to six months after you open the requisition. When the roadmap gap is now, the recruiting timeline is the cost that dominates everything else.

Predictability. A sprint has a fixed price, a defined start, a demo on day 14, and a decision point after. That maps cleanly onto board reporting in a way neither “recruiting is ongoing” nor a time-and-materials invoice does. You are never more than two weeks from a clean exit — which changes the risk profile of saying yes.

AI-augmented throughput per dollar. This is where the hourly-rate lens breaks down. Our developers work inside the twelve-layer system — investigation gates, build gates, per-PR architectural inventories — which means AI agents do the mechanical share of the work under deterministic guardrails, and senior engineers spend their hours on decisions. The relevant question stopped being what does an hour cost and became what does a shipped, reviewed, evidenced feature cost. On that measure, a five-person boutique running guardrailed agents competes with teams several times its size.

What’s actually in a $4,800 sprint

Day 1 is kickoff and planning against your priorities. Days 2–13 are execution with check-ins on whatever cadence fits your team — daily standups, twice-weekly syncs, or async-only. Day 14 is a demo and hand-off. Code is committed to your repository from the first day; you own all of it, always. Team size flexes between sprints — one developer this sprint, three the next — without renegotiating anything, and pausing between sprints costs nothing.

The full mechanics, FAQ, and pricing tiers are on the sprint-based development page.

The cost math a CFO actually runs

A US senior .NET developer costs roughly $130K–$180K per year fully loaded — about $65–$90/hr on paper, closer to $100+/hr once you count the true cost of an employee: benefits, tooling, management overhead, and the ramp months. Crucially, that cost runs whether the roadmap is full or not.

Staff augmentation looks cheaper per hour, but the spreadsheet rarely carries the management line: someone senior on your side directing, reviewing, and integrating the work — plus the knowledge that walks out at contract end and has to be re-purchased on the next one.

The sprint model bills only for active sprints. For variable or project-bound work, that typically lands 30–50% below in-house cost — and it turns off cleanly when the work is done.

A worked example

Say the work is project-bound: a six-month build, one senior developer’s worth of effort. Illustrative math with the numbers above:

In-house hire: ~3 months to recruit and onboard before productive work starts, then salary at a $130K–$180K/yr loaded rate. Six months of output costs roughly $65K–$90K — but arrives over nine calendar months, and the cost continues after the project ends unless you part ways.
Staff augmentation: at $55/hr mid-range, six months ≈ $53K — plus the unpriced line: a senior person on your side directing and reviewing throughout, and a knowledge reset when the contract ends.
Sprint-based: twelve 2-week sprints at $4,800 ≈ $58K — starting within two weeks, with a demo every fortnight, senior judgment included, and a clean stop at sprint twelve with a documented hand-off.

The spreadsheet ranks them within ~15% of each other. The calendar, the management load, and what happens after the last invoice do not — and those three lines are where the models actually differ.

When each model is correct

Hire in-house when the work is permanent, the complexity is your domain rather than the plumbing, and you can afford a 3–6 month runway before the capacity arrives. This is the right default for your core product team.

Use staff augmentation when you have strong internal technical leadership with capacity to direct the work, the tasks are well-specified, and the hourly cost floor is the binding constraint.

Engage a sprint-based boutique when the work is project-bound or variable, time-to-value matters more than rate, and you want senior judgment included rather than supplied by your own management layer — with pricing your board can read at a glance.

Most scale-ups eventually use more than one of these. The mistake isn’t picking the “wrong” model — it’s paying boutique prices for hands, or augmentation prices while silently supplying the judgment yourself.

How each model fails

Since every vendor page tells you how their model succeeds, here is how all three fail — ours included.

In-house fails by hiring ahead of need. The team staffed for the roadmap’s peak becomes a fixed cost through its troughs, and the pressure to keep everyone busy starts generating work — internal platforms, premature rewrites — that no customer asked for. It also concentrates risk: one resignation in a three-person team is a third of your capacity and often the only person who understood the deploy pipeline.

Staff augmentation fails by becoming permanent. The three-month contractor is still there in year two, now load-bearing, with knowledge that exists nowhere on your payroll and a rate that has quietly crept past what the equivalent hire would cost. The flexibility you bought was never exercised, so you paid its premium for nothing.

The sprint model fails when priorities drift. Two-week increments are a forcing function only if someone on your side does the forcing — a client who arrives at each sprint boundary without a clear next priority converts predictable delivery into an expensive drift. It also depends on vendor availability: a boutique’s capacity is real but finite, and scaling up dramatically needs a heads-up we may not always be able to honor on your timeline.

Match the failure mode you can best absorb, not just the success story you like most.