Five clauses carry most of the risk: ownership, acceptance, exclusions, support, and what happens if either side walks away. What to put in front of your lawyer.
Key Takeaways
- Five clauses carry most of the risk: ownership, acceptance, exclusions, support, and what happens if either side walks away.
- What to put in front of your lawyer.
The short answer
Five clauses carry most of the risk: who owns the code, what "done" means, what is excluded, what support costs after launch, and what happens if either side walks away. If your contract is silent on any of them, that silence will be resolved later in whoever's favour has more leverage, and that is rarely you.
We are a software studio rather than a law firm, so treat this as the list of questions to put to your lawyer, not as legal advice.
Ownership
"You will own the software" is not a clause. The contract should say the copyright in the delivered source code is assigned to you on payment, and it should name what is delivered: the repository, the deployment configuration, the database schema, the designs.
Expect a carve-out for the vendor's pre-existing libraries and general know-how. That is normal and reasonable. What is not reasonable is a licence to use the thing you paid to have built, where the vendor retains ownership and you discover it when you want to change supplier. Our note on what owning your source code actually means goes through the distinction.
Acceptance, in writing
Define how a deliverable is judged complete. Not "to the client's satisfaction", which is unbounded and unfair to both sides, but against a written scope, within a stated review window, with a defined number of correction rounds.
Without that, two failure modes appear. The vendor calls something done that plainly is not, or the client withholds sign-off indefinitely while asking for new things. Both are contract problems rather than character problems.
What is not included
The exclusions list protects you more than the inclusions list. Content and copywriting, data migration from the old system, third-party licences and subscriptions, training, the hosting bill, work on devices or browsers not listed: each of these turns into an argument if it is assumed rather than stated.
Ask directly what is not in the quote. A vendor who answers that question clearly is telling you they have thought about the project. We wrote about the related pattern in why adding it later costs more.
What happens after launch
Software is not finished at launch, it is launched. The contract should say what the vendor fixes for free and for how long, what counts as a defect against a change, what support costs per year, and how quickly someone responds when the site is down.
A warranty period of thirty to ninety days for defects is common. Separate it explicitly from new work, because the boundary between "it is broken" and "I want it different" is where most post-launch friction lives.
Leaving
- Termination. Either side can end it, with notice, and you pay for work done to that point.
- Handover. On termination you get the code, the data, the credentials and the documentation, within a stated number of days.
- Your accounts stay yours. Domain, hosting and app store listings registered to you throughout, not transferred at the end.
- Data on request. You can take a full export at any time, without having to ask nicely.
These clauses cost nothing while the relationship is good and are the only thing that matters when it is not.
Frequently asked questions
Do I need a lawyer for a small project?
For a small website, a clear written scope with the five points above is usually proportionate. For anything holding customer data or money, have a lawyer read it. The cost of the review is small against the cost of the dispute.
Who owns the code by default?
Do not rely on a default. Positions vary and the point of the clause is to remove the question entirely. Get the assignment written down.
What is a fair payment schedule?
Staged against milestones, with a deposit at the start and a final portion on acceptance. Full payment up front removes the vendor's incentive to finish; full payment at the end makes the vendor your bank.
Should I expect a warranty?
Yes, for defects, for a defined period. It covers things that do not work as specified, not things you have decided you want differently.
What if we disagree about whether something is a bug?
Write down in advance that the written scope decides it. That is the whole reason the scope is worth the time it takes to produce.
Enjoyed this article? Share it with others!
Written by
Antbytelabs
Writing about the software we build at Antbytelabs in Bhaktapur, Nepal.