Onboarding an external developer into your team: access, method, code review

Onboarding an external developer means giving them in a few days what an employee receives over a few months: access, context, the team’s rules. Poorly prepared, their arrival costs weeks and opens access that nobody remembers to close. Well prepared, it fits in a list: a contract signed before the first access, named and limited accounts, an environment that installs without help, a first task delivered quickly, systematic code review, and a departure planned from day one.

This guide is for executives, CTOs and technical leads who are welcoming a freelancer, a developer from a services company or a remote dedicated team. It gives no typical duration and no rate: it gives the order of things and the points not to forget.

What should be ready before an external developer arrives?

Before an external developer arrives, three things must be ready: the written framework, a point of contact in the team and a first batch of work. What is not settled before day one is rarely settled afterwards, because the work has already started.

• The signed services contract, with the assignment of rights in the code, a confidentiality clause and reversibility: what happens to the code, the documentation and the access at the end.
• If the developer can see personal data, the processor clauses of Article 28 of the GDPR: the French data protection authority (CNIL) advises against starting a service without a contract that includes them.
• A named point of contact on your side, available to answer questions and review code during the first weeks.
• Minimal, up-to-date documentation: how to install the project, how it is deployed, where architecture decisions are recorded.
• Three or four tickets ready, described and prioritised, including a small one to start with.

The contract is not just about price. Our guide to the application maintenance contract details the clauses on ownership, security and reversibility; they also apply to a dedicated developer.

What access should an external developer get?

An external developer receives accounts in their own name, with only the rights they need for their tasks. This is the principle of least privilege, which the CNIL recommends for any access right: define access profiles, have each request approved by a manager, remove access as soon as it is no longer needed and review access rights at least once a year.

Data deserves particular attention: developing on a copy of production exposes personal data to people who do not need it. Our guide to test data and the GDPR explains how to test without copying production.

How do you make them productive in the first week?

An external developer becomes productive once they have delivered a first real change, from their machine all the way to production. The goal of the first week is not to understand everything: it is to push a small change through the whole pipeline and see where it gets stuck.

• Day one: accounts opened, the local environment installed from the documentation, a conversation with the point of contact about the architecture and priorities.
• The following days: a small, real first task (a fix, a label, a missing test), reviewed then merged.
• By the end of the week: that task deployed through the usual pipeline, and a list of what was missing from the documentation.
• Then: tasks of increasing size, on different parts of the application.

Whatever the newcomer struggled to install or understand is valuable information: ask them to complete the documentation themselves as they go. It will help the next person, and it often reveals part of the technical debt the team no longer sees.

Include them in the team’s rituals from day one: daily stand-up, planning, demos. An external developer kept out of the discussions produces code that matches the ticket, not necessarily the need.

How should code review be organised?

Every change by an external developer goes through a pull request reviewed by a team member, on a branch nobody can modify directly. This is not mistrust: it is the rule that keeps code consistent when several people work on it, internal and external alike.

Code platforms allow this without any extra tool. On GitHub, a branch protection rule can require a number of approvals before any merge, approval from the designated owners of part of the code (CODEOWNERS file) and passing status checks. GitLab and Bitbucket offer equivalent settings.

• A protected main branch: no change without an approved pull request.
• Automated checks before human review: tests, static analysis, formatting. The review then focuses on logic, not layout.
• Written review criteria: naming conventions, expected tests, security, documentation.
• An agreed review time, so that a request does not stay blocked for days.
• Short pull requests: one change per request, easier to review and to revert.

Review works both ways. A senior developer coming from outside sees what the team no longer notices: inviting them to review others’ code too speeds up their understanding of the project and surfaces useful points. For automated checks to mean something, automated testing is often the first project.

Who steers the work, who manages the developer?

In a service arrangement, the client expresses the need, sets priorities and approves the work delivered; the provider manages its developer: assignment, leave, evaluation, replacement in case of absence. This split is not only a matter of organisation: in France, it bears on the legal framework of the service.

The French Labour Code prohibits “any for-profit operation whose exclusive purpose is the lending of labour”, outside the cases it provides for, such as temporary work (Article L8241-1). It also prohibits marchandage, a for-profit supply of labour that harms the employee or circumvents the law or a collective agreement (Article L8231-1). These texts do not themselves draw the line between a service and the lending of labour: it depends on how the service is actually carried out. For a specific arrangement, an employment lawyer will answer better than a guide.

In practice, a few markers keep the split clear:

• You set priorities and approve the work through tickets and the team’s rituals; the provider organises how to deliver them.
• The developer’s leave, working hours and evaluation are a matter for their employer.
• A contact on the provider’s side, a lead or an account manager, follows the service and organises replacement in case of absence.
• Deliverables, volume and deadlines are discussed with that person, at the agreed pace.

The billing model matters too: on a fixed price, the provider commits to a result; on time and materials, to skills and time. Our guide fixed-price or time-and-materials TMA compares what each model commits to.

Who owns code written by an external developer?

Code written by an external developer does not automatically belong to the company paying for it. Under French law, as Bpifrance Création points out, the client does not become the rights holder by default: an assignment contract must be concluded, and without it “the provider remains the owner of the code delivered”. For an employee, by contrast, the rights in software created as part of their job belong to the employer without any specific clause.

So check that the assignment of rights is in the services contract, or in an appendix, before the first line of code. Also check that the code repository, the hosting and the third-party service accounts are in your company’s name, not the developer’s or their employer’s. Our guide to taking over a web application shows what an oversight on this point costs on the day you need to change provider.

How do you prepare their departure from day one?

An external developer’s departure is prepared when they arrive: that is when you know which access they receive and what will need documenting. Prepared, a departure comes down to a handover; improvised, it leaves accounts open and knowledge in a single head.

• A list of the access granted, kept from day one, which becomes the list of access to close on the last day.
• Accounts deleted on the day of departure, and the secrets they could see rotated.
• Documentation kept up as you go, rather than written in the last week.
• Handover time with the person taking over their topics.
• The return of code, documentation and data provided for in the contract.

The CNIL lists among the mistakes to avoid forgetting to delete the accounts of people who have left the organisation. On the provider’s side, continuity should be asked for too: replacement in case of absence and knowledge transfer are part of what a serious reinforcement provides.

Frequently asked questions

Onboarding is prepared like a production release

Onboarding an external developer is a series of simple steps in the right order: sign, open only what is needed, get them delivering quickly, review everything, and prepare the departure from the start. These rules protect your code and your data; they also make the developer useful sooner.

iones’ dedicated developers join your tools, rituals and conventions from our nearshore team in Tunisia, supervised by an iones lead who organises continuity and knowledge transfer. To talk about it, write to us.