Quick summary
The most dangerous clause in a software contract is the missing one. The three that matter most: explicit source-code ownership — because without express wording, rights generally stay with whoever wrote the code rather than whoever paid; whose name the accounts use — domain, hosting, store; and acceptance criteria — how everyone knows delivery is done without argument. This is a practical guide for project owners, not legal advice.
The twelve clauses
| # | Clause | What it protects you from |
|---|---|---|
| 1 | Written scope listing what will and will not be built | "I assumed that was included" — the most common dispute |
| 2 | Source-code ownership with an express assignment to you | Owning an app but not its code |
| 3 | Accounts in your name: domain, hosting, store, database | Your product becoming hostage to a disagreement |
| 4 | Payments tied to deliverables, not dates alone | Paying for elapsed time with no result |
| 5 | Acceptance criteria — how delivery is tested and who signs off | "It's done" versus "it isn't" with no reference |
| 6 | Warranty period after launch and its scope | Paying twice to fix an original defect |
| 7 | Change-request process and its pricing | Silent scope creep from both sides |
| 8 | Handover and documentation — literally what is delivered | Receiving "an app" without what runs it |
| 9 | Confidentiality and customer-data protection | A leak with unclear responsibility |
| 10 | Right to showcase the project — or to forbid it | Your project appearing publicly before launch |
| 11 | Early termination: what happens to payments and work done | Losing everything if work stops |
| 12 | Dispute resolution and governing terms | A disagreement with no path forward |
The clause that matters most: ownership
Many owners assume paying means owning. That is a dangerous assumption. As a general principle of copyright, rights arise with the creator, and transferring them to the client requires express wording. Without it you may own a working copy but not the right to modify it or move it to another developer.
And ownership is broader than the word "code". Name it explicitly: the source and its change history in a repository you own; editable design files, not exported images; store, domain, hosting and database accounts; keys and secrets with an obligation to rotate them at handover; and the right to modify, derive and move the work without permission.
A fair exception you should accept: the vendor may retain the right to reuse generic components they built before you and use with others. That is legitimate — what matters is that it is stated clearly and does not cover what was built specifically for you.
Payments: tie them to delivery
| Payment | Against what | Typical share |
|---|---|---|
| First | Start of work and an approved written scope | 25 – 30% |
| Second | Approved, testable design | 20 – 25% |
| Third | A working beta you use yourself | 25 – 30% |
| Final | Launch, full handover and documentation | 20 – 25% |
The final payment comes after handover, not before. Paying 100% up front is not trust — it is risk with nothing in return.
Acceptance criteria
"Delivered" carries two readings. Make it measurable: the app runs on named devices, the functions listed in the scope pass a test both parties attend, and a defined review window (say five days) in which feedback must be raised or delivery is deemed accepted. That last part protects both sides — you from incomplete delivery, the vendor from endless review.
We work to a written contract and scope on every project — see custom business systems.
Note: this is practical guidance for project owners, not legal advice. Have final wording reviewed by a lawyer, especially ownership, liability and dispute clauses.
