Here is a confession from a developer who has signed more than one contract he did not fully read. The first time a client disputed an invoice with me, I opened my "contract" and found a two-line email thread and a Google Doc titled "Scope v3 FINAL". Neither said when I was supposed to be paid. Neither said who owned the code. I got paid eventually, but only because the client was decent, and that is not a contract, it is luck.
If you freelance in web development, you need a contract template you actually trust, and you need it before the first discovery call turns into a project. I'm not a lawyer, and nothing here is legal advice. What follows is the checklist I run through before I sign anything, with the clauses I've seen cause the most pain, and a few pointers to primary sources so you can check my claims instead of taking my word for them.
A freelance contract template does not need to be long. Mine is about two pages. It needs to answer six questions in plain English, and the rest of this post walks through them.
What a short contract has to settle
A good contract is a list of decisions you made while you were both still friendly. Every clause exists because, at some point, two reasonable people remembered a conversation differently.
The six questions I want answered in writing are these. What exactly am I building, and what happens when the request changes? When and how do I get paid? Who owns the result, and when does ownership transfer? What happens if either of us stops? Who is responsible if something breaks after launch? And, for work in some places, does the law already require something I forgot?
If you want a version of the first question that wins you the job rather than just protecting you, I wrote about the proposal side in my web development proposal template post. The contract is the quieter sibling: it only matters when something goes sideways.
Scope and the change clause
Scope descriptions fail when they describe features instead of outcomes and boundaries. "A contact form" is a feature. "A contact form that sends to one address, with a spam filter, no file uploads, no CRM integration" is a scope.
I list deliverables, then I list what is explicitly excluded, then I add a change clause. The change clause is short:
Work outside the deliverables listed in section 2 is a change request.
I will estimate it in writing. Work on a change request starts after
you approve the estimate by reply email. Approved changes are billed at
the rate in section 3 and may move the delivery date.
That paragraph does more for scope creep than any amount of firmness in a meeting. It turns "can you just also..." into a question with a price attached, and it makes me the person offering an estimate rather than the person saying no. I went through the human side of that problem in my scope creep post, and the short version is that a one-line email estimate beats a long conversation every time.
One more thing about scope: put the number of revision rounds in the contract. "Unlimited revisions" is a sentence that sounds friendly and ends careers.
Payment terms that survive a slow client
Payment clauses are where most freelancers are too polite. Mine has five parts, and I'd keep all five.
A deposit before work starts. I take a third on signing for projects under a few weeks, and I never begin without it. The deposit is not about money, it is a cheap test of whether the client can send a payment at all.
Milestone invoices tied to deliverables, not to calendar dates. If I invoice on "the 15th" and the client has not reviewed anything, I'm invoicing for a promise.
Net terms in days, stated as a number. "Payable within 14 days of invoice date" beats "promptly" because you can count to 14.
A late fee or a pause clause. I use a pause clause: if an invoice is more than seven days overdue, work pauses and the delivery dates move by the length of the pause. It's gentler than interest and more effective, since clients rarely care about a 1.5% fee but do care about their launch date.
Currency and fees. If you work across borders, say who pays the bank and platform charges. I've lost a surprising amount of an invoice to transfer fees nobody mentioned.
For how I decide the numbers that go into those clauses, see how I price freelance web development work.
Who owns the code
This is the clause people copy from the internet and get wrong, so I'll go slowly.
Many templates say the work is "work made for hire". That phrase has a specific meaning in US law. The statute's definition, in 17 U.S.C. section 101, covers works made by an employee within the scope of employment, and a short list of commissioned categories (a contribution to a collective work, a translation, a compilation, an instructional text and a few others) where the parties agreed in a signed writing. Custom website or application code does not obviously sit in that list. The US Copyright Office's Circular 30 on works made for hire is a readable explanation, and it is worth five minutes before you paste a boilerplate sentence into your agreement.
What I use instead is an assignment clause that transfers ownership on full payment, plus a licence for anything I bring with me:
On receipt of full payment, I assign to you the copyright in the
deliverables created specifically for this project. I keep ownership of
my pre-existing tools, libraries and templates, and grant you a
perpetual, non-exclusive licence to use them as part of the deliverables.
Two details matter. "On full payment" ties ownership to the thing you care about. And the carve-out for pre-existing tools means you can reuse your own deploy scripts and component library on the next job without being accused of selling something twice.
Other countries have different rules, and whether a clause like that holds up depends on where you and your client live. If the project is large, pay a lawyer for an hour to read your template once. That hour is cheap compared with one dispute.
Ending the project early
Every contract needs an exit. Mine allows either side to end the agreement with seven days written notice. On termination, the client pays for work completed to that point, plus a kill fee, which I set at a flat percentage of the unbilled remainder for fixed-price projects. The kill fee isn't a punishment. It reflects that I turned down other work to hold the slot.
I also add a line that deliverables, source code and credentials are handed over only after the final invoice is settled. Clients occasionally see that as aggressive, and I explain it as the same rule that governs ownership.
What the law may already require
Some places now require a written contract for freelance work. New York State is one example: its Department of Labor page on the Freelance Isn't Free Act says the act added Article 44-A to the General Business Law in August 2024, with contract requirements and a formal enforcement process, and that the department published a model contract. I haven't read the whole statute closely, and your own jurisdiction might have something similar or nothing at all. Searching your state or country plus "freelance written contract law" takes five minutes and might turn up a requirement you didn't know about.
Treat the model contract from a government site as a free checklist even if it doesn't apply to you. Compare it against yours and see what's missing.
Do this before your next call
Open your last signed agreement, or the email thread that passed for one. Hold it up against the six questions near the top of this post. Where you find a gap, write the missing clause in two sentences, and paste it into a template file you will actually reuse. Then send the next client that template before the kickoff call, not after. If you want to see how I structure the work that comes after the contract, the rest of my projects are on my portfolio.
Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.
Top comments (0)