Software Development Contract: What to Check

Five clauses in a software development contract matter more than the price: a scope annex attached in writing, assignment of the source code and the economic rights in it, acceptance criteria, payment instalments tied to acceptance rather than calendar dates, and a warranty kept separate from maintenance. In most jurisdictions the developer — not the client who paid the invoice — holds copyright in commissioned code unless it is assigned in writing, and “work made for hire” is narrower than people assume: for software built by an outside supplier it normally still requires a signed assignment. Below is how to read a software contract clause by clause, which sentences actually bind you, and which gap real disputes come out of.

The real contract lives in the annex

The opening pages are near-identical at every firm: parties, term, confidentiality, notice addresses. Almost every dispute, however, comes out of the annex those pages refer to — because that is where “what will be built” is written. A one-line subject such as “development of a corporate website and admin panel” produces an argument six months later in which both sides are genuinely convinced they are right. The most efficient way to produce the scope annex is to carry your tender brief straight into the contract; the headings in our software project brief guide can be attached as-is.

• Screen and module list, with numbers. Not “reporting” but “5 report screens: sales, stock, collections, users, audit log”.
• Roles and permissions — how many user roles exist, what each role can see and change. Role count drives development time directly.
• Integrations and who owns which side — which systems will be connected, who supplies the API documentation and the test account, and whose risk a third party’s delay is.
• Data migration — which data, from which source, how many records, and who cleans it. This is almost always the line item that delays projects most.
• What is explicitly out of scope: content entry, image production, a mobile app, multi-language support, user training. There is a six-week difference between “we never discussed it” and “it is out of scope”.
• Deliverables — source code, database schema, deployment documentation, environment variable list, design files.

Who owns the source code and the IP?

Software is protected as a copyright work, and those rights stay with the developer unless they are assigned in writing. “I paid for it, so it is mine” does not hold. The assignment clause should not be one generic sentence either: reproduction, adaptation, distribution and communication to the public should each be listed as transferred to the client, unlimited in time and territory, and further transferable. Moral rights cannot be assigned in many legal systems — which is exactly why the developer’s right to name the project as a reference belongs in the same conversation.

The second question is how much of the delivered code really belongs to the developer. Every modern project uses open source libraries; most are harmless, but a GPL/AGPL component compiled into the core can make it impossible to later sell your product as closed source. It is also common and reasonable for a supplier to build on their own in-house framework; what is not acceptable is that core being neither assigned nor covered by a perpetual licence in return. Add one sentence: a list of third-party components and their licences is delivered together with the product.

Whoever owns the repository owns the project in practice. Creating the GitHub/GitLab repo under your own company account and inviting the development team into it is a faster-acting safeguard than the assignment clause: if the relationship ends, you revoke access and the code is already yours.

Acceptance criteria: what does “done” mean?

This is the gap that produces the most argument. Delivery and acceptance are not the same event: delivery is when the supplier hands the work over, acceptance is when you say “this is what I expected”. The contract needs an acceptance window (typically 5-15 business days) and a rule for what happens if you stay silent in it. “Deemed accepted if no objection is raised within the period” is standard and fair — but it means you have to guarantee that the person doing the testing exists and is free that week.

• Blocker — the workflow does not run at all. Blocks acceptance, and the acceptance clock stops until it is fixed.
• High — it runs but produces the wrong result. Blocks acceptance; anything that corrupts data always sits in this class.
• Low / cosmetic — alignment, typos, secondary copy. Does not block acceptance, fixed under warranty.
• Each class gets a fix deadline and a right to retest, and the contract should state that retesting is not billed separately.

Writing “the order screen will work properly” as an acceptance criterion is the same as writing nothing, because it cannot be measured. The measurable version reads: “a 1,000-line order loads in under 2 seconds; the error rate stays below 1% at 50 concurrent users; the approval flow rejects an unauthorised approver.” These criteria change scope and therefore man-days, so they belong in the tender phase — we broke down which line items set the price in our custom software cost article.

The change request procedure belongs in the contract

No project finishes with the scope it was written with on day one. The contract’s job is not to forbid change but to route its price and schedule impact through a path agreed in advance. Which commercial model suits you — fixed price, time and materials or a hybrid — is a separate discussion; what matters here is that the change flow is written down whichever model you pick.

• Requests arrive in writing. Email is enough; verbal requests are not actioned.
• The supplier returns an impact analysis: extra man-days, extra cost and effect on the delivery date, together.
• No work starts without written approval — and unapproved work cannot be invoiced. That clause protects both sides.
• Every approved change updates the schedule automatically. “Keep the date and add the scope” is not an available option.
• Define a small monthly allowance for minor work (say 2 man-days), otherwise every copy change turns into a quotation thread.

Payment plan: the final instalment follows acceptance, not delivery

Tying the payment schedule to calendar dates punishes both parties: the date arrives, the work is not finished, and the invoice becomes the argument. The correct anchor is accepted deliverables.

• Kick-off payment of 20-30% — it covers reserving the team and the analysis phase.
• Interim instalments, each tied to acceptance of a milestone: analysis sign-off, first module accepted, integration test passed.
• The final instalment is paid after acceptance rather than at go-live; holding 10-20% back over the warranty period is common.
• A symmetric delay clause: if your approvals, data or access are late, the schedule moves too. One-sided penalty clauses feel reassuring at signature and make every later negotiation harder.

Warranty and maintenance are not the same clause

A warranty is free correction of defects within the delivered scope, limited in time (typically 3-12 months). Maintenance is a separate agreement: updates, monitoring, backups, small improvements and new requests. Merge them into one clause and every ticket becomes a debate about whether it is a bug or a feature. The practical test: if behaviour written in the scope annex does not work, it is a defect (warranty); if behaviour that is not in the annex is being requested, it is new work (maintenance or a change request). We put real numbers on the annual maintenance line in our website maintenance cost article.

• Support hours: business hours or 24/7? This single line drives the biggest part of the price difference.
• Response time and resolution time written separately — “we reply within 4 hours” is not a commitment to fix anything.
• Severity classes, with a separate target per class.
• Hours included per month and the unit rate beyond them.
• One ticketing channel. Support that runs over WhatsApp cannot be measured, so the SLA cannot be enforced.

Data protection: define the processor relationship

If the project handles personal data — customer records, employee details, delivery addresses — the roles are settled: you are the controller, the software firm processes data on your behalf, and security measures are a shared responsibility. What belongs in the contract: which country and which cloud the data sits in, a ban on using real customer data in test and development environments (masking instead), a limited list of staff with access, return or deletion of data at project end, and how many hours the supplier has to notify you of a breach. We collected the implementation-side requirements in our data protection compliant website article.

Termination and exit: the most frequently skipped section

Contracts get written on the assumption that everything will go well, yet the clause you need most only activates when the relationship ends. The point of an exit clause is that you are left with something transferable even if you part ways mid-project.

• Handover of all source code and documentation produced to date, regardless of the reason for termination.
• Transfer of repository, server, cloud and third-party service access — at account ownership level, not by sharing a password.
• Transition support: a defined number of man-days (say 5-10) to hand over to the next team, priced up front.
• The relationship between unpaid balance and the duty to hand over. “No code before payment” is reasonable, but it should be bounded and mutual.

The detail most often missed here is account ownership. Domain name, hosting and cloud subscriptions, the App Store and Google Play developer accounts, the payment provider merchant account — if those are opened in the supplier’s name, the supplier effectively owns the product no matter what the contract says. The rule is simple: accounts are opened under the paying party’s corporate identity and the developer is granted access. We covered whose name the store account should carry in our Play Store publishing fee article as well.

Five mistakes that break the contract

• Leaving scope in the email thread. If the subject of the contract is one line, six months later both sides simply produce their own emails.
• Fixing the price without fixing the scope. A fixed price only makes sense against a fixed scope; with scope open, the difference comes out of either quality or the relationship.
• Postponing the IP assignment to “we will sort it out when the project ends”. Your leverage on assignment is highest before signature.
• Tying the payment schedule to dates without writing acceptance criteria.
• Letting infrastructure and app store accounts be opened in the developer’s name.

Conclusion

A good software contract protects the parties less than it proves that both understood the same thing. In practice what does that is not long legal prose but four annexes: the scope document, the acceptance criteria, the payment milestones and the exit plan. With those four written, the remaining clauses are largely standard. We collected the supplier selection criteria in our choosing an enterprise software company article; if you would like us to map your scope and turn it into a proposal you can attach to a contract, take a look at our custom software development service or request a quote. This article is general information and not legal advice — have your lawyer review the contract before you sign.