What a dedicated team actually is
A dedicated development team is a group of engineers who work on your project through a supplier rather than on your payroll. They are not shared across other clients, and they normally include the roles a project needs rather than developers alone: designers, QA and DevOps as well.
The important part is not the label. It is that the supplier carries the hiring, the contracts, the replacement risk and the equipment, and you direct the work. If a supplier is selling you a "dedicated team" but rotating people between clients, it is staff augmentation with a better name.
Three ways to add capacity, and how they differ
Most companies arrive asking for one of these and need a different one. The difference that matters is how long the need lasts and who carries the risk.
- One or two specialists
- You have a team and a gap in it — a particular skill, for a particular stretch. Fastest to arrange, and the easiest to stop. Best when the gap is narrow and well defined.
- A dedicated team
- You have a plan and not enough people to carry it out. Slower to assemble than one specialist, faster than hiring. Best when the work will last quarters rather than weeks and you want one group accountable for a whole area.
- A permanent hire
- The need is indefinite and the knowledge should stay in your company. The slowest of the three and the hardest to reverse, which is exactly why it is the right answer when the role is genuinely permanent.
What the day rate does not show you
Comparing suppliers on rate alone is how companies end up paying twice. The costs that do not appear on the quote are the ones that decide whether the engagement works.
Onboarding is the first. A team that needs six weeks to become useful is more expensive than a team on a higher rate that needs two. Ask how the supplier plans to get people productive, and who on their side carries that.
Continuity is the second. If the people who learned your system leave the account after three months, you pay the onboarding cost again. Ask what their turnover on a typical engagement looks like, and what happens contractually when someone is replaced.
Overlap is the third. Distributed teams work well when enough of the day is shared to make decisions in. Four hours of overlap is usually workable. One is not.
Questions worth asking any supplier
- Who exactly is on the team?
- Names, seniority and what else they are working on. If you cannot find that out before signing, you will not find it out afterwards.
- Who owns the code?
- It should be you, by default, in your own repositories and accounts — not handed over at the end of the contract as a deliverable you have to ask for.
- What happens if this does not work?
- Notice period, how work in progress is handed back, and whether the documentation to run it without them is part of the work or an extra.
- Who do I talk to when something is wrong?
- An engineer on the team, or an account manager relaying messages. The difference shows up on the first bad week.
How to tell it is working
Set this before the team starts, not after the first disagreement. The useful signals are boring ones: work reaching your users at a steady rate, the team asking questions that show they understand the business rather than just the ticket, and problems surfacing early instead of at the deadline.
Agree what "done" means for the first piece of work and who is responsible for deciding it. Most engagements that fail did not fail on capability — they failed because nobody wrote down what success looked like.
When a dedicated team is the wrong answer
If you do not yet know what you are building, a team will build the wrong thing efficiently. Planning first is cheaper: a few weeks of working out what is worth building often saves months of the wrong build.
If the work is a short, well-bounded task, one specialist will do it with less overhead. And if the knowledge genuinely needs to stay in your company for years, hire — accept that it takes longer, and start now.