How long does it take to onboard a dedicated development team?

For a mid-sized codebase with reasonable documentation, expect first useful contributions within a fortnight, meaningful independent delivery by the second month, and full velocity around the third. The main variable is not the team's skill but whether someone who knows the system is available to answer questions daily. Where that person is busy on other work, the same ramp takes months instead of weeks.

What should a client prepare before a new team starts?

A local development environment with setup instructions someone has actually followed recently, all system access requested and approved before the start date rather than on it, and a first ticket that is real but bounded and touches the deployment pipeline end to end. If security policy requires background checks or signed agreements for external access, begin that at contract signature rather than at kickoff.

Why does onboarding cost more than people expect?

Because it is paid at full rate and appears as slowness rather than as an invoice line. Three costs run in parallel: the team's reduced output while learning, a senior internal engineer's interrupted attention for a month or two, and a heavier review load on the same people. Access delays add a fourth, where a full team is billed while waiting for credentials nobody realised were on the critical path.

Should a whole team start at once or in stages?

Staggering usually works better. Starting with the lead and one engineer, then adding the rest after a few weeks, means the second group is onboarded by people who already know the system. It also protects the client's own engineers, whose attention is the real constraint during ramp, since a team of four does not learn four times faster than one person.

How can you tell onboarding is going badly?

Questions stopping is the clearest warning: a team that goes quiet in the first month is usually blocked and unwilling to say so, or has started guessing. A first substantial pull request arriving late and very large means work happened without feedback for too long. Repeated questions about the same topic point to answers given in calls and never written down, which is a documentation problem rather than a team problem.

Do you pay the ramp cost again when someone is replaced?

Only partly, and the amount depends on whether knowledge sat with the team or with the individual. Where work is peer reviewed, decisions are written down and no one person solely owns a subsystem, a replacement absorbs in a couple of weeks. A reasonable contractual position is that the supplier funds a replacement's ramp, since the client already paid to build that knowledge once and did not choose the departure.

Dedicated teams guide

How long does it take a new team to become productive?

Longer than the proposal implies, and most of the delay is on your side rather than theirs. A competent engineer joining an unfamiliar codebase needs weeks before their output is worth what you are paying, and that period is paid at full rate. It is the largest hidden cost in the engagement, it is largely determined by preparation you control, and it is the reason short engagements rarely make financial sense.

What does ramp actually consist of?

Three separate things that people collapse into one: getting access, learning the system, and learning the domain. They have different lengths, different owners, and only the middle one is the supplier's problem.

Access is administrative and is the most avoidable delay in the whole engagement. Repository permissions, cloud accounts, VPN, secrets, staging environments, third-party services, laptops meeting your security policy. It should take days and routinely takes weeks, because approvals sit with people who did not know they were on the critical path.

Learning the system means the codebase, the deployment process and the local development setup. Learning the domain means what the business actually does, what the words in the tickets mean, which customers matter and why an apparently strange rule exists. Domain knowledge is the long one and no amount of engineering seniority shortens it.

How long is realistic?

For a mid-sized codebase with reasonable documentation, expect first useful contributions inside the first fortnight, meaningful independent delivery by the second month, and full velocity somewhere in the third. A team of four does not reach full output four times faster; the constraint is the attention of whoever answers their questions, not the number of people asking.

The main variable is not the team's skill, it is whether someone who knows the system is available to them. A codebase with a knowledgeable engineer answering questions daily ramps a team in weeks. The same codebase with its only expert on another project ramps the same team in months, and the difference is entirely on the client side.

This is why staggered starts usually beat a full team on day one. Bringing in the lead and one engineer first, then the rest a few weeks later, means the second wave is onboarded by people who now know the system, and it protects your own engineers from being consumed by questions.

Phase	Typical length	Who owns it	What it costs you
Access and environments	Days if prepared, weeks if not	You	Full rate for people who cannot start
Codebase orientation	One to two weeks	Supplier, with your answers	Your senior engineer's attention
First independent delivery	Weeks two to six	Shared	Heavy review load on your side
Domain fluency	Two to three months	You, by explaining	Rework where guesses were wrong
Full velocity	Around month three	Shared	Nothing further, if the team stays

What should you prepare before day one?

A running local environment, documented in a file that someone followed recently. This is the single highest-value piece of preparation, because a setup process that takes a new engineer three days takes every new engineer three days, and you will onboard more people than you expect.

Then access, requested and approved before the start date rather than on it. Write down every system a new engineer needs, find the approver for each, and get them provisioned in advance. If your security process requires background checks or signed agreements before external access, start that at contract signature, not at kickoff.

Then a first ticket that is real but bounded. Not a toy task, which teaches nothing and signals distrust, and not a critical path item, which turns a learning exercise into a risk. Something genuinely useful that touches the deployment pipeline end to end, so the first week produces a merged, deployed change and everybody learns where the friction is.

Who on your side pays the real cost?

Your most knowledgeable engineer, in interrupted attention, and this cost is almost never planned for. Onboarding a team of four consumes a meaningful share of one senior person's capacity for the first month or two, and if that person also has delivery commitments, one of the two will fail.

The way to make this survivable is to make it explicit. Name the person, tell them this is their job for the period, and reduce their other commitments accordingly. Teams that skip this step get a senior engineer who answers questions resentfully between their own deadlines, which slows the ramp and poisons the relationship in the first month.

The second cost is review load. Early work from a new team needs closer review than steady-state work, and review is done by the same people. Budget for it, and prefer a supplier whose lead does the first pass so your reviewers see work that has already been checked.

How do you know the ramp is going wrong?

The clearest signal is questions that stop. A team asking a lot in week two is normal and healthy; a team that goes quiet is either blocked and unwilling to say so or has decided to guess. Silence in the first month is a warning, not a sign of competence.

The second signal is pull requests that are large and late. If the first substantial change arrives in week four as a thousand-line pull request, the team has been working without feedback for too long, which means either they were not unblocked or nobody was reviewing. Both are fixable immediately and expensive to leave.

The third is repeated questions about the same thing, which usually means the answer was given verbally in a call and never written down. That is a documentation failure rather than a team failure, and the fix is to answer the next one in a document rather than a message.

Does ramp cost repeat when someone is replaced?

Partly, and how much depends on whether the team retained the knowledge or the individual did. A team where work is reviewed by peers, decisions are written down and nobody is the sole owner of a subsystem absorbs a replacement in a couple of weeks. A team where one person held the whole picture pays most of the ramp again.

This is worth raising in the contract rather than after the first departure. A reasonable position is that the supplier funds the replacement's ramp, because you already paid to build that knowledge once and the departure was not your decision. Suppliers vary on this and many will agree if asked before signature.

It is also the strongest practical argument for insisting on shared ownership from the start. Pair reviews, documented decisions and rotating responsibility all look like overhead in month one and turn out to be the thing that makes month nine survivable when somebody resigns.

Common questions

How long does it take to onboard a dedicated development team?: For a mid-sized codebase with reasonable documentation, expect first useful contributions within a fortnight, meaningful independent delivery by the second month, and full velocity around the third. The main variable is not the team's skill but whether someone who knows the system is available to answer questions daily. Where that person is busy on other work, the same ramp takes months instead of weeks.
What should a client prepare before a new team starts?: A local development environment with setup instructions someone has actually followed recently, all system access requested and approved before the start date rather than on it, and a first ticket that is real but bounded and touches the deployment pipeline end to end. If security policy requires background checks or signed agreements for external access, begin that at contract signature rather than at kickoff.
Why does onboarding cost more than people expect?: Because it is paid at full rate and appears as slowness rather than as an invoice line. Three costs run in parallel: the team's reduced output while learning, a senior internal engineer's interrupted attention for a month or two, and a heavier review load on the same people. Access delays add a fourth, where a full team is billed while waiting for credentials nobody realised were on the critical path.
Should a whole team start at once or in stages?: Staggering usually works better. Starting with the lead and one engineer, then adding the rest after a few weeks, means the second group is onboarded by people who already know the system. It also protects the client's own engineers, whose attention is the real constraint during ramp, since a team of four does not learn four times faster than one person.
How can you tell onboarding is going badly?: Questions stopping is the clearest warning: a team that goes quiet in the first month is usually blocked and unwilling to say so, or has started guessing. A first substantial pull request arriving late and very large means work happened without feedback for too long. Repeated questions about the same topic point to answers given in calls and never written down, which is a documentation problem rather than a team problem.
Do you pay the ramp cost again when someone is replaced?: Only partly, and the amount depends on whether knowledge sat with the team or with the individual. Where work is peer reviewed, decisions are written down and no one person solely owns a subsystem, a replacement absorbs in a couple of weeks. A reasonable contractual position is that the supplier funds a replacement's ramp, since the client already paid to build that knowledge once and did not choose the departure.