A product manager at a Hyderabad software company brings in a freelance mobile developer for six weeks. On day one the developer is added to the team chat, the code repository and the shared drive that holds customer test data. Nobody writes down what was shared. In week five the developer finishes early. Two months later someone notices their account is still active.
Bringing in a specialist is quick. Taking them out cleanly is harder. This post gives a first-week routine that treats access, data and confidentiality as part of onboarding, not as an afterthought.
Why the first week matters
Outside specialists arrive with skills and little context. They do not know your habits, your clients or your sensitive material. In the first week you set the tone for how they handle all three. A calm, organised start makes people more careful. A casual start leaves them guessing.
Before day one
- 1
Confirm the written terms
Check that the signed engagement agreement is in place and covers scope, payment, ownership and confidentiality. Our guide on what a freelancer agreement should cover lists the topics.
- 2
Name one contact
Pick one person who answers questions, approves work and owns the access list. Tell the freelancer who it is.
- 3
Decide the minimum access
List each system the person truly needs and the lowest permission level that works. Leave out anything nice to have.
- 4
Create separate accounts
Use named accounts for the freelancer, not shared logins, so actions can be traced and access can be removed cleanly.
- 5
Prepare the brief
Write the scope, deliverables, deadlines, review dates and communication channels on one page.
- 6
Schedule the welcome call
Book a short call for the first morning with the contact and, if useful, the team lead.
Access: grant little, log everything
Do not copy the access of an employee in a similar role. Start from nothing and add what the task needs. For a developer, that might be one repository, a test environment and one chat channel. For a designer, it might be a shared folder and a design file. Avoid giving access to production systems, customer lists or billing tools unless the work demands it, and review that decision with your technical lead.
Keep an access register. It can be a simple sheet with the freelancer's name, the system, the permission level, the date granted and the date removed. This is the single most useful tool for a clean exit.
Freelancer name and contact.
Engagement start date and planned end date.
System or account name.
Permission level granted.
Who approved it, and on what date.
Data sensitivity of this system: low, medium or high.
Review date for this access.
Date removed, and by whom.Data and confidentiality
Decide what the freelancer will see before sharing anything. Real customer data should usually stay out of test work. If a task needs realistic data, ask your technical lead whether masked or sample data will do. Make clear that work files belong in company-owned storage, not in personal email or a phone gallery.
Confidentiality should be signed before the first file moves. Use a reviewed document, such as the structure described in our confidentiality and NDA guidance, and explain it in the welcome call in plain words. Cover what counts as confidential, where it can be stored, who it can be shared with and what to do if something goes wrong.
The first week, day by day
- Day one: welcome call, brief, access granted from the register and a reminder of the confidentiality terms.
- Day two: the freelancer repeats the task back in their own words, and you correct any gaps.
- Day three: a short check-in on blockers, access problems and early drafts.
- Day four: first review of work against the brief.
- Day five: a feedback call, and a decision on whether the plan or the scope needs a change.
Employees follow a similar path in their first week, and the steps in our employee onboarding process can be adapted. For a freelancer the plan is shorter, but the access and data steps matter just as much.
Tools, devices and working habits
Say early which tools the freelancer should use for chat, files and tasks, and which they should not. If they bring their own laptop, agree where work files may live and what is deleted at the end. Ask them to keep client work in company folders, and to tell you at once if a device is lost. Short, specific rules are easier to follow than a long policy that nobody remembers.
Treat the freelancer as part of the team, within limits
Introduce them to the people they will work with. Invite them to the calls that affect their work. Do not add them to wider chats about salaries, appraisals or internal issues. Explain the escalation route for problems with a client or a deadline. This helps them work well without drawing them into matters that are not theirs.
Planning the exit on day one
Write the exit steps into the plan from the start. When the work ends, remove every account on the register, collect company files and devices, receive the final deliverables and confirm in writing that confidential material has been returned or deleted. Ask for a short handover note covering what was done, what is open and where files sit. Thank the person. A good ending makes a second engagement easy.
For software teams in particular, the page on software development companies describes other people processes worth setting up. If a freelancer is becoming a regular fixture, see when to move a freelancer onto your payroll.



