Onboarding contract developers well comes down to four things, in this order: paperwork signed before access, access scoped to what the first ticket needs, a first pull request open within a week, and a go/no-go review on day 14. Everything else in a standard onboarding checklist (culture decks, benefits, org charts) can be skipped. This plan covers one external engineer, from any vendor or direct, joining a team you already run. It sits inside the wider set of Engineering management guides for CTOs and VPs of Engineering.
The step sizes, dates and thresholds below are our judgment unless a source is named. No benchmark exists for a "typical" contractor ramp, so treat day numbers as defaults to adjust for your sprint length.
Why contractor onboarding is not employee onboarding
A contractor is judged on value per unit of time, and the unit is short. LeadDev's piece on what seven years as a contractor taught one engineer about onboarding frames it with simple arithmetic: a week spent getting up to speed is about 2% of an employee's first year but about 8% of a three-month engagement. That's the author's framing, and the arithmetic is right.
The consequence is practical. Every day a contractor waits for a login is expensive in proportion. The second difference is that they aren't members of your organization, so access, IP and exit all need explicit handling that an employee gets by default through HR. Both differences point at the same fix: do the work before day one.
How to onboard a contract developer in 14 days
1. Sign IP assignment and confidentiality before any access
Nobody gets a repo invite, a Slack seat or a staging URL until the IP assignment and confidentiality terms are signed. Once the code is on their laptop, your bargaining position on the paperwork drops sharply. If the engineer comes through a vendor, confirm the vendor's contract already assigns their work to you and that the NDA covers the individual, not just the company.
We won't make legal claims here, because the position depends on the jurisdiction and the contract wording. For the EU side, who owns contractor code in the EU walks through what the assignment needs to say. The other legal questions around a contract hire, such as contractor status and GDPR, are in our overview of legal requirements for hiring contract developers in Europe. Have a lawyer read your actual template.
2. Write the access list once, as both grant list and revocation list
Make one document with every system the engineer will touch: repos, CI, cloud console, ticket board, chat channels, password vault, VPN. On day 14 or day 90, that same list is your offboarding checklist. If a system isn't on the list, nobody should have granted it.
On GitHub, the right object is the outside collaborator. GitHub defines an outside collaborator as someone who isn't a member of your organization. They can't join teams, they're added repo by repo, they use a paid license on a private repository (unless you're on a free plan), and they have to be added to forks separately. If your organization requires two-factor authentication, they must enable it before accepting the invite. Those constraints are what you want: repo-level, never org-wide, and no shared accounts.
3. Prepare a first ticket and test credentials before day one
LeadDev's contractor lists three things worth stealing: a pre-selected first task, credentials that were tested before the start date, and a named buddy. A broken login on day one burns hours of a short engagement before anyone has written a line.
Pick a first ticket that touches real code but has a small blast radius: a bug with clear reproduction steps, a missing test, a contained feature. Write acceptance criteria into the ticket. Then log in with a throwaway account that mirrors the contractor's permissions and confirm you can clone, build, run the tests and open a draft PR.
4. Run day one: context, one buddy, one channel
Keep day one short and concrete. A 45-minute call covers what the product does, how the team ships and where the first ticket lives. Then the buddy (a mid or senior engineer on your team who has agreed to answer questions within hours) pairs with them to get the project running locally.
Put the contractor in one team channel, not twelve. Work async-first, and skip the all-hands and the culture tour. If the engineer is in a different timezone, agree two overlap hours and write them down. More on running a contractor across timezones after onboarding, including the day-14 and day-30 decisions, is in how to manage nearshore developers over a full engagement.
5. Get the first PR open by day 3-5 and merged by day 10
These dates are judgment, not benchmarks. A draft PR by day 3-5 shows that access works and the engineer understands the codebase well enough to change it. A merge by day 10 leaves four days to judge the work before the review.
Published plans disagree with themselves on this. Full Scale's 90-day onboarding guide puts the first merged feature at day 10 in its milestone text and around day 15 in its metrics table, so use its numbers as a rough shape rather than a target.
A common reason a PR misses its date is review lag on your side rather than slow coding. Name a reviewer for the contractor's first three PRs and set a turnaround, using the habits in code review best practices for distributed teams.
6. Raise access in steps, only after the first merged PR
Start with write access to one repo. After the first PR merges cleanly, add the second repo, staging, or the CI secrets the next ticket needs. Each step should be triggered by a ticket that requires it, not by the calendar.
Branch protection does the heavy lifting here. GitHub's protected branches documentation describes required approving reviews, under which collaborators can only change the protected branch through a pull request, and the option to restrict who can push at all. Turn both on for main before the contractor arrives. It protects you from mistakes as much as from bad intent. Admins can bypass these rules unless you also enable "Do not allow bypassing the above settings", so keep the contractor's role below admin.
7. Hold the day-14 review: extend, convert or replace
Spend 30 minutes with the buddy, the reviewer and whoever owns the engagement. Look at three things: what merged, how many review rounds each PR took, and whether the engineer raised blockers early. Then pick one of three outcomes: extend as-is, convert to a longer engagement with wider access, or replace.
Decide in the room and write it down. If the signals are bad, check your side first (access delays, ticket quality, review lag), then move to a documented replacement process (linked at the end of this article). The sooner a replacement starts, the less of the engagement you lose.
A short check-in with the engineer's own view of the first two weeks is worth adding, run by someone other than their direct lead, because contractors may not volunteer problems to the person who decides on their extension. The format is close to a skip-level meeting.
8. Plan offboarding on day one
Write the exit before the start. The access list from step 2 is your revocation list, the handover doc is a standing file the engineer updates weekly, and the IP assignment from step 1 is already signed. Offboarding then takes an hour instead of a week of archaeology, and it doesn't depend on a goodwill conversation at the end.
The checklist below covers what to revoke and what to confirm.
Offboarding checklist
| Item | What to do |
|---|---|
| Repo access | Remove the outside collaborator from every repo on the access list |
| Forks | Private-repo forks are deleted when access is removed; confirm none are hosted elsewhere |
| Local clones | Retained on the engineer's machine, so ask for written confirmation of deletion |
| Cloud, CI, SaaS, VPN | Revoke each system on the list, then check the audit logs for the last login |
| Shared secrets | Rotate anything the engineer could read, even if they never used it |
| Handover doc | Review it with the next owner while the engineer is still reachable |
| IP and confidentiality | Confirm the signed assignment is filed and the NDA obligations are restated in the exit note |
The removal effects come from GitHub's guide to removing an outside collaborator: forks of private repositories are deleted, but local clones stay where they are. That's why the table asks for written confirmation, and why secrets rotation is not optional. To remove someone from all repositories: profile menu > Organizations > your organization > People > Outside collaborators, tick the person, choose Remove from all repositories, then confirm. For a single repository, use the menu beside their name: Manage > Manage access > Remove access to this repository. Removing a collaborator doesn't reduce your paid licence count automatically.
What this means for your next contractor decision
The day-14 review is a real decision only if reversing it is cheap. If you're locked into a minimum commitment or a fee to swap someone out, you'll talk yourself into extending, and the plan above loses its value. Before the next engagement, check three terms: the minimum hours, what a replacement costs, and how fast a new engineer can start.
For reference, HighCircl has no minimum hour commitment, replaces an engineer at no additional recruitment cost if the engagement isn't working, and matches within 72 hours. Whatever vendor you use, get equivalent terms in writing. In our judgment, any contract that makes day 14 expensive to act on has the wrong incentive.
Then run the plan on the next engineer and keep the access list, the review notes and the handover doc as your template. If day 14 comes out as a "replace", handling an underperforming staff augmentation developer is the next read.
FAQ
How long does it take to onboard a contract developer?
There's no sourced industry number. As a working default (our judgment), aim for a first PR open by day 3-5, a first merge by day 10 and a decision at day 14. Full productivity takes longer, and that's fine, as long as the early signals show up on time.
Should contractors get full repo access on day one?
No. Give them one repo with branch protection on, add more after the first merged PR, and keep them as outside collaborators rather than organization members. Requesting every account and permission up front, as at least one published onboarding plan does, gives you the most exposure and the least information.
Who owns the code a contractor writes?
It depends on the contract and the jurisdiction, and without an explicit assignment you can't assume it's you. Get the IP assignment signed before access, and have a lawyer check the wording. The IP assignment guide linked in step 1 covers the EU position.
What do you do when access is still blocked on day 3?
Treat it as your problem first. One staffing firm's guide, summarized in our underperformance article, lists access still blocked after day 2 and no PR by day 4 as red flags. Escalate the access request the same day, and don't count blocked days against the engineer in the day-14 review.
What is the 30-60-90 rule, and does it fit a contractor?
It's a widely used framework for an employee's first three months, usually with a distinct goal per 30-day block. A three-month contractor has no room for that pace. Compress it to the 14-day plan above, then decide whether a longer engagement earns a 30-60-90 of its own.