Freelance dev contract essentials
I lost R$ 8,000 on a project because there was no written contract. Client disappeared, complained six months later, I denied the payment. Without a document, it was my word against his. Learned real quick that contracts aren’t just for big companies. They’re how freelancers protect themselves.
I’m not going to lecture you on law stuff, I’m not a lawyer. But I’ll tell you what every solo dev needs documented before sitting down to code.
Contracts saved my business. After structuring terms properly, my conflict resolution time dropped 80%. Clients know exactly what to expect. I know exactly what I’m committed to. That’s it.
Scope is everything
Define exactly what you’re building. Not “pretty website” or “working system”. Type it out: “Develop appointment booking screen with Astro, integrate with Supabase, validate forms with Zod, deploy to Vercel.”
This kills 90% of disagreements. No more “you didn’t mention it should be responsive” or “I also wanted an API.”
Include what’s NOT in scope. “Excludes: layout changes after development, hosting, post-delivery support, legacy system integration.” Seems obvious until the client asks for it.
Timeline matters
Write the delivery date. For bigger projects, break it into milestones. Example: “May 4th first version, May 11th second version with feedback, May 18th final deploy.”
Make clear that delays on their end (providing content, approvals, access) don’t affect your timeline. Clients love disappearing for two weeks then acting like you’re the slow one.
Specify your working hours. “Support available Tuesdays and Thursdays, 10am-2pm.” Otherwise they think you’ll answer on Sunday.
Payment is non-negotiable
Total amount, first payment, second payment. For projects up to R$ 10k I do 50/50 split.
Above that, three installments: 30% upfront, 35% halfway, 35% delivery.
Include late payment fees. 3% monthly interest. Not because you’re greedy, but because it signals the money matters.
If they cancel mid-project, they pay for what’s done. “If cancelled halfway through, client pays first installment plus 50% of second.”
Intellectual property
Your client owns the code after paying. That’s normal. But be explicit: you can reuse techniques and components in future projects.
Something like: “Client acquires license to the code. Developer retains rights to architecture, base components, and custom libraries created.”
So that masked input you coded beautifully? You can use it again. You’re not copying their entire site, you’re applying what you learned.
Termination and cancellation
How does this end if it goes south? “Either party may cancel with 5 days notice, paying only for completed work through that date.”
Make clear that undelivered code isn’t their property. If they bail early, you keep your work-in-progress.
Presenting it without seeming bureaucratic
Don’t send a 10-page contract to a small client. Looks like you’re about to sue them.
Format: send it by email, casual tone. “Hey, before we kick off I need to document the project details. Sending a simple contract here.” Print it, they sign both copies, you each keep one.
If a client complains about contracts, they’re already looking for wiggle room later. Push back.
Lessons from projects that went wrong
One client asked for “small tweaks” on a delivered site. Six months of free adjustments later I found he was selling services using my code without credit.
Another tried to sue me because his site went down twice in a year. Infrastructure problem, not my code.
A third disappeared for a year, reappeared wanting changes, thought he still had rights.
Contract would’ve prevented all of it.
These stories are common in the dev community. I talked to 15 freelance devs in 2025, and 12 had experienced clients trying to renegotiate or demand extra work. Contracts protect both sides.
When a client refuses to sign
Some clients resist contracts. “Nah, let’s keep it informal, I trust you.” That’s a red flag. Someone who won’t document an agreement wants to leave room to complain later.
Respond like this: “The contract protects us both. If something goes wrong, we have something to reference. If everything goes well, we won’t need it. But it’s necessary so I can work comfortably.”
If they still refuse, decide: do you want to work with someone who doesn’t trust you enough to sign?
Amendments and scope changes
Project starts, client wants to add a feature. Then the discussion: “Was that supposed to be in the original scope?”
Contract solves this. You make an amendment. “Original: site with 5 pages and 3 forms. Amendment: add Dashboard with charts and Google Analytics integration. Extra cost: USD 600, timeline extended two weeks.”
Client signs the amendment. Done. No games later.
I’ve done this on eight projects. Only one client complained. The other seven? Signed happily. Because they saw clearly what was new work.
Ending the contract as a developer
Sometimes a client is so bad you want out. Your contract makes that clear too.
“If developer must end the contract for justified reason (client not paying, client violating terms, etc.), developer gives 10 days notice. Client pays for half the completed work. Code delivered to that date becomes client property.”
This protects you. You’re not stuck in an endless project with a client who won’t pay or is abusive.
Importance of keeping copies
Both people sign. Each keeps a copy. Don’t send digital copies that the client later claims they never got. Print it. Pen in hand, signature.
I keep my contracts in a physical folder for three years. If a client sues after that, the statute of limitations has expired. But while it hasn’t, I have documentation.
Digitally: save as PDF to Google Drive with automatic backup. Cloud is your friend.
Simple template
Don’t need to hire a lawyer. Use a basic template, customize it. Include:
- Contact info for both parties
- Project description and scope
- Timeline and milestones
- Amount and payment schedule
- Cancellation terms
- IP ownership
- Signatures and date
Keep it straightforward.
We work to get paid. Contracts are like backups, annoying until you need them. Then you’re grateful they exist.
Read also: Charging for those “quick fixes” | Scope is the skill that matters most | Client onboarding that works
- Write scope clearly, define what’s excluded
- Set delivery dates and milestones for larger projects
- Specify total amount and payment structure
- Protect IP and your right to reuse components
- Document cancellation terms clearly
- Keep the template simple and casual in how you present it
- Keep both signed copies for your records
Without a contract, you’re throwing your work to the wind.
A freelance dev contract isn’t intimidation. It’s professionalism. It’s you saying: “I take my work seriously and I need you to as well.”