Buying a dedicated development team is the easy part. Keeping it from drifting into order-taking is the part nobody writes down.

Most pages about the model stop at the definition: you rent a team, they work only on your product, you pay monthly. That is accurate and almost useless. The teams that produce and the teams that stall are bought the same way. They differ in who owns the backlog, where architecture decisions get made, and what the word "done" means on a Tuesday afternoon when nobody senior is online.

This is the operating side of the model, written from how these teams actually run.

What a dedicated development team actually is

A dedicated team is a group of engineers who work on your product and no one else's, usually under a monthly agreement, usually assembled and employed by a partner in another country.

Three things follow from that, and they matter more than the definition:

• You get continuity, not tickets. The same engineers keep working on the same codebase, so the knowledge they build stays in your product instead of evaporating at the end of a statement of work.
• You get capacity, not an outcome. Nobody has promised you a finished feature by a date. You have promised yourself that, and the team is how you get there. If you have no one steering, the team will still be busy and you will still be behind.
• The partner carries the employment side. Recruiting, payroll, equipment, office, replacement when somebody leaves. That is the actual service being sold.

That third point is why the model exists. The second point is why it fails.

When a dedicated team beats project outsourcing

Project outsourcing — a fixed scope, a fixed price, a delivery date — is the better buy when you genuinely know what you want and will not change your mind. Fixed scope is a promise in both directions. It protects your budget and it protects the vendor's margin, which is why changing anything mid-project costs so much.

A dedicated team is the better buy when any of these are true:

• The product is still moving. Priorities change monthly, and you want the cost of changing your mind to be near zero.
• The work has no end date. Someone has to own this system in eighteen months.
• You are building internal knowledge, not buying a deliverable. An integration layer, a data platform, anything where next year's work depends on this year's decisions.
• You need to scale a team faster than you can hire locally.

If you are weighing this against adding individual engineers to your existing team, the difference is management: with a dedicated team you also get the partner's delivery structure. We walk through all three shapes in ODC vs dedicated team vs staff augmentation, and the pure resourcing route is on our staff augmentation page.

How to size the team

Start smaller than feels right.

The Scrum Guide puts it plainly: a Scrum Team is "typically 10 or fewer people", small enough to stay nimble and large enough to finish meaningful work in a Sprint. That ceiling is not Scrum trivia. It is a communication limit. Every person added to a team adds a communication path to every other person, and past roughly ten the coordination cost starts eating the capacity you just bought.

A practical shape for a first dedicated team:

• 4 to 6 engineers. Enough to cover frontend, backend and a shared concern like data or infrastructure, without a standing meeting problem.
• One QA engineer from day one, not added later when quality becomes a complaint.
• One technical lead who is accountable for how the code is built.

If you need more than ten people, run two teams with separate backlogs and a clear seam between them — a service boundary, a product area, something real. Do not run a team of fifteen.

The four roles that decide whether it works

Titles vary by partner. The accountabilities do not.

The product owner sits on your side. This is the one role you cannot outsource. Somebody at your company has to decide what gets built next and be available to answer questions. If that person has four hours a week, your dedicated team has four hours a week of direction.

The technical lead owns how. Architecture, code review standards, technical debt. They should be arguing with you occasionally. A technical lead who agrees with every request is an expensive typist.

The project manager or bridge engineer owns the flow of information. They run the cadence, surface risk early, and make sure a question asked at 4pm in Hanoi is not blocking work at 9am the next morning. On teams spanning time zones and languages, this role is the difference between a two-hour delay and a two-day one.

QA owns the definition of done. Not "it works on my machine" — the actual, written, agreed standard.

Who owns the backlog, the architecture and "done"

This is where most dedicated teams quietly go wrong. Everything is friendly, the standups happen, the velocity looks fine, and six months later the system is a pile of reasonable local decisions that do not add up.

Write down the split before you start. A workable default:

Two rules make that table work in practice.

Architecture decisions get recorded, not remembered. A short written record for anything structural: what we chose, what we rejected, why. Three paragraphs is plenty. Without it, the reasoning leaves when the engineer does, and the next team re-litigates a decision that was already made correctly.

"Done" is written down and includes tests. If "done" means "the developer says it is finished", you have no quality bar, only a reporting line. A real definition of done names the tests, the review, the documentation and the environment it has to run in.

Running the first 90 days

The first three months set the pattern. What good looks like:

Weeks 1–2: environment and first merge. The goal is one small change, written by the new team, reviewed and merged to your main branch. Not a feature — a change. This exercises access, CI, review and deployment in one go, and it surfaces every access problem while they are cheap. If a new team cannot merge anything in two weeks, the blocker is almost always permissions, not people.

Weeks 3–6: first real feature, deliberately small. Something with a visible outcome and a narrow blast radius. You are testing the process, not the people.

Weeks 7–12: cadence and ownership. The team should now be raising problems before you find them, pushing back on unclear requirements, and proposing technical work you did not ask for. That last one is the signal to watch. A team that only does what it is told has not taken ownership, and it never will on its own.

Run a written review at 30, 60 and 90 days against what you agreed, not against a general feeling.

Why Vietnam

Vietnam has become a default option for engineering capacity, and the reasons are structural rather than promotional.

The country's economy grew 8% in 2025, with GDP per capita rising from under $500 in 1986 to $5,066 in 2025, according to the World Bank. That trajectory matters to you for an unglamorous reason: it funds the universities and the local tech employers that produce and retain engineers, which is what keeps a team stable for more than a year.

The practical factors for a dedicated team:

• Time zone. GMT+7. Roughly three to four hours behind Australia's east coast, an hour ahead of Singapore, and a workable afternoon overlap with Europe. For the US, expect the overlap to be your morning and their evening, and design the cadence around it rather than pretending it does not exist.
• Retention. A stable team is worth more than a cheap one. Continuity is the whole value of the dedicated model, and it is destroyed by churn.
• English and process maturity. Varies by company far more than by country. This is a question to ask about a specific team, not a nation.

On cost: Vietnam is used as an engineering location partly for cost reasons, but the number that matters to you is not an hourly figure. It is the total of salary, recruiting, management overhead, attrition and the rework caused by unclear requirements. A team that costs less per head and needs twice the supervision has not saved you anything. We go through those drivers in our guide to software outsourcing in Vietnam.

What to ask us before we start

Questions worth putting to MOHA directly, and that we will answer for your specific case:

• Which engineers would be on this team, and what have they built?
• How is the technical lead role staffed, and what are they accountable for?
• What does your definition of done look like on a current team?
• How do you record architecture decisions?
• What happens when someone leaves the team?
• What does the reporting cadence look like, and who attends?
• How do you handle a sprint where the requirements turn out to be wrong?

MOHA runs offshore development centres and dedicated teams from Hanoi for clients across 15 countries, with delivery habits — written specifications, test evidence, bilingual project management — built up through years of work for Japanese clients, where documentation and QA discipline are not optional. You can see the shape of that work on our portfolio and our offshore development center page.

If you are considering a dedicated team and want to talk through the team shape, the roles and how the first 90 days would run for your product, contact us and we will go through it with you.