The client signed, and the external team starts tomorrow. Someone on your side sends an invitation to the repository, a password for the test server and an API key for the payment system, all in one message, because "they need to get started." Everyone is happy, and that message contains exactly what will be hard to collect back.
Working with an external development team requires deciding several things in advance that happen without thought in an internal team, and writing them down. This list suits any vendor you choose, including us.
Who owns the code, and which document says so
The first point is legal. The code written for you must be yours, and the agreement should say so explicitly, including copyright and intellectual property in everything created during the work. Pay attention to existing components that belong to the vendor or a third party: what exactly is delivered to you, and under what license terms. Check licenses on open-source code that goes into the product as well, because some licenses impose obligations on the product that uses them.
Don't settle for a verbal understanding. The wording of the agreement is a matter for a lawyer who specializes in the field, not for a blog article, but the question "who owns the code on the day the relationship ends" is one you can and should ask in the first meeting.
The technical side of the same question: the code lives in a repository that you hold, in your own organization on GitHub, GitLab or Bitbucket, and the external team is invited into it. Also ask for an orderly handover at the end: all the repositories, the run scripts, the infrastructure configuration and the list of dependencies, so a new developer can continue without the previous team. The reverse (the team works in its own repository and you get a copy at the end) is a situation to avoid, because the code history and the access stay with someone else.
Permissions, secrets and environments
Permissions: every person in their own account
A few rules that look obvious and are often violated:
- A personal account for every developer. A shared team password means you can't tell who did what, and you can't remove one person without changing it for everyone.
- Permissions by role. A frontend developer doesn't need access to the production database. A developer working on a feature needs write access to their own branch, and no permission to merge into main.
- Two-factor authentication in every system that supports it, and SSO if you have it.
- A protected main branch: merging only through a pull request with a review by someone on your side. This prevents both mistakes and uncontrolled changes.
- A periodic permissions review. People move between tasks, and whoever received access for one purpose keeps it long after the need is gone.
Deploying to production
The permission to deploy a version to production should also stay with you or with one defined person. The team prepares and hands over the version, and you approve. That way there is always one point where someone on your side sees what is about to go live, and the changes that went live are documented.
Secrets and environments
Keys, passwords and tokens don't go into code and aren't sent in chat. They are kept in a dedicated mechanism (a secrets manager or environment variables in the CI tool) and delivered to each environment separately. Run an automated scan that detects secrets accidentally committed, and assume that a secret exposed once, even for an hour, gets replaced.
The second point is separating environments. Development and testing run on test data, not on real customer data. When a developer truly needs something that resembles production, create a masked copy. Access to production, if it is needed at all, is given to a limited person for a defined period.
One of the most common mistakes in any development team, internal or external, is an access key that accidentally lands in the code repository. So work with scanning tools that detect secrets before they are saved, and define a clear procedure for when it happens: replace the key immediately, check who used it, and document.
People, AI tools and offboarding
Who is the employer and what do they sign
Ask every vendor: who employs the developers, and what do they sign? With us, the developer is employed by our company in the Philippines, and if the client asks, the developer also signs an NDA. This is a question to ask every vendor, and the answer is worth seeing in a document and not only hearing.
AI tools and code privacy
This point is relatively new and so it gets forgotten. Developers today use code assistants and chats to work faster, and sometimes paste code snippets, logs or data into them. A clear policy should set which tools are allowed, under which privacy settings (for example, ones that don't use input for training), and what must never be pasted under any circumstances: secrets, customer data and personal information. It is easy to slip in good faith, so the rule is written down and stated at the start.
If the project itself involves AI and the data is sensitive, you can consider a model that runs in your own environment. We wrote about this dilemma in when to add AI to your product.
Offboarding: prepare it on day one
Every developer leaves at some point, at the end of a project or during it. You need a checklist that runs the same day: removal from the repositories, revoking access to environments and work tools, replacing the secrets the person knew, and checking that no personal accounts or keys remain active. If nobody is defined as responsible for the checklist, it won't get done.
Agree in advance on the reverse scenario too: what happens if an exposure is discovered, such as a leaked key. Who reports to whom, in which channel, and who replaces the secret and checks what was done with it. When this is defined after the incident, the first hours, the most important ones, are wasted arguing about who is responsible.
It is also worth documenting as the work goes: run instructions, the structure of the system and key decisions. Documentation like this reduces dependence on any one person, which is in your interest for both security and continuity.
A quick check before you start
If you haven't set these up yet, check that you have an answer to each of the following:
- The agreement states that the code and the intellectual property are yours.
- The repository is in your organization, and the team is invited into it.
- Every person has a personal account with two-factor authentication.
- Secrets are not in code, and environments are separated.
- Real data doesn't flow into development environments.
- There is a policy for using AI tools.
- There is an offboarding checklist and an owner for it.
The bottom line
Most of the risks in working with an external team come from missing definitions and not from bad intentions: who owns what, who sees what, and what happens on the last day. One hour of setup at the start saves the most unpleasant conversations later, when the code is already written and the team is already working. Go through the list once with whoever is responsible for infrastructure or security on your side, and document the answers in one place the whole team can find. The list above is no substitute for legal advice and for a security review suited to your project.
If you are evaluating a team that joins you and works inside your own infrastructure, this is what the Outstaffing model looks like.
