Freelance Developer Contract Guide

80% of freelance project disputes stem from scope disagreements. "Build me a website" means something different to you and the developer. A detailed scope eliminates ambiguity.

What to include in the scope:

• Deliverables list: Every feature, page, integration, and component explicitly listed. Not "a website with user accounts" but "a Django web application with email-based registration, login, password reset, profile page with editable fields (name, email, phone, company), and admin panel for user management."
• Out-of-scope statement: Equally important as the scope. "This project does not include: mobile app development, SEO optimization, content writing, ongoing maintenance, or third-party API integrations beyond Stripe payment processing." Prevents assumptions.
• Acceptance criteria: How do you determine if a deliverable is complete? Define specific, testable criteria. "User registration is complete when: a new user can register with email and password, receives a confirmation email within 60 seconds, can log in after confirming, and sees their profile page with all fields populated."
• Technical specifications: Technology stack (Python/Django, PostgreSQL, hosted on Hetzner VPS), browser support (Chrome, Firefox, Safari, Edge — latest 2 versions), mobile support (responsive design for screens 375px and above), performance target (page load under 3 seconds on 4G connection).
• Design specifications: If the developer is not handling design, specify who provides designs and in what format (Figma files, wireframes, or written descriptions). If the developer handles design, define the number of revision rounds (typically 2-3).

Change request process:

Scope will change — that is normal. The contract must define how changes are handled:

1. Client submits a change request in writing (email is fine)
2. Developer assesses impact on timeline and budget within 2 business days
3. Client approves the revised timeline and cost in writing
4. Work proceeds on the change only after written approval

Without this process, scope creep is inevitable. "Can you also add..." becomes a pattern that delays delivery and inflates costs — with both sides frustrated.

Template clause: "The Developer shall deliver the work as described in Appendix A (Scope of Work). Any work not explicitly listed in Appendix A is out of scope. Changes to the scope require a written Change Request approved by both parties, including adjusted timeline and fees."

IP ownership is the second most common source of freelance disputes. Without a clear IP clause, the default legal position varies by country — and it often favours the developer, not the client.

Three IP models:

• Full assignment (recommended for most projects): All intellectual property created during the project transfers to the client upon final payment. The developer retains no rights to use, license, or resell the code. This is what most clients expect and should insist on.
• License model: The developer retains ownership but grants the client an exclusive, perpetual, irrevocable license to use the code. Used when the developer builds on their existing framework or libraries. Less common but appropriate in some cases.
• Shared IP: Both parties retain rights. The developer can reuse code components (not your specific business logic) in future projects. The client owns the complete application. This is fair when the developer creates reusable tools during the project.

Critical IP considerations:

• Pre-existing IP: The developer likely uses their own code libraries, frameworks, and tools that existed before your project. These should be explicitly excluded from the IP transfer. The developer grants you a license to use their pre-existing code as part of the delivered project, but they retain ownership of the underlying library.
• Open-source components: Most projects use open-source libraries (Django, React, etc.). These remain under their original licenses. The contract should acknowledge this and list major open-source dependencies.
• Timing of transfer: IP transfers upon final payment. If you stop paying mid-project, the developer retains IP for the unpaid portion. This protects the developer from non-payment.
• Portfolio rights: Many developers want to showcase the project in their portfolio. Agree on this upfront. A common compromise: the developer can mention the project type and technology but not share confidential business data or code.

Template clause: "Upon receipt of final payment, the Developer assigns to the Client all intellectual property rights in the Deliverables, including copyright, source code, and documentation. The Developer retains ownership of Pre-existing IP (listed in Appendix B), for which the Client receives a perpetual, non-exclusive license. Open-source components remain under their respective licenses."

Legal review cost: EUR 150-300 for an IP clause review by a technology lawyer in the EU. Worth every cent — IP disputes cost EUR 10,000-50,000+ to resolve.

Payment structure protects both parties. The developer needs assurance of payment; you need assurance of delivery. Milestone-based payments achieve both.

Recommended payment structures by project size:

• Small projects (under EUR 2,000): 50% upfront, 50% on delivery and acceptance. Simple and fair.
• Medium projects (EUR 2,000-5,000): 30% upfront (project start), 30% at mid-project milestone, 40% on final delivery and acceptance.
• Large projects (EUR 5,000-15,000): 20% upfront, then 4-5 milestone payments tied to specific deliverables, with 20% held until final acceptance.
• Enterprise projects (EUR 15,000+): Monthly invoicing based on completed work, with a retainer or deposit of 10-15%.

Payment terms details:

• Invoice payment deadline: 14 days from invoice date is standard in the EU. Some developers accept 30 days for larger companies. Specify in the contract.
• Late payment penalty: EU Late Payment Directive allows interest at ECB reference rate + 8% on late B2B payments. Include a clause: "Late payments incur interest at 8% per annum above the ECB reference rate, calculated daily."
• Currency: Specify EUR and include a clause for exchange rate fluctuations if applicable.
• Accepted payment methods: Bank transfer (SEPA), Wise, PayPal — specify which. Credit card payments via Stripe may incur a 2-3% processing fee passed to the client.
• What counts as "acceptance": Define explicitly. "Acceptance occurs when the Client confirms in writing (email sufficient) that the deliverable meets the acceptance criteria defined in the Scope of Work, or when 10 business days pass after delivery without the Client raising specific objections."

Never agree to:

• 100% upfront payment — no leverage if the developer disappears
• 100% on completion — unfair to the developer who invests weeks of work
• Vague milestones — "Phase 1 complete" means nothing without defined deliverables
• Payment tied to subjective criteria — "when the client is satisfied" is legally unenforceable

Template clause: "The Client shall pay the Developer according to the Milestone Payment Schedule in Appendix C. Each milestone payment is due within 14 days of the Developer delivering the associated milestone deliverables and the Client accepting them per the acceptance criteria. Late payments are subject to interest at 8% per annum above the ECB reference rate."

If the developer will access, process, or store personal data (user emails, customer records, analytics data), GDPR requires a Data Processing Agreement (DPA) as part of your contract. This is not optional — GDPR Article 28 mandates it.

When a DPA is required:

• Developer has access to your production database containing user data
• Developer sets up analytics that track user behaviour
• Developer builds features that process personal data (user registration, contact forms, CRM integrations)
• Developer accesses your email inbox, CRM, or helpdesk for integration work

When a DPA is NOT required:

• Developer works only with test data (synthetic, no real personal data)
• Developer builds frontend-only features with no data access
• Developer works on infrastructure without accessing application data

Essential DPA clauses:

1. Purpose limitation: The developer processes personal data only for the purpose of delivering the project. No other use is permitted.
2. Data minimisation: The developer accesses only the minimum data necessary. If they need to test with user data, provide anonymised or pseudonymised datasets instead of production data.
3. Security measures: Specify minimum security requirements: encrypted connections (SSH, VPN), no personal data on personal devices, secure development environment, two-factor authentication on all accounts with data access.
4. Sub-processors: List any third-party services the developer uses that may process data (cloud hosting, error tracking, analytics). Each sub-processor needs its own DPA (most SaaS providers offer standard DPAs).
5. Data breach notification: The developer must notify you within 24 hours of discovering a data breach. GDPR requires you to notify your supervisory authority within 72 hours — you need time to assess and respond.
6. Data return and deletion: Upon project completion, the developer returns all personal data and deletes copies from their systems within 14 days. Provide written confirmation of deletion.
7. Audit rights: You have the right to audit the developer's data processing activities. In practice, this is rarely exercised but its presence ensures accountability.

Confidentiality clause (NDA):

Separate from GDPR but equally important. The developer must not disclose your business information, trade secrets, customer data, or proprietary processes. Standard NDA duration: 2-5 years after project completion. Exceptions: information that becomes public, information the developer already knew, or information required by law.

Legal review cost: DPA review by a GDPR-specialist lawyer: EUR 200-500. Standard DPA templates are available from EU data protection authorities — these can be adapted to your situation at lower cost.

Every contract needs clear rules for when things go wrong. Hope for the best, plan for the worst.

Warranty period:

• Standard warranty: 30-90 days after final delivery. During this period, the developer fixes bugs in the delivered code at no additional cost. A "bug" is defined as behaviour that deviates from the agreed scope and acceptance criteria.
• What the warranty covers: Defects in code written by the developer, broken functionality that was working at acceptance, security vulnerabilities introduced by the developer's code.
• What the warranty does NOT cover: New feature requests, changes caused by the client modifying the code, issues caused by third-party service changes (API updates, hosting problems), or problems arising from the client not following deployment instructions.
• Warranty response time: Critical bugs (site down, data loss): 24-hour response. Non-critical bugs: 5 business day response. Define severity levels in the contract.

Termination clauses:

• Client termination for convenience: The client can terminate at any time with 14 days written notice. The developer is paid for all completed work plus work-in-progress. Common kill fee: 15-25% of the remaining contract value to compensate the developer for opportunity cost.
• Developer termination for convenience: The developer can terminate with 30 days written notice. They must deliver all completed work, source code, and documentation. No kill fee — the developer forfeits the remaining contract value.
• Termination for cause: Either party can terminate immediately if the other party materially breaches the contract and does not remedy the breach within 14 days of written notice. Material breach includes: non-payment (client), failure to deliver (developer), breach of confidentiality (either party).

Dispute resolution:

1. Step 1 — Direct negotiation: Both parties attempt to resolve the dispute through direct discussion within 14 days.
2. Step 2 — Mediation: If negotiation fails, submit the dispute to a professional mediator. Cost is shared equally. Mediation is faster and cheaper than arbitration — typical cost: EUR 500-2,000 total.
3. Step 3 — Arbitration or court: If mediation fails, the dispute is resolved by arbitration (binding, faster, private) or by the courts of the agreed jurisdiction. For EU contracts, specify the applicable law (e.g., Dutch law, German law) and jurisdiction (e.g., courts of Amsterdam).

Limitation of liability:

Standard clause: the developer's total liability is limited to the total fees paid under the contract. This protects the developer from disproportionate claims. The developer is not liable for indirect, consequential, or incidental damages (lost revenue, lost data beyond what the developer caused, reputational damage). This is standard in the software industry.

Legal review cost for full contract: EUR 300-800 for a technology-focused lawyer in the EU. Many offer fixed-price contract review packages. For projects over EUR 5,000, this investment is non-negotiable.