The dedicated team model, explained end to end

Somewhere between renting individual engineers and buying a finished project sits the engagement model that most long-run product outsourcing actually uses: the dedicated team. A vendor assembles a team that works only on your product, you direct its roadmap as if it were your own department, and the vendor keeps it staffed, employed and healthy. The model powers thousands of product companies' engineering organizations, and it is chronically misexplained by vendors selling it and misused by buyers who wanted a different model at this model's price.

This guide explains it properly: what a dedicated team is and what the fee actually buys, how the model differs from augmentation and fixed-scope projects, what a real team contains, the honest cost arithmetic, the direction-versus-management split that makes or breaks engagements, and the lifecycle from contract to a team that outsiders cannot distinguish from your employees. Throughout, the test of every claim is the same: what happens in month eighteen, because this is a model you buy for the long run or should not buy at all.

It belongs to a cluster of sourcing decisions: the augmentation guide covers the model dedicated teams are most confused with, the sourcing model guide handles whether to use external engineering at all, and the offshore center guide covers where dedicated teams often grow into.

What a dedicated team actually is

A dedicated team is a group of engineers, with a lead and usually QA, assembled by a vendor to work exclusively and indefinitely on one client's product. Exclusively means no other clients, no shared utilization, no bench rotation: the team's calendar belongs to your roadmap. Indefinitely means the engagement has no scope-defined end: it runs month to month or year to year until you end it, and the team's composition is designed for tenure rather than for a delivery date. The commercial shape is a monthly fee per team member, usually all-inclusive of salary, employment costs, workspace, equipment and the vendor's margin.

What the fee buys, beyond the hours, is an institution around the team. The vendor recruits to your approval, employs, pays and retains the engineers; replaces departures and underperformers; provides the office, the hardware, the local HR and legal compliance; and carries accountability for the team's operational health, attrition, morale, working conditions, that a pile of individual contractors leaves entirely with you. This is the concrete difference from augmentation: there you buy individuals into your structure and own everything about how they combine; here you buy a functioning unit, and the vendor answers for the unit staying functional.

What the fee explicitly does not buy is delivery ownership of outcomes. A dedicated team is directed by you: your product owner sets priorities, your roadmap defines the work, your acceptance defines done. If the roadmap is wrong, the team builds the wrong thing efficiently, exactly as your own department would. Vendors sometimes blur this by promising outcome accountability at team-model prices; the blur always resolves in the contract's favor, not the sales deck's. The honest formulation: the vendor is accountable for the team's capability and continuity, and you are accountable for what you aim it at.

The model's center of gravity is continuity, and it is worth being precise about why that is worth paying for. An engineer's value on your product is not constant: it compounds, through the first months of learning the domain, the codebase and the unwritten decisions, into a steady state where changes that once took weeks take days. Project staffing resets that curve at every engagement; churn-funded cheap augmentation resets it every quarter; a dedicated team is the engagement structure explicitly designed to never reset it. Buyers who have run the same team for three years describe the effect the same way: the team stops being a vendor and becomes the department that happens to sit elsewhere.

The model's vocabulary

Dedicated team

A vendor-assembled unit working exclusively on your product under your roadmap, priced monthly per person, designed for tenure.

Exclusivity

The team serves no other client. Its calendar, context and loyalty accumulate on your product alone.

Product owner

Your named person who directs the team's priorities daily. The single most predictive role in the whole model.

Team health accountability

The vendor's side of the split: staffing, retention, replacement speed, morale and working conditions.

Ramp curve

The months-long climb from zero context to steady-state productivity. Continuity is valuable because this curve only pays off once per person kept.

Against the alternatives: augmentation, projects, and hiring

Against augmentation, the difference is who supplies structure. Augmented engineers join your existing team under your lead; a dedicated team arrives with its own lead, its own internal review practices, its own working rhythm, coordinated with yours but owned by the vendor. That makes augmentation the right call when you have a strong team that needs hands, and the dedicated team the right call when the work needs a whole standing unit, a product line, a platform, a market, that you do not want to build from individuals yourself. The price difference between the models is mostly this structure: a team lead's attention, the vendor's team-health accountability, and cohesion that pre-assembled groups bring.

Against project outsourcing, the difference is who owns scope risk. A fixed-scope project prices every ambiguity: the vendor's bid carries a risk premium, changes arrive as change orders, and the commercial physics push both sides toward litigating the spec rather than serving the product. A dedicated team dissolves that entire dynamic: there is no scope to defend because you direct the backlog directly, and re-prioritizing costs a conversation, not a contract amendment. The trade is that you absorb the risk the vendor was pricing: if the team is idle or aimed wrong, the monthly invoice arrives anyway. Projects fit fixed, well-specified, genuinely bounded work; dedicated teams fit the evolving roadmap that describes almost all real product work.

Against building your own team by hiring, the differences are speed, geography and reversibility. A vendor with a real bench and recruiting engine stands up a five-person team in 4 to 8 weeks in markets where you have no entity, no employer brand and no hiring pipeline; doing the same directly takes one to two quarters after you have an entity at all, which the offshore center guide prices honestly. And a dedicated team unwinds with a notice period, while an employed team unwinds with severance and reputational cost. The offsetting truth: at multi-year horizons and meaningful scale, roughly ten people and up for several years, direct employment or a build-operate-transfer arrangement becomes cheaper than paying the vendor's margin forever, which is why mature engagements often include conversion terms from day one.

The three-way comparison collapses to a sentence each. Buy augmentation when you have structure and need capacity. Buy a project when the scope is real and fixed. Buy a dedicated team when the work is a long-run stream that needs its own standing structure and you want to direct it without employing it. Most sourcing mistakes in this market are shape mismatches, outcome-shaped needs bought as capacity, evolving roadmaps bought as fixed projects, and the dedicated team is frequently the correct answer bought last, after both mismatches have been paid for.

The three engagement models, side by side

Dimension	Augmentation	Dedicated team	Fixed-scope project
Unit purchased	Individuals	A standing team	An outcome
Structure and lead	Yours	Vendor's, coordinated with yours	Vendor's, opaque to you
Scope flexibility	Total; you direct individuals	Total; you direct the backlog	Change orders, priced
Who owns team health	You	The vendor	The vendor
Utilization risk	Yours	Yours	Vendor's, priced into the bid
Best horizon	3 to 18 months	1 year and beyond	Bounded, spec-complete work

The structural differences that should drive the choice. Rates differ less than what each rate includes.

What a real team contains

The minimum viable dedicated team is larger than buyers expect, because a team is a structure, not a headcount. Below roughly four people there is nothing to structure: no meaningful lead role, no internal review dynamic, no resilience to a single departure, and the model's team-health accountability has nothing to attach to. Engagements of one to three engineers are augmentation wearing a team's name, and should be bought, priced and managed as augmentation. The classic starting shape is five to seven: a team lead who codes, three to five engineers across the stack's needs, and a QA engineer, with design and DevOps either fractional from the vendor's shared pool or added as the product demands.

The lead role deserves specific attention because it carries the model. A dedicated team's lead is the junction where your direction meets the vendor's structure: inward, they run the team's technical practices, review, standards, estimation, mentoring; outward, they are your product owner's daily counterpart, translating roadmap into plan and surfacing the trade-offs that tickets hide. Weak leads reduce the model to augmentation with extra margin, a group of individuals you end up directing one by one. When evaluating a proposed team, interview the lead hardest, ask how they have handled priority conflicts and quality pushback with previous clients, and treat lead quality as a deal condition, not a staffing detail.

Seniority mix should be argued about openly, because it is where team price and team capability are actually set. A durable long-run shape is senior-weighted at the core, the lead and one or two seniors who carry architecture and standards, with mids doing the bulk of delivery and at most a small junior tail that the team can absorb and grow. Vendors under price pressure will quietly propose mid-heavy shapes that demo well and decay under architectural load; buyers over-indexing on credentials will pay for five seniors where two seniors and three strong mids deliver the same roadmap. The honest conversation prices two or three mixes against the work, exactly as the rate benchmark recommends for any offshore purchase.

Two composition rules prevent most structural regrets. First, the team owns systems, not tickets: give it durable ownership of services, modules or product areas, with the documentation and on-call duties ownership implies, because ownership is what converts continuity into compounding value. Second, plan the interface roles on your side before the team exists: a named product owner with real authority and real availability, and a technical counterpart, an architect or staff engineer, who holds the standards conversation with the team's lead. A dedicated team with no empowered product owner is a rowing crew with no coxswain: perfectly synchronized motion in whatever direction it happened to be pointing.

Composition review, before signing

• Four people or moreBelow that there is no team to structure. Smaller needs are augmentation and should be bought as augmentation.
• A lead you have interviewed hardThe role carries the model. Priority conflicts and quality pushback are the interview topics.
• A seniority mix argued in the openTwo or three alternative mixes priced against the roadmap, not one blended number.
• System ownership definedThe team owns services and product areas durably, with docs and on-call, not a ticket queue.
• Your product owner named and availableReal authority, real hours. The single most predictive variable in the whole engagement.
• QA inside the teamQuality as a team member, not a downstream department. Retrofit costs more than the seat.

The economics: what it costs and why

The pricing unit is a monthly fee per team member, all-inclusive: the engineer's salary, employer costs, workspace, equipment, local compliance, the vendor's recruiting and retention machinery, and margin. In Vietnam and similar markets, that lands roughly 4,000 to 8,500 dollars per engineer per month depending on seniority, with leads above the band; Central and Eastern Europe runs roughly 7,000 to 12,000; Latin America similar or slightly above. A senior-leaning six-person team in Vietnam therefore prices around 400,000 to 550,000 dollars a year, all-in, against 1.3 to 1.8 million for the equivalent employed team onshore in the US or Western Europe, the same arithmetic the rate benchmark develops hourly.

Against project pricing at the same vendor, the dedicated team runs 15 to 30 percent cheaper per hour of engineering, and the discount has a clean explanation: you have taken the utilization and scope risk. The vendor is not pricing bench time between projects, estimate overruns, or change-order friction into every hour; you pay for the team every month whatever the roadmap does, and in exchange the hours come at close to capacity cost. This is why the model punishes buyers without a real pipeline of work: an idle dedicated team is the most expensive idleness in outsourcing, and the discipline the model demands is a roadmap that genuinely runs ahead of the team.

Against direct employment in the same offshore market, the vendor's fee typically exceeds raw employment cost by 25 to 40 percent, and that premium buys concrete things: recruiting without your own pipeline or brand, employment without your own entity, retention machinery, replacement guarantees, and an exit measured in notice rather than severance. The premium is rational at team sizes up to roughly ten and horizons up to a few years; beyond that scale and duration, the same money starts to fund your own entity, which is the crossover the offshore center guide maps, and why serious vendors offer build-operate-transfer paths rather than pretending the crossover does not exist.

The hidden lines are the same as for any offshore engagement, and they are smaller here than in any other model, which is part of the value. Ramp is paid once per person retained, not once per quarter; management attention is concentrated in one product owner relationship rather than spread across individually directed contractors; and communication overhead falls as the team accumulates context, the opposite of its trajectory in rotating engagements. Budget the engagement honestly at fee plus 10 percent of your own attention, model 8 to 12 percent annual fee growth as market salaries rise, and the model's multi-year total cost is the strongest in offshore engineering, provided the duration assumption that justifies everything actually holds.

The dedicated team, priced

$4,000 to 8,500 Per engineer per month, Vietnam band All-inclusive: salary, employer costs, workspace, vendor margin. Leads above the band.

15 to 30 percent Below project pricing per hour You carry utilization and scope risk; the vendor stops pricing it.

25 to 40 percent Premium over direct offshore employment Buys recruiting, entity, retention machinery and reversibility.

~$450,000 a year Senior-leaning six-person Vietnam team Against 1.3 to 1.8 million employed onshore for the same shape.

The split that makes it work: direction versus management

Every healthy dedicated team engagement runs on the same division of labor, and every failed one violated it somewhere. You own direction: the roadmap, the priorities, the acceptance of work, the product decisions and their trade-offs. The vendor owns management of the unit: who is on the team, how departures are replaced, how the office runs, how the engineers are paid, grown and retained. The lead owns the junction: converting your direction into the team's plan, and representing the team's technical reality back into your decisions. Write this split into the contract and the working agreement, because the default drift, in both directions, is the model's main degradation path.

Drift in your direction looks like managing through the vendor: routing daily priorities through an account manager, treating the team's engineers as fungible with the vendor's other staff, or accepting weekly status reports in place of direct contact with the people building your product. Each relay adds latency and loss, and a team directed through intermediaries behaves exactly like the relayed communication failure every offshore guide warns about. The fix is structural: your product owner works directly with the team in a shared channel and a daily or near-daily rhythm, the account manager handles commerce, and the org chart between your PO and the team's engineers contains exactly one node, the lead.

Drift in the vendor's direction looks like abdication dressed as service: the vendor starts making product-shaped decisions because your product owner is absent, the backlog fills with the team's guesses, and six months later the demo is full of competently built features nobody asked for. This failure is almost always the buyer's: a dedicated team consumes direction the way a factory consumes orders, and an unfed team does not idle politely, it improvises. The pre-purchase test from the augmentation guide applies with double force here: name the product owner, count their hours, and if the honest answer is nobody has ten hours a week for this team, the organization is not ready for the model.

The instruments that keep the split healthy are unglamorous and non-negotiable. A single prioritized backlog that only your side reorders. A sprint or cycle review where the team demos to your stakeholders, not to the vendor's. A quarterly engagement review covering both halves of the split: your side's direction quality, was the backlog ready, were decisions timely, and the vendor's management quality, attrition, replacement speed, growth of the team's people. And an escalation path with names on it for the day the lead and your product owner genuinely disagree. Engagements with these four instruments survive personnel changes on both sides; engagements running on goodwill survive until the goodwill's owner changes jobs.

Keeping the split clean

Do this

• Direct the team, not the vendorYour product owner works with the lead and engineers daily. The account manager handles commerce.
• Keep one backlog you reorderA single prioritized queue, reordered only by your side, is the direction interface.
• Demo to your stakeholdersThe team presents to the people who own the product, every cycle. Visibility is alignment.
• Review both halves quarterlyTheir management (attrition, replacements, growth) and your direction (backlog readiness, decision latency).

Not this

• Route priorities through relaysEvery intermediary between product owner and team adds latency and loss. One node: the lead.
• Leave the team unfedAn undirected team improvises a roadmap. The features will be competent and unwanted.
• Reach into vendor managementDictating salaries, offices or HR decisions breaks the accountability you are paying for.
• Let goodwill replace instrumentsBacklog, demos, quarterly reviews, escalation names. Structure survives personnel changes; goodwill does not.

The lifecycle: from contract to a team that feels like yours

Formation runs four to eight weeks for a first team, and its quality is set by how much you participate. The vendor sources candidates from bench and market; you interview every one at your hiring bar, including and especially the lead; and the team's working agreement, tools, channels, meeting rhythm, definition of done, ownership map, is written before the first sprint rather than discovered during it. Buyers who delegate formation entirely to the vendor receive a team optimized for the vendor's convenience: whoever was available, structured however is easiest to staff. The hours you spend interviewing in formation are the highest-leverage hours of the entire engagement.

The first 90 days are ramp, and they decide the engagement's ceiling. The team is absorbing your domain, codebase, standards and decision history, and the transfer speed is set by what you provide: architecture walkthroughs, domain immersion sessions, access to the people who hold context, and a starter slice of real roadmap chosen to teach the system's shape. Expect 50 to 70 percent of steady-state output during ramp and plan the roadmap accordingly; teams pushed to full feature velocity in month one skip the learning that makes month twelve fast. The classic ramp mistake is feeding the team isolated tickets to keep them busy, which produces motion, defers context transfer indefinitely, and creates the expensive-typists dynamic the model exists to avoid.

Steady state, from roughly month four onward, is where the model pays. The team owns systems, estimates from experience, pushes back on the roadmap with informed trade-offs, and its throughput on your codebase approaches what an equivalent employed team would do. The work at this stage is maintenance of the two accountabilities: your side keeps the backlog genuinely ready and decisions genuinely timely, and the vendor's retention machinery is watched through tenure reporting, because steady state is exactly when a complacent vendor starts quietly rotating your context into their newer clients. Growth belongs to steady state too: scale the team by adding people into a working structure, one or two at a time, absorbed by the team itself, rather than doubling headcount into a structure that has to re-form around the newcomers.

Evolution and ending are part of the model, not exceptions to it. Long engagements evolve: teams split as products grow, a second team forms in the same center, and at sufficient scale the engagement converts, to your own entity via build-operate-transfer, or to direct hiring of the team with a conversion fee, both of which belong in the original contract rather than in a tense year-three negotiation. Endings, when they come, are notice periods plus a handover the team itself documents, and the quality of that ending was actually determined years earlier, by whether documentation and shared ownership were part of done all along. A dedicated team you could not offboard cleanly was a dependency, not a department, and the difference was in how it was run, not in how it ended.

When to choose it, and how to buy it well

The fit conditions are few and hard. The work is a stream, not a scope: an evolving product roadmap with no natural end, which is what makes paying for standing capacity rational. The horizon is a year or more: shorter engagements never amortize formation and ramp, and fit augmentation or project work better. The size is four people or more: below that there is no team to structure. And your side can feed it: a named product owner with real authority and roughly ten hours a week, plus a technical counterpart for the standards conversation. Miss any one of these and a different model is cheaper and kinder; meet all four and the dedicated team is usually the strongest structure external engineering offers.

Vendor selection for this model weights differently than for projects. Delivery portfolio matters less; people machinery matters more: engineer retention rates on multi-year engagements, the realized tenure of teams they run for other clients, replacement speed evidence, and how their leads are grown and supported. Ask to speak to two clients who have run teams with the vendor for more than two years, and ask those references specifically about attrition, lead quality and what degraded over time. A vendor's market and segment position tells you their economics; only their long-run references tell you whether continuity, the thing you are actually buying, gets delivered.

Contract the model's specific risks rather than generic outsourcing boilerplate. Exclusivity in writing: the named team works only on your product. Named people with interview and rejection rights, including replacements. Tenure instruments: reassignment notice, quarterly tenure reporting, and retention economics that give the vendor a reason to keep your team stable, some buyers negotiate small tenure bonuses per engineer-year, which pay for themselves in avoided re-ramps. Team-health transparency: attrition and satisfaction reporting per quarter. IP assignment flowing through every individual. And the evolution terms discussed above: scale provisions, conversion and build-operate-transfer economics, and a notice-period exit with a documented handover obligation.

Then buy it like the long-run decision it is. Run a paid pilot quarter with the actual proposed team on a real roadmap slice before committing to the multi-year shape; the pilot reveals lead quality, communication reality and the vendor's staffing honesty at a fraction of the cost of learning them in year one. Negotiate the mix and the structure hard and the rate gently, the reverse of instinct, because a great team at five percent more beats a diluted one at five percent less by an amount that compounds monthly. And revisit the model choice annually as part of the quarterly review's year-end edition: needs change shape, teams earn conversion, and the best dedicated team engagements end either in decade-long partnership or in a planned graduation to your own center, both of which are successes.

Frequently asked questions

A dedicated team is a vendor-supplied unit that works only on your product under your roadmap, and its real product is continuity: the same engineers compounding context for years. Before buying one, read how the model actually works, including the direction-versus-management split that decides every engagement.