A contract with a freelance developer needs written answers to nine questions: what is being built and what is not, how you accept each delivery, when, for how much and in what instalments, how changes are priced, who owns the code and the accounts, what stays confidential, what happens with bugs after launch, and how either side can end it early. It can be two pages of plain English. What matters is that none of the nine is left to memory.
Most disputes between clients and developers are not about bad faith. They are about two reasonable people remembering a conversation differently. A contract is mostly a shared memory.
The nine clauses at a glance
| Clause | The question it answers |
|---|---|
| Scope | What exactly is being built, and what is not |
| Deliverables and acceptance | What you receive, and how you sign it off |
| Timeline and communication | When, and how you stay in touch |
| Price and payment schedule | How much, and when each part is paid |
| Changes | What happens when you want something new |
| Ownership and accounts | Who owns the code, and whose accounts it lives in |
| Confidentiality | What must not be shared |
| After launch | Who fixes bugs, for how long, at what cost |
| Ending it | How either side can stop, and what happens then |
Scope, deliverables and acceptance
Scope is the part to spend the most time on. List the features in plain words, then add the line that prevents most arguments:
Includes: email sign-up and login, the booking calendar, card payments through Stripe, and the confirmation email. Does not include: the admin dashboard, App Store submission, or any content and copy.
If you already have a brief, attach it and refer to it. How to write a project brief produces exactly the document this clause needs.
Acceptance says how a delivery becomes "done". A simple version: you have a set number of working days to test each delivery and send one list of problems; the developer fixes anything that does not match the scope; if you send nothing in that window, the delivery counts as accepted. That last part is fair to the developer, who otherwise waits indefinitely to be paid.
Timeline and communication
Put dates on the milestones, not just on the end. Then add how you will work together: one channel for messages, a weekly update or demo, and the expected reply time on both sides.
Include one sentence about delays: if either side expects a date to move, they say so as soon as they know. Late software is normal. Late news about late software is what damages the relationship.
Price, payments and changes
State the total, the currency, and what each payment is tied to. A deposit to start and payments on accepted milestones is the usual shape for a first project. How to structure milestone payments goes through it, and fixed price or hourly covers which model fits your project.
Then the change clause. Anything outside the scope is quoted in writing, with its effect on the price and the dates, and starts only once you agree. Include the hourly or day rate for change work, so every change is a calculation rather than a negotiation.
Also decide who pays for outside costs: hosting, paid plugins, fonts, store fees. Usually you do, on your own accounts.
Ownership, accounts and confidentiality
This clause protects the thing you are paying for. Three parts:
- Ownership. Work created for the project is assigned to you once the related invoice is paid. The developer keeps their own pre-existing tools and code and gives you a permanent licence to use them in the project. Who owns the code explains why this has to be written down.
- Accounts. The domain, repository, hosting, database and store accounts are registered to you. The developer is invited in, and access is removed at the end.
- Confidentiality. Both sides keep the other's confidential information private, during the project and for a set time after. This replaces a separate NDA, as covered in do you need an NDA for your app idea.
After launch
Software has bugs after launch. Agree now what happens:
- A fix period. For example, the developer fixes defects in their own work free of charge for a set number of days after launch. A defect is something that does not match the agreed scope, not a new idea.
- Support after that. Billed at the agreed rate, or under a separate monthly arrangement.
- Handover. At the end you receive the code in your repository, the logins, and a short note on how to run and deploy it.
Ending it early
Projects stop for ordinary reasons: budgets change, priorities change, people get ill. Agree the exit while everyone is friendly:
- Either side can end the agreement with written notice.
- You pay for work done up to that point, at the agreed rate or milestone value.
- The developer hands over everything built so far, including code, designs and access.
- Ownership of the work you have paid for passes to you, as in the ownership clause.
A clean exit protects both of you. Without one, the end of a project turns into a standoff over half a feature.
What can stay out
A good freelance contract is short. You do not need:
- Pages of boilerplate copied from a large company's agreement, which neither of you will read.
- A non-compete that stops the developer working for anyone in your industry. For a freelancer it is a request to give up their living, and most good ones will refuse it.
- Clauses neither side would ever enforce. They add length and no protection.
Two plain pages that both of you have read beat twenty pages that neither of you has. The point is not to win a future argument. It is to make sure there is nothing to argue about.