'Source files included' — what it actually means and why most agencies are mildly insulting about it

If you’ve read more than two web design proposals, you’ve seen the line. ‘Source files included.’ Or ‘all source files handed over on completion’. Or, when an agency really wants to flex, ‘full IP transfer’.

It’s almost never explained. It sounds reassuring. It rarely is.

Here’s what the phrase ought to mean, what it tends to mean in practice, and what specifically should be sitting in your Google Drive (or wherever) on the day a project ends. Names withheld throughout, but every pattern below is from a real project we’ve been called in to rescue.

What ‘source files’ should mean

A website is not a single file. It’s a small fleet of things, and ‘source files included’ should mean every one of them is yours, in a format you (or your next designer) can actually open and use.

At minimum, that’s:

• The code. Every line of HTML, CSS, JavaScript, configuration, content, deployment scripts. In a version-controlled repository — Git, almost always GitHub — that you own, on an account in your name.
• The design files. Figma, usually. Editable. With the libraries, components and the style system intact, not flattened to images.
• The brand assets. Logo in vector (SVG and either AI or PDF), colour palette with exact hex and Pantone values where they exist, typography licences, photography rights, and a brand book — even a short one — that explains how the bits fit together.
• The content. Copy in something that isn’t only inside the CMS — a doc, a sheet, somewhere you can grep. Images in original resolution, not the compressed web versions.
• The infrastructure. Domain registrar, DNS, hosting, email — all in accounts you own, with billing in your name. If the agency holds any of these ‘as a convenience’, they’re lock-in dressed up as a favour.
• The vendor contracts. Anything third-party — analytics, forms, comments, payments, search, fonts — should be billed to you, accessed by your team, and movable without the agency’s involvement.

That’s the floor, not the ceiling. If a proposal says ‘source files included’ and doesn’t list these things, ask what’s actually inside the box before you sign.

What it usually means in practice

A non-exhaustive tour of the patterns we’ve seen handed to clients on day-of-launch:

The ‘export to ZIP’ handoff. An agency hands over a folder of static HTML, CSS and images. No Git history, no build tooling, no readme. Everything renders but nothing is editable in any practical way. A new developer needs a week to work out how the agency did anything.

The ‘we host it for you’ tether. Code lives on the agency’s server. Domain is in the agency’s registrar account. Forms email the agency’s inbox and they forward them on. Everything ‘works’ until you want to change agency, at which point you discover you don’t own any of it.

The ‘editable Figma’ that isn’t. Design file is shared with view-only permission. Or shared as editable but with all the components detached and the style system stripped out. Technically a Figma file. Practically a screenshot.

The vendor-locked CMS. A bespoke CMS the agency built on top of a framework only they use. Yours, in theory. Unmaintainable, in practice, without paying them to extend it every time you want a new field.

The repo with a missing readme. Git, this time. But no instructions. No documentation of which environment variables are needed. No deploy script. A clone that builds for the original developer and no one else.

None of these are scams — most are just how agencies have always done it, and no client has pushed back hard enough to make them change. But the cumulative effect is the same as a soft lock-in: the cost of leaving is high enough that you usually don’t.

Why this happens

A short, honest answer: it’s good for the agency.

If the client owns nothing, the client renews. If renewing is hard, the client doesn’t shop around. If the agency holds the keys to hosting and email, every small change is billable. The economic incentive runs against full handover, and most agencies don’t even notice they’re doing it.

It’s not always malicious. Sometimes it’s just that no one in the studio has been on the other side — picking up someone else’s three-year-old build with no documentation, trying to ship a content change before lunch.

We’ve been on that side. It informs how we hand things over.

What we hand over

At the end of a Nerdster Design project, before final invoicing, you get:

• A GitHub repository in your organisation’s name. Full commit history. Branch protection rules. A readme that explains how to run the site locally, deploy it, and where every external dependency lives.
• Deployment access. Whether the site is on Cloudflare Pages, a Digital Ocean droplet, Netlify or Vercel — the account is yours, billed to your card, with us as a collaborator that you can remove at any time.
• An editable Figma file. All components, libraries and styles intact. Shared with your team as owner, not viewer.
• A short brand book PDF. Logo usage, colour values, typography, voice notes. Twelve to twenty pages, no fluff. Enough that a freelance designer can pick up the work without asking.
• An asset library. Logos in vector and raster. Photography in original resolution. Icons in SVG. All in a shared Drive (or wherever you keep files) with sensible folder names.
• Vendor contracts in your name. Email, fonts, analytics, any SaaS we set up — all on your billing, your accounts.
• An engagement letter that says this in writing. The handover list is in the contract, not a verbal promise. If we change agency, the next person doesn’t have to wonder what we left out.

The honest caveats

A few things to be straight about.

If you use us for ongoing care — our monthly retainer — we’ll often keep deployment access during that period because we use it weekly. The day you cancel, that access goes; you don’t lose anything.

Some third-party services have account-binding rules we can’t override. Stripe, for instance, has ‘one merchant of record’ logic that means we can’t transfer a Stripe account from us to you — you set it up in your name from day one. We make a list of these at kickoff so nothing surprises you at handover.

And no, we don’t transfer ‘IP’ of anything we built before your project — the studio’s component library, our internal tooling, the open-source libraries everyone uses. What you get is full rights to the site we built for you, including any custom components made specifically for it. That’s the practical definition of ‘yours’.

What to ask before you sign

Three questions, in any proposal:

1. Will the GitHub repository be in our organisation, not yours? A ‘yes’ tells you they’ve thought about handover. A pause tells you they haven’t.
2. Will hosting, domain and email billing be in our name from day one? Not ‘transferred at the end’ — from day one. Anything else is a future battle.
3. Can we have a sample handover doc from a previous project? Redacted is fine. The point is whether the doc exists at all.

If those three answers are crisp, the rest tends to be in order. If they aren’t, no amount of ‘source files included’ in the proposal is going to mean much.

We’re happy to send the engagement letter template we use, including the handover schedule. Email mail@nerdster.design and we’ll forward it over, no obligation to engage further.