Skip to content

Freelance Developer Contract Checklist: 14 Must-Have Clauses

A freelance developer contract checklist with 14 must-have clauses: scope, payment, IP assignment, access, GDPR, liability and exit. Not legal advice.

By

Freelance full-stack developer

Published
Reading time
8 min
In this post8

This freelance developer contract checklist covers the 14 clauses every agreement with a freelancer should include, from scope and payment to intellectual property (IP), GDPR and termination. When a project goes sideways, the dispute usually starts in one of them, most often scope or acceptance.

I'm a developer, not a lawyer, and contract law varies across Europe, so treat this as a practical checklist rather than legal advice.

The short answer: the 14 clauses

14 clauses your contract should cover

  • Parties and contacts: the legal entities, and who approves work.
  • Scope and deliverables: what's in, and what's out.
  • Change requests: how new ideas are estimated, approved and billed.
  • Timeline and milestones: dates, and what you need to deliver when.
  • Price and pricing model: fixed, hourly or capped, plus currency and VAT.
  • Payment terms: installments, due dates and late payment.
  • Acceptance and warranty: when work is accepted, and who fixes bugs afterwards.
  • IP assignment: that the rights to the code transfer to you, and when.
  • Open source and third-party code: which components and licenses are used.
  • Access and hosting: repo, domain and servers in your name.
  • Confidentiality: what's confidential, and for how long.
  • Data protection: a DPA if the developer handles personal data.
  • Liability: caps, indirect losses and insurance.
  • Termination and handover: notice, handover and governing law.

Most freelancers have standard terms. Ask for them early and use this list to spot the gaps. If you haven't picked anyone yet, start with my complete guide to hiring a developer.

The project: who, what and when

1. Parties and decision-makers

Name the legal entities with their registration and VAT numbers, and the person on your side who can approve deliverables and changes. Without a named decision-maker, the developer either waits or builds whatever the last email asked for.

2. Scope and deliverables

Describe the deliverable in concrete terms: features, integrations, and which devices and browsers it must support. Be just as clear about what's out: design, copywriting, hosting or post-launch support. Attach the project brief as an appendix so the contract itself stays readable.

3. Change requests

New ideas mid-project are normal. The contract just needs a process: you describe the change, the developer sends a written estimate of cost and time, and work starts only once you've approved it.

4. Timeline and milestones

Agree on milestones, not just a deadline, and tie them to payments. List what you have to provide too: content, access and feedback within a set number of days. If your inputs arrive late, the timeline should move by the same amount.

The money: price, payment and acceptance

5. Price and pricing model

Spell out the model: a fixed price for a defined scope, an hourly or day rate with a monthly cap, or a mix. Say what's included and how licenses and hosting are billed. If you and the developer use different currencies, agree which one you're invoiced in and who carries the exchange-rate risk. On hourly work, ask for a time report with every invoice.

6. Payment terms

Tie installments to milestones: part upfront, part midway, the rest on acceptance. Write down the payment term (net 14 or net 30 is typical) and what happens when payment is late. For cross-border B2B work inside the EU, invoices are usually issued without VAT under the reverse charge rules (check with your accountant). Holding back a small share until acceptance is fair, and so is a freelancer pausing work over unpaid invoices.

7. Acceptance testing and warranty

Define when a deliverable counts as accepted: who tests it, how long you have (say, 10 business days) and what counts as a bug rather than a new request. Agree on a warranty period after acceptance in which bugs are fixed at no extra cost. Updates and hosting after that belong in a software maintenance agreement, not the project contract.

The rights: code, open source and access

8. IP assignment

Under the EU Software Directive, employers automatically get the economic rights to code their employees write. There's no matching rule for contractors, so in most European countries the freelancer keeps the copyright unless the contract assigns it to you. Make the assignment broad and say when it happens, typically on payment. In some countries, Germany among them, copyright itself can't be transferred, so the contract grants exclusive, unlimited usage rights instead.

Freelancers often reuse generic building blocks across clients. That's fair, as long as you get a perpetual, royalty-free license to those parts. More on that in who owns the code when a freelancer writes it.

9. Open source and third-party components

Your developer can't assign rights to open-source packages or paid services they don't own, so the contract should state that those stay under their own licenses. Ask for a list of the significant ones and any paid licenses, and agree that licenses which could require you to publish your own code (such as GPL or AGPL) are only used with your approval.

10. Access, repository and hosting

The code should live in a repository under your own GitHub or GitLab account. Domain, hosting and third-party accounts belong in your company's name too. Then you can grant and revoke access without asking anyone. The contract should say that all credentials and keys are handed over at the end and never held back as a bargaining chip.

The risks: confidentiality, data and liability

11. Confidentiality

A confidentiality clause in the main contract is usually enough: what's confidential, what isn't, and that the duty continues after the project ends. Agree on whether the developer can show the work in a portfolio. For a standalone agreement before the first call, see when an NDA with a developer makes sense.

12. Personal data and the DPA

If the developer can access customer or employee data, they're typically acting as your data processor. Article 28 of the GDPR then requires a contract covering the subject, duration and purpose of the processing, and it must be in writing (electronic form counts). As the controller, getting it signed is your job. Better still, let the developer work with test data instead of real personal data. If your developer is outside the EU or EEA, their access can count as an international data transfer, which adds paperwork.

13. Liability and insurance

It's common for a freelance contract to cap the developer's liability, often at the fees paid, and to exclude indirect losses such as lost profit or business interruption. That's reasonable: no solo developer can carry the risk of your entire revenue. Check that the cap doesn't apply to gross negligence or willful misconduct, and ask whether the developer has professional liability (professional indemnity) insurance.

When it ends: termination and handover

14. Termination, handover and governing law

Agree how either side can end the contract, with what notice, and what you pay for: usually the work done up to that point. The handover matters most: code, documentation, credentials and a short walkthrough for the next developer. With cross-border work, also pick which country's law applies and where disputes are settled. If you're already stuck mid-project, here's how to switch developers without losing everything.

Next steps

Run every quote through this checklist and ask about the gaps before you sign. They make good material for the questions to ask a developer before hiring. If the budget is large, or personal data and business-critical systems are involved, have a lawyer in your jurisdiction review the contract.

I start larger builds with a paid fixed-price discovery phase, and the code is yours from day one. See my services and how a project with me runs.

Frequently asked questions

Can I use a freelance developer contract template?

Yes, as a starting point, but adapt it. Generic freelance templates often miss what's specific to software: IP assignment, open-source licenses, access to accounts and data processing. Compare any template against this checklist and cut what doesn't fit. A template written for hourly consulting rarely suits a fixed-price build.

Is an accepted quote or email enough?

For small jobs of 10-20 hours, often yes. In many European countries, Denmark included, a contract needs no particular form to be binding, so a quote accepted by email is an agreement. The problem is proof: what isn't written down is hard to enforce. A DPA, however, must always be in writing.

Should the contract mention AI coding tools?

Yes, since many developers now write code with help from AI assistants. Agree on whether that's allowed, and that your code, data and confidential information won't be shared with services that may train on them. The developer should stand behind all delivered code, regardless of how it was written.

I'm in the UK or US. Can I hire an EU freelancer on my own contract?

Yes, you can use your own template. Check three things first: which country's law governs it, whether the IP clause works under the freelancer's local law (some countries don't allow an outright copyright transfer), and how VAT should appear on the invoice. A lawyer who knows cross-border contracts can confirm all three in one review.