The source files clause every freelancer needs in their contract

A client takes delivery. Invoice is paid. Three months later, a new designer they’ve hired contacts you asking for the Figma file.

You never discussed source files. Now you’re negotiating after the fact, with no leverage and no clause to point to.

What “source files” means

The term covers different things depending on what you produce:

• Design: .fig, .ai, .psd, .sketch — the editable originals behind the exported PNG, PDF, or SVG
• Development: the repository, build configuration, environment templates, database scripts
• Video: project files, raw footage, timeline exports
• Writing: native .docx or editable versions, not the final published format

The finished deliverable and the working files that produced it are separate things. Most clients don’t know this until they want to change something.

Why they’re not included by default

You’re paid to produce a result. The source files are the scaffolding you used to get there.

Preparing files for handover is actual work. Organising layers, annotating a codebase for someone else’s maintenance, structuring a Figma file so another designer can navigate it — none of that is free. And unlike the final deliverable, which you hand over once, source files create an ongoing dependency. A client who has them can modify your work without you. That’s a legitimate commercial decision — but it should be priced as one.

Three ways to handle it

Include at a higher rate. Your standard pricing covers the final deliverable. Source files are included in a premium tier at +30–50%. You’re compensated for the handover work; the client knows what they’re buying.

Price it separately. Set a flat fee for source file delivery quoted upfront — alongside the project cost, not after. €300 for a logo package, €800 for a development handover. Once it’s on the brief, it’s rarely disputed at delivery.

License the output, keep the source. You retain the working files. The client gets usage rights over the deliverable. They can’t modify it without coming back to you — a natural retention mechanism for ongoing work.

None of these is wrong. What’s wrong is leaving it unresolved and discovering the client’s expectation six months later.

The clause

One sentence in your contract:

“Final deliverables are provided as [format]. Editable source files and working assets are not included unless listed separately below. Source file delivery may be purchased for [amount], payable prior to project completion.”

Adjust for your discipline. The essential parts: what format you’re delivering, that source files are separate unless stated, and the price. Add it to your standard contract — not as a client-by-client conversation.

This clause operates alongside the IP assignment clause, which governs ownership of the deliverable, and the scope of work, where you define what “deliverables” means in the first place.

When a client asks post-delivery

The easiest response: “Source files weren’t in scope for this project, but I can put together a handover package. Let me send you a quote.”

Most clients who genuinely need the files will pay. Those who were hoping for a freebie usually drop it. Either way, you’ve avoided delivering something with real value for nothing.

If your contract is silent on the matter, you’re in a grey zone — and grey zones favour whoever is more persistent.

The dispute pattern

It rarely surfaces on delivery day. It surfaces months later, when the client wants to make a change and realises they don’t have what they need to do it.

At that point, having a clear record of what was delivered — in what format, on what date — matters more than any verbal agreement. What every freelance contract should include covers the other clauses that tend to matter after the fact: payment terms, IP transfer, kill fees. Source files belong in the same document.

Timescanner reads your calendar to track hours by client and project — so if a dispute comes up over what was delivered, you have a timestamped record to refer to. Works with any iCal-compatible calendar.