What a freelancer engagement agreement should cover, and what to leave to your legal adviser

Arjun heads delivery at a software company in Pune. A freelance tester delivers a report late, then says the extra round of fixes was never part of the job. Arjun searches his email and finds a chat message with a rough budget and a start date. There is no agreement. Both sides are polite, and both are irritated.

Most freelancer disputes begin with a missing answer, not with bad faith. This post lists what the agreement should answer and how to produce one without a long legal project. It also marks the points that belong with your legal adviser.

The agreement is a shared memory. It records what both sides understood on the first day, so you do not rely on recollection later. It also protects the freelancer, who gets a clear scope and a payment trigger. A good document is short, readable and specific to the engagement.

Group the content under a handful of headings. This keeps the document short and makes it easy to review with the freelancer before signing.

• The parties, with the correct business or personal names and contact details.
• The scope of work, described by deliverables and not by hours alone.
• The timeline, including the start date, milestones and how delays are handled.
• The fee, the way it is invoiced and the event that triggers payment.
• Review rounds, acceptance and what counts as a change request.
• Ownership of the finished work and of any materials the freelancer brings.
• Confidentiality of your information and your clients' information.
• Use of your tools, accounts and data, and the return of them at the end.
• How either side can end the engagement and what happens to work in progress.
• Who may sub-contract, and whether your client names can be shared.

Vague scope is the main source of friction. Instead of saying a freelancer will test the app, say which builds, which devices, what form the report takes and how many rounds of retesting are included. State what is not included. If a designer is delivering a campaign set, list the formats and the number of revisions. A new project manager should be able to read the page and know whether a request is inside or outside the agreement.

1. 1

   List the real questions

   Ask the project manager what went wrong with the last freelancer. Each problem becomes a line the agreement must answer.

2. 2

   Start from a reviewed template

   Use a standard document your adviser has approved, then adapt the scope and payment pages for each job. Our confidentiality and NDA guidance shows how the confidentiality part is structured.

3. 3

   Fill in the commercial terms

   Complete deliverables, dates, fee and payment trigger in plain language. Keep the company's decisions on limits and timelines with the person who owns the budget.

4. 4

   Send it to the freelancer early

   Share the draft before the first day so questions come up while there is still time to answer them.

5. 5

   Take legal review where needed

   Send anything unusual, such as exclusivity, shared ownership or work for a client with special terms, to your adviser.

6. 6

   Sign, file and brief the team

   Store the signed copy in one shared folder. Tell the project manager where it is and what it says.

1. Parties and date
2. Purpose and a short description of the project
3. Deliverables and acceptance method
4. Timeline and milestones
5. Fee, invoice details and the event that triggers payment
6. Review rounds and change requests
7. Confidentiality and handling of data
8. Ownership of work and use of third-party material
9. Tools, accounts and return of materials
10. Ending the engagement and handover
11. Who to contact on each side, and how disputes are first raised
12. Signatures

Before you send the draft, ask the project manager to read it as if starting the job tomorrow. Can they tell what to ask for, when to expect it and what to do if it is wrong? Can they find the payment trigger without help? Fix every place where they hesitate. A clear agreement is read and used. A dense one is filed and forgotten, and the chat thread takes over again.

Do not copy employment terms into a freelance document. Fixed hours, leave entitlements, appraisal cycles and a probation clause belong to a different relationship and can blur it. Equally, avoid long clauses you cannot explain. If the project manager cannot say in one sentence what a clause does, ask your adviser to simplify it.

Projects rarely go exactly to plan. A client changes direction, a platform releases an update or the freelancer falls ill. Agree early how changes are raised, who approves them and how the fee and dates move. A single change request form, with a line for effect on fee and timeline, is enough. It turns an argument into a routine step.

The agreement only helps if people use it. Put the key points in a one-page project brief that the project manager and freelancer both see. Keep a short change log with dates when scope shifts. When a request arrives outside scope, answer with the change request step from the document, not with an argument.

For software teams, where freelancers often touch code repositories and test data, the people processes are further described on the page for software development companies. If your freelancer is becoming a regular, read about when to move a freelancer onto your payroll.