Here’s something most beginner web developers don’t find out until it’s too late: ownership of code isn’t automatic. It depends almost entirely on what your contract says — and if you don’t have a contract, things get messy fast.
Note: The following applies to U.S. copyright law. Rules vary in other countries.
The legal term to know is “work-made-for-hire.” According to ASP’s breakdown on code ownership, if your work qualifies as a work-made-for-hire, the client who commissioned it owns the copyright — not you. That means if you want to use that same code again on a future project, you’d technically need to negotiate a license from your own client, just like any stranger would. Yeah. That can happen.
Important nuance: if you’re a freelancer or independent contractor (not a regular employee), a work-made-for-hire situation generally requires two things — a written agreement that says so, AND the work has to fall into a specific list of categories defined by U.S. copyright law. Custom websites don’t always fit neatly into those categories, which means even a signed clause isn’t always the final word. This is exactly why getting a lawyer to review your contracts matters.
If you’re a regular employee (W-2, not 1099), the rules are different — work you create for your employer as part of your job is almost always owned by your employer, even without a written agreement saying so. Keep that in mind if you’re doing an internship or part-time job that involves coding.
But here’s the flip side — and this is the part that actually protects you as a freelance developer. If your contract doesn’t explicitly say it’s a work-made-for-hire, you likely still own the copyright. Your client gets a finished website. You keep the underlying code. That’s the default in most cases for independent contractors, and it means you can reuse your own templates, frameworks, and snippets on the next ten projects without asking anyone’s permission.
So what does your client actually own? Only what your contract spells out. If the contract says they own the custom homepage design you built from scratch for them, then yeah — that’s theirs. But your generic utility functions, your reusable CSS library, your plugin setup? Unless the contract specifically transfers those, they’re still yours.
This is why the contract matters so much. Before you start any paid project, you want it clearly written out: what the client is buying, what they’re licensing, and what stays yours. Vague language is how developers accidentally sign away work they’ve spent years building.
One more thing worth knowing: if you’re using someone else’s code — open-source plugins, Creative Commons assets, third-party templates — those come with their own rules. Creative Commons licenses, for example, can require attribution, restrict commercial use, or require that any adapted version carries the same license (depending on which specific CC license applies). So before you drop a plugin into a client’s site and promise them full ownership, make sure you actually understand what license that plugin is under. You can’t give your client something you don’t have the rights to transfer.