Web Development Contracts and IP Assignments, Signed Online
Software projects are famous for changing while they are being built. A web developer who starts without a written scope, milestones and an agreement about who owns the code is taking on risk that has nothing to do with programming. Codec Document helps developers and small studios send clear contracts and statements of work that clients sign online, before the first commit.
Who owns the code is not what most clients think
Many clients assume that paying for a website means owning the code. Many developers assume they can reuse their components on the next project. Both assumptions can be wrong, and the conflict usually appears at the worst time: when the client wants to move to another developer, or when the developer wants to publish a library. Add changing requirements and hosting responsibilities, and a web project without a contract is a set of misunderstandings waiting for a deadline.
How it helps web developers
Statements of work with milestones
Features, milestones, acceptance criteria and payment per milestone, so progress and payment move together.
Clear IP assignment on payment
Transfer ownership of the custom code on full payment while keeping your pre-existing libraries and tools licensed, not transferred.
Change requests that are priced
Every new feature request becomes a short change order with a cost and a date, signed before you build it.
Maintenance and hosting terms
Who pays for hosting, domains and third-party services, and what ongoing support costs, agreed in a separate signed plan.
Custom software is usually not a work made for hire
Under 17 U.S.C. § 101, work created by an independent contractor is a work made for hire only if it falls into a limited list of categories and the parties agree in a signed writing; custom software often does not fit those categories. That is why client contracts typically include an assignment, and 17 U.S.C. § 204(a) requires a transfer of copyright ownership to be in writing and signed. The ESIGN Act, 15 U.S.C. § 7001, allows that assignment to be signed electronically.
The client who wanted the repository
A freelance developer in Seattle built an e-commerce site and was paid three of four milestones. The client then asked for full access to the repository to hand it to another developer. The signed contract said ownership of the custom code transferred on final payment. The client paid the last milestone, received the repository and the assignment, and both sides moved on without lawyers. Without that clause, the conversation would have been very different.
What to put in writing before the first commit
- Features and pages included, and acceptance criteria for each milestone.
- The payment per milestone and what happens if the client does not approve a milestone.
- How change requests are estimated, approved and billed.
- Ownership of the custom code, and a license for your pre-existing libraries.
- Who owns hosting, domains and third-party accounts, and who pays for them.
- Support after launch: the warranty period for bugs and the rate for new work.
Questions people ask about this
Can I keep ownership of my reusable components?
Yes. Define pre-existing materials in the contract and grant the client a license to use them, rather than transferring them.
Can I send an NDA before seeing the client codebase?
Yes. Send a mutual NDA first, then the development agreement.
Is there an API to send contracts from my own tools?
Yes. A REST API and webhooks let developers send documents and receive signing events programmatically.
Do clients need an account?
No. Clients sign through a secure link in the browser.
What if the client never approves the final milestone?
Add a deemed acceptance clause: if the client does not report specific defects within a set number of days after delivery, the milestone is considered accepted and payable. Without it, a project can stay at ninety-five percent forever. Pair it with a short bug-fix warranty so the client still feels protected after acceptance.