How to hire a dedicated software development team: the four decisions that come first

What the five-step guides leave out

Search for how to hire a dedicated software development team and the answer arrives before any page loads. Define the scope and the roles, shortlist vendors on a review site, interview the engineers, agree the intellectual property and confidentiality terms, then onboard with some time-zone overlap. It is correct. In September 2026 we read the guides that search engines returned for this question in the US and in India, and every one we read in full followed those steps in roughly that order.

It is also not where hires go wrong. The steps tell you what to do. They do not tell you what to decide, and a vendor will happily make each of those decisions for you: the team shape, the reporting line, the cadence, what the monthly figure covers. By the time you are comparing proposals, the proposals have already answered the questions you did not ask.

One disclosure before the rest. We sell dedicated software development teams, so we have an interest in you hiring one. Every guide we read on this question was also written by a company selling the model, and none of them said so. Put the questions below to us exactly as you would to anyone else.

Start with what the team will own, not the roles

Almost every guide opens by asking you to list the roles: two back-end engineers, a front-end engineer, QA, a project manager. It is the natural first step and it is backwards. A role list written first is a guess, and a vendor will staff a guess without argument, because a larger team is a larger invoice.

Start instead with the workstream: the part of the product or the system the team will own end to end. Write it as one sentence a stranger could check. "Own the order management service and its integrations with the warehouse and the payment provider" is a workstream. "Help with development" is not. Once that sentence exists, the roles follow in one conversation, because the systems it names decide the skills and the volume of change decides the size.

The one-page brief

Before any vendor call, put four things on one page:

• The workstream, in one sentence, and the systems and repositories it touches.
• What the first quarter should produce, written as outcomes someone can check rather than as tasks.
• Who on your side the team will answer to, and when that person is available.
• What the team must not change without asking: the shared schema, the public API, the deployment pipeline.

The last line matters more than it looks. It is where a dedicated team’s independence meets your architecture, and drift away from your architecture is the way this model most often fails. Naming the boundary in week one costs an afternoon. Discovering it in month six costs an integration project.

Decide who steers before you decide who builds

The second decision is the one the guides present as a benefit rather than a question. Somebody has to set the team’s priorities every cycle, answer its questions, and accept or reject what it ships. If that somebody is on your side and directs the engineers day to day, you are buying augmentation, whatever the proposal calls it. If the team has its own lead who turns your priorities into a plan and reports back on outcomes, you are buying a dedicated team.

Do not rely on the label to tell you which. Vendors sell the same arrangement as an extended team, a team extension, a managed team or a remote development team, and the same phrase means different things at different companies. Outsourcing, in the sense of handing a result to a supplier who delivers it under their own management, is a third arrangement again. Ask who sets the priorities each morning and who the engineers report to, and the answer places any proposal on one side of the line or the other.

The line also has consequences outside delivery. The first of the common-law tests the US Internal Revenue Service applies to worker classification is behavioural control: whether the company controls, or has the right to control, what the worker does and how they do it. Your jurisdiction will have its own version, and your counsel will ask which side of it you are on.

The dedicated team model still needs one person on your side. Not a committee, and not someone who runs the team’s internals: one named person who can answer a question within a working day and has the authority to say no. If nobody can do that, stop here, because that is the one thing no vendor can supply.

And if you already have direction to give and simply want more engineering capacity to carry it out, you want IT staff augmentation rather than a team. The comparison of the two models walks through that choice in detail.

How to test a retention claim

Every vendor says its engineers stay. The guides tell you to ask for an attrition percentage, and some vendors will give you one. It cannot be checked, it is calculated however the vendor chooses, and it does not protect you anyway. What protects you is what happens on the day a particular engineer on your account wants to leave.

The research explains why that day matters more than the number. A study of turnover on Chrome and on a project at Avaya found both exposed to knowledge losses more than three times larger than the expected loss, and over five times larger in historical simulation. The same study found that simple "truck factor" estimates exaggerate the danger, and that having a successor already working in the same files reduced the expected loss by as much as fifteen percent. The lesson is not to panic about departures. It is that planned succession measurably helps, and it only exists if someone arranged it before anyone left.

So test tenure and succession, not percentages:

• Ask which of their teams are still on the same product after two years, and ask to speak to one of those clients.
• Ask how many engineers on that account have changed, and how the last change was handled.
• Ask who else already works in the code each engineer on your team will own.
• Read what the agreement says about notice, overlap and replacement, and compare it with the six continuity terms we publish for our own teams.

Documentation is the other half. In a survey of 411 developers at Microsoft, 267 said that a lack of proper documentation increased the time it took a new hire to make a first contribution, and having a mentor was among the factors that shortened it. A replacement engineer arriving on an undocumented system is a new hire on the worst possible terms, so documentation and knowledge transfer belong in the contract as deliverables rather than in the vendor’s good intentions.

What the monthly figure contains

A dedicated team is billed monthly for the team, much like a retainer, rather than hourly for the work. That makes the budget predictable. It does not make two quotes comparable. Two honest proposals for the same team size can differ widely, and the difference is rarely the engineers. It is what else sits inside the figure.

We do not publish prices, and we would treat any range you find online with care, including the ones search engines now quote in their own answers. A range only means something once you know what it includes. Ask each vendor to break the figure into these lines and the comparison becomes real:

Overlap deserves a sentence of its own. In a study of distributed development at Lucent, work that crossed sites took about two and a half times as long as comparable work within one site, and the mechanism was the number of people involved rather than distance as such. The study dates from 2003 and the tools have improved, but the mechanism has not: every hand-off across a gap in working hours is a day a question waits for an answer.

Interview the engineers, then run a trial that can fail

Every guide says to interview the engineers who will actually work on your system rather than the account manager, and they are right. The part they leave vague is the trial. A two-to-four-week trial appears almost everywhere, rarely with a word about what it is meant to prove.

A trial is only useful if it can fail. Research on onboarding at Microsoft is a good guide to what to put in one. Interviewing 32 developers who had moved into new teams and 15 managers who had onboarded them, the researchers found that most managers started people on simple, well-defined tasks and increased the complexity over time, and that people handed the most urgent work first often described it as challenging and damaging to their confidence. Fourteen of the eighteen developers who had a mentor or onboarding buddy found that person helpful.

So design the trial the way a good onboarding starts:

1. One real, well-defined ticket from your backlog, in your repository, under your review process. Not a toy exercise, and not your most urgent problem.
2. A named person on your side who answers questions within a day and acts as the team’s first point of contact.
3. A code review by your own lead, looking at how the change was reasoned, not only whether it works.
4. A short written handover at the end: what was done, what they learned about the system, and what they would do next.

Judge it on the review comments and the handover note, not on speed. And be clear about what a trial cannot show. Managers in the same study described expecting a new developer to work independently at around six months. Those were expectations rather than measurements, but either way a few weeks tells you how a team starts, not whether it stays. That is what the continuity terms are for.

Plan the exit on the day you sign

Termination appears in every guide as a clause. It deserves to be treated as a plan, because the day an engagement ends is the day you find out what you actually own. The code is yours if the contract says so. The reasoning behind it, the environments, the credentials and the deployment path are yours only if someone wrote them down and handed them over.

Before you sign, agree what the final month looks like:

• The notice period each side gives, and whether it is the same in both directions.
• A handover overlap in which the outgoing engineers brief whoever comes next, paid for as part of the engagement.
• The documentation that must exist at exit: runbooks, architecture decisions, the deployment path, known issues.
• Who holds the credentials to every environment, repository and third-party account, and when access is revoked.

If you later decide to move the work into your own team or into the other engagement model rather than end it, the costs are different again, and what switching between the two models costs sets them out.

The questions to ask before you sign

Here are the decisions above turned into questions for the vendor. Put all eight to every company on your shortlist, including us, and compare the answers side by side. Most vendors answer the first two easily. The last four are where suppliers separate.

1. 01

   Which engineers, by name, and can we interview each one?

   Before the agreement is signed, not after. Ask whether any of them is shared with another client.

2. 02

   Who directs their work day to day?

   Their lead or yours. The answer decides whether you are buying a team or augmentation, and what your side has to supply.

3. 03

   What does the monthly figure contain?

   The roles inside it, whether QA, DevOps and delivery management are included, and how the ramp period is charged.

4. 04

   What happens when an engineer wants to leave?

   Notice, overlap with the replacement, and who pays for the replacement’s ramp. Ask to see it in the agreement.

5. 05

   Which of your teams have stayed on one product for two years?

   Then ask to speak to that client. Tenure you can check is worth more than any retention percentage.

6. 06

   What is documented as a deliverable?

   Architecture decisions, runbooks and the deployment path, kept current, so a departure does not take the reasoning with it.

7. 07

   What does ending the engagement look like?

   Notice in both directions, the handover, the credentials, and what the final month includes.

8. 08

   What would you refuse to take on for us?

   A vendor that cannot name anything it would decline is telling you something about how it takes on work.

When you should not hire a dedicated team

Three cases where the honest answer is something else, and we will say so on the call:

• The work is a defined system with an end. That is a fixed-scope build with one price, and buying it as a monthly team means paying for continuity you do not need.
• You have direction to give and need hands to carry it out. That is staff augmentation, and a team would duplicate the leadership you already have.
• Nobody on your side can answer a question within a day. Fix that first. A dedicated team without a steer drifts, however good the engineers are.