What to check in a software house contract — including ours

Disclosure first: we are a software house, and this page teaches you to negotiate against us. We wrote it because a founder who asks for these clauses is a better client — they know what they are buying, and a project that starts from shared understanding ends with fewer arguments.

What follows is not legal advice and is not a substitute for a lawyer. These are the clauses we have watched determine what actually happens when something goes wrong, and what separates them from the rest of the contract is that they cannot be fixed after the fact.

Code ownership

The most important clause, and frequently the most vaguely worded. "The client receives a licence to use" is not ownership. Ownership means you can take the code to another developer, change it and sell a product built on it, without asking permission.

You also have to look at what is not the code itself: cloud accounts, the domain name, the repository, third-party service keys and the app store account. We have seen more than one situation where ownership of the code was clear but the domain was registered to the software house, leaving the client dependent anyway.

Repository access throughout

A contract promising code delivery at the end of the project promises you a sealed box on an unknown date. Read access to the repository from day one is not a statement of distrust but basic protection: it lets you see that progress exists, and lets an outside developer assess the state if you ever need one.

A partner who refuses usually explains that the code is not tidy yet. That is an answer about process, not about commercial risk. We grant access at project kickoff, and it is what we would tell you to ask of anyone else.

What counts as delivery

Most end-of-project arguments are not about quality but about definition. If the contract says "development of the application" with no detail, each side arrives with a different list in their head. A useful definition of delivery covers four things.

1. What is delivered: which screens, which user paths, and which cases are explicitly out of scope — in writing.
2. Where it runs: a live production environment with a domain, not only code in a repository.
3. What counts as working: an agreed acceptance criterion, including behaviour in failure states.
4. What happens afterwards: a warranty period for defect fixes, and what counts as a defect rather than a change.

That last one generates the most friction. The line between a defect and a change has to be written down, because without it every request after delivery becomes a conversation about money at precisely the moment both sides are most tired.

Exit terms

Nobody signs a contract planning to separate, which is why this is the least-read clause. It is also the only one read carefully when it is actually needed. Ask three questions: what happens to the code and accounts if you stop midway, what is required to hand the project to another team, and how much notice is needed.

A healthy answer is an orderly handover of code and accounts against payment for work actually performed, plus a short transition document. A problematic answer is any wording conditioned on full payment of the entire contract, including work never done.

That bears on the contract more than it seems: if the large risk is discovering the product is not needed, the contract has to let you stop and change direction without losing what was already built. A contract that penalises stopping makes exactly the decision you most need to be able to make more expensive.

What matters less than it seems

A highly detailed payment schedule, bug warranties beyond a reasonable window, and late-delivery penalties all look like protection and change less than expected. A late penalty mostly causes the supplier to price the risk in advance, and everybody pays for it.

What is worth the time is scope clarity. A good contract against a vague scope still ends in an argument. We wrote about defining a scope that holds in our piece on MVP definition, and about the differences between supplier types in software house vs freelancer.

How to open that conversation

Many founders worry these requests will read as distrust and sour the relationship before it starts. Our experience runs the other way: a supplier who gets defensive about a question on ownership and exit terms has answered exactly what you asked, and one who produces the answers immediately has clearly been through it before.

The framing that works is simply to say you want to understand what happens if the project stops, so that neither of you is having that conversation for the first time while it is happening. That is easy to agree to, and it produces exactly the same document.