How-to guide · Clients & workflow

Source files and working files: what the price buys

By the WorkKitly Team · Last updated: November 2026 · 7 min read

The argument about source files almost never starts as an argument about files. It starts at the end of a happy project, when the client asks for “everything” — and discovers the quote never said what everything meant. One side hears a reasonable request for work they paid for. The other hears a request for the tools, drafts and systems behind it, handed over free. Both are being honest; the document between them was not. The fix is boring and total: decide the file question in the proposal, price it deliberately, and deliver exactly what was agreed — no more reluctant, no less complete. What follows is general information about how freelancers make that decision, not legal advice: ownership defaults differ by country and by contract, and where real money or real rights are at stake, a lawyer in your jurisdiction outranks any guide.

1. What the client actually means

“Send me the source files” sounds like one request. It is three, wearing one phrase — and they carry different prices, different risks and different answers. Until you know which one is on the table, every reply you give answers the wrong question. Naming it, out loud and in the thread, is most of the resolution: freelancers who have this fight repeatedly are usually fighting all three asks at once, in a single tangled conversation that never separates them.

The deliverables, in editable form. The client wants to change a headline, swap a photograph, fix a typo — without booking you for it. This is often reasonable, often already implied by the shape of the engagement, and by far the cheapest of the three to grant. A large share of “everything” requests are only ever this.

The working files. Your process, made visible: the layered design file with its discarded directions, the writer’s drafts and research notes, the developer’s repository history, the photographer’s unedited RAWs. The kitchen, not the meal. This is the ask with real value inside it — your templates, your systems and your future editing work all live in these folders.

The rights. Permission to reuse the work, remake it, adapt it, or hand it to another freelancer to continue. A legal question wearing a file question. It is the ask that matters most — ownership and reuse are worth more than any folder — and the one discussed least, because both sides mistake it for a conversation about attachments.

The three also escalate in that order, which is how small requests become standoffs: the client asks for the first, the freelancer hears the third and refuses everything, and each side walks away convinced the other was unreasonable. Ask which one it is. The question is not defensive. It is how the conversation gets a shape, a price and an answer.

2. The default shapes, craft by craft

No universal rule settles any of this, and a guide that states one is inventing law. What exists is common practice, and it is consistent in shape even where the details differ. In many places the creator holds rights in the work until a contract assigns them — which is why the contract, not custom, always has the last word; and doctrines like work-for-hire, and the line between employee and contractor work, vary enough that you should check yours rather than assume. But quotes are written inside the customs, so know them.

Design. The finished exports are the product: the print-ready files, the web images, the logo in its agreed formats. The layered working file — named groups, discarded directions, type experiments — is commonly a separate line, priced or withheld, because it carries the apparatus: the grids and templates the next ten jobs will reuse.

Photography. The edited, delivered images are standard. The RAW files are commonly withheld or separately priced. Photographers call the RAW the negative, and the comparison is exact: it is the unfinished material from which finished work is made, not a finished thing in itself.

Writing. The final text is the product. Drafts, research notes, interview recordings and transcripts are working papers — the trail of how the text got good — and they are not normally part of the delivery unless the engagement says so.

Development. The exception that proves the shape: the delivered codebase usually is the product, handed over as the work itself. What stays yours is the scaffolding around it — the snippet libraries, build tooling and components you brought to the project rather than made inside it.

Video and audio. The finished edit or mix is standard. The project files — timelines, session files, raw footage — are commonly a separate conversation, for the same apparatus reason.

One line runs through all five: the finished thing is what the price bought. The apparatus that produced it — the process, the drafts, the systems — is yours unless it was priced in. That is not possessiveness; it is the distinction every trade makes. A restaurant sells the meal. It does not sell the kitchen’s knife roll.

3. Pricing the apparatus: three honest positions

Any of three positions is defensible. What is not defensible is having none — deciding under pressure, at delivery, with the client waiting on the thread. Choose yours while the quote is being written, when it is still a pricing decision instead of a negotiation.

Included. Price the files into the quote quietly and hand them over as part of delivery. This is right for repeat clients, for productised work where the package is the point — how to productize a freelance service builds offers exactly that way — and wherever the working files are genuinely worth little once the job is done. Generosity there costs almost nothing and buys real goodwill.

A release fee. Name a price for the working files as their own line, in the proposal or when the ask arrives. Frame it as what it is: the client is buying your future edits and your systems, not a folder — so the fee is real, not a ransom and not a penalty for asking. Set the figure by judgement: what the edits it replaces would have earned you, what the templates inside are worth in a stranger’s hands. There is no honest formula for it; anyone offering one is selling certainty they do not have.

Withheld. Some apparatus is not for sale at any price: the templates that are your trade’s machinery, and anything belonging to another client that happens to live in the same folder — that material must never travel, at any number. Licensed elements sit here too: check the licence before promising anything, because many font and stock licences do not transfer to a new owner, and a file you cannot legally hand over is not yours to sell.

Whichever position you take, it belongs in one sentence in the proposal: the file line. The freelance proposal template, section by section reserves the deliverables section for exactly this — “Delivery: final artwork as print-ready files and web exports; layered working files available as a separate release” is the whole clause. One sentence, written while everyone is friendly, prevents the entire genre of dispute this guide exists for.

4. When the ask arrives anyway

Sometimes it arrives mid-project, or at delivery, with no file line anywhere in the paperwork. Run the calm sequence. First, clarify: which of section 1’s three asks is this — editable deliverables, working files, or rights? Half the time it is the first, and the answer is a small yes you can give today. If it is the working files, quote the release as a normal line item, in the invoice’s language, without apology or ceremony:

The finished files named in your proposal — the print-ready artwork and the web exports — are already yours, and they’ll be in the delivery folder. The layered working files sit outside that quote. If you’d like them, I can release the full set for a one-off fee, invoiced like any other line. If you only need to update text later, the editable exports may well cover it.

The message runs to 68 words. Note what it does: it gives before it prices — the included part is named first and called theirs — and it opens the smaller door, the editable exports, before the bigger one. It does not explain, justify or mention your feelings, because a price needs no defence. It needs a number and a next step.

What never works is the pressured, resentful yes: the working files sent “as a favour”, while you seethe. An unpriced yes teaches the client the files were free all along, and teaches the next ask to arrive the same way. If you want to give them, give them deliberately, as a gift whose name is said out loud. Otherwise price them, kindly — and let kindly priced be the precedent.

If the real ask is the third one — rights — stop treating it as a file transfer. Reuse and remake rights are a licensing conversation, bigger than any folder: which uses, for how long, exclusively or not. That conversation belongs in the contract — freelance contract basics covers where terms like these sit — and where the work carries real continuing value, it belongs in front of a lawyer before it belongs in an email. Files can be re-sent. Rights, given loosely, cannot be un-given.

5. The handover line

At delivery, write the settlement down where the client will still find it in month three: the file inventory in the project handover document. It states exactly what was delivered — each file, its format, its location — and, just as plainly, what was not: the working files retained, the licences that remain in your name. A client reading that table has nothing left to argue with, including the version of you they invent at midnight.

Keep your own archive complete alongside it: the working files, and a frozen copy of exactly what was delivered. The delivered version is your evidence if a dispute ever does arrive, and your portfolio when it does not — the freelance case study you write next year is built from the archive you kept this year.

One tactic is out of bounds, and it is worth naming plainly: deleting your working files at delivery so the client is forced to come back to you. That is not a retention strategy; it is a hostage arrangement, and clients can tell the difference. Keeping your files, as your own archive, is normal, professional and expected. Destroying them to manufacture dependence is the opposite — and the freelancer known for it gets recommended accordingly.

To close where this guide opened: everything here is general information, not legal advice. Ownership, assignment and work-for-hire rules vary by country, by contract and by whether the work was made as an employee or as a contractor — check yours before you rely on any of it. The commercial habit, though, travels everywhere: name the files in the proposal, price the apparatus on purpose, and deliver exactly what was agreed. Do that, and “send me everything” becomes the easiest email of the project.

Questions

As general information only: it depends on the contract and on the jurisdiction, and without an agreement covering it, positions vary — which is precisely the argument for the proposal's file line. Where a contract does assign the files, they are owed like any other deliverable. Where the paperwork is silent or disputed and real value is at stake, that is a question for a lawyer in your jurisdiction, not for a guide — and not one to settle by whoever argues longest in an email thread.
If they were not in the quote, yes: the working files are a deliverable like any other, and the apparatus reasoning — they carry your systems and your future-edit revenue — is why they carry a price. If they were in the quote, they are already paid for, and charging again would be the dishonest move. So the first step is embarrassingly simple: check your own proposal before answering. The file line you wrote, or failed to write, is most of the answer.
Show them the proposal's file line — or, if there is none, its absence, owned plainly. Then run the calm sequence: clarify which ask it is, give what was agreed, and price the rest as a normal line. Where the wording is genuinely ambiguous, the professional settlement is often the generous reading this once — deliver, keep the goodwill — with the file line written into every proposal from that day forward, so the ambiguity can never be quoted back at you. That is a judgement call, stated as one; what never settles it is insisting, on principle, in a thread the client will forward.
The editable natives of the finished deliverables: the layered design file behind the artwork, the document behind the PDF, the project file behind the edit, the RAW behind the photograph, the codebase behind the site. What does not count — however the request is phrased — is your internal apparatus: the templates, snippet libraries, research trails and systems you brought to the work rather than made inside it. Most “everything” requests resolve the moment that distinction is on the table, because most clients were only ever asking for the first list.

Related: the paperwork around the files

The inventory that records the settlement lives in the project handover document; the sentence that prevents the argument lives in the proposal template. The terms underneath both are in freelance contract basics — and the archive you keep is the raw material of the freelance case study that wins the next client.