Software Development Contracts: What to Check Before Signing

Most software development contracts are signed in a state of optimism. Both parties are excited about the project, the relationship is warm, and the future looks straightforward. Nobody reads the dispute resolution clause carefully when they believe there will never be a dispute. Nobody scrutinises the IP assignment when they assume the agency will do the right thing.

The problem is that contracts are not written for the good times. They are the only document that governs what happens when things go wrong — when scope balloons, when the agency misses deadlines, when you need to terminate the engagement, when you discover the code was built on a library with an incompatible licence. By the time you need the contract, you are already in a difficult situation. If you did not read it properly before signing, you are about to find out exactly how much leverage you do not have.

We have had clients come to us who lost IP they believed they owned, who could not terminate a failing engagement without paying tens of thousands in notice fees, and who discovered mid-project that the NDAs they signed did not actually cover their business concept. Every single one of them would have spotted the problem if they had known what to look for before signing.

This guide covers the clauses that matter, the ones that are commonly missed, and the provisions you should refuse to accept. It is written for founders, product managers, and procurement leads — not lawyers — and it is designed to give you enough fluency to review a contract intelligently, even if you bring in a solicitor for the final check.

---

IP Ownership

This is the single most important clause in any software development contract, and it is the one most frequently misunderstood.

The standard you should expect is full assignment of intellectual property rights on payment in full. That means when you have paid, the code, the documentation, the design assets, and any derivative works belong to you absolutely. Not to the agency. Not under a licence. To you.

What that clause should say, in plain terms: the agency irrevocably assigns to you all intellectual property rights in the deliverables, including copyright, upon receipt of final payment. There should be no carve-outs, no retained rights, and no licence language masquerading as ownership.

What to watch out for:

• "Licence to use" language instead of assignment. If the contract says the agency "grants you a licence" to use the software, you do not own it. You are renting it. The agency retains ownership and can, in theory, revoke or alter the terms. This wording is sometimes dressed up to look like ownership. Read every word.
• Retained rights for "pre-existing IP." Agencies legitimately retain ownership of tools, frameworks, libraries, and boilerplate they bring to a project. That is fair. What is not acceptable is pre-existing IP that is so broadly defined it encompasses the core functionality of what you commissioned. Ask them to list specifically what pre-existing IP is being retained and ensure you have an irrevocable, royalty-free licence to use it within your product.
• Conditional IP assignment. Some contracts include clauses where IP "reverts" to the agency if you miss a payment or breach a term. We cover this in the red flags section. Never accept it.
• Work-made-for-hire vs. assignment. In some jurisdictions, software created by a contractor does not automatically qualify as "work made for hire." A clean assignment clause bypasses this ambiguity entirely. Make sure the contract uses explicit assignment language regardless of jurisdiction.

Ask the agency to confirm in writing, before you sign, that you will own the IP outright upon payment. Any hesitation is a signal worth investigating.

---

Scope of Work

A vague scope of work is a budget leak waiting to open. The Scope of Work (SOW) is the document that defines exactly what the agency is building for you, and if it is imprecise, every disagreement about what is "included" will be resolved in the direction of additional cost.

What a well-defined SOW includes:

• A specific list of features and functionality, not a general description of the product
• Acceptance criteria for each deliverable — how will you both know when something is done?
• Platform and technology stack decisions
• Third-party integrations with named systems
• Performance expectations where relevant (page load times, concurrent user thresholds)
• What is explicitly out of scope

The change request process matters as much as the SOW itself. No project survives contact with reality without changes. The question is whether changes are handled transparently or used as a mechanism to extract additional revenue without your full understanding. A good contract specifies a formal change request process: the client submits a change request in writing, the agency provides a written impact assessment covering time and cost, and work on the change only begins after you have approved it in writing.

Be suspicious of any contract that does not define how changes are handled. "We will accommodate reasonable changes at no extra cost" is not a process — it is a vague promise that evaporates the moment you and the agency disagree on what "reasonable" means.

The SOW should be an exhibit or schedule attached to the contract, not embedded in a sales email. If it is only in an email chain, get it formalized before you sign the main agreement.

---

Payment Terms

Payment structure is where the power dynamics of a project are set. How you pay, and when, determines how much leverage you retain throughout the engagement.

The three main structures:

• Milestone-based. Payment tied to defined deliverables. You pay when something specific is completed and accepted. This is the most client-friendly model for fixed-price projects because your money is always behind value received.
• Time-and-materials. You pay for hours worked, usually weekly or monthly in arrears. This is standard for ongoing retainers and iterative development. The risk is uncapped cost if scope is not managed tightly.
• Deliverable-based upfront. You pay a fixed price for a defined output. This is reasonable for small, well-scoped pieces of work.

The rules we recommend:

Never pay more than 30–40% of the total contract value upfront. An initial deposit of 20–30% is standard and reasonable — it covers the agency's onboarding cost and gives them confidence you are serious. Anything higher than 40% upfront tips the leverage in their favour. If a project fails or is not delivered, recovering a 60% upfront payment through legal action is expensive, slow, and uncertain.

Milestone payments should be tied to acceptance, not to the passage of time. "We will invoice on the last Friday of each month" is not milestone-based billing — it is time-based billing labelled as milestones. Acceptance criteria in the SOW become the gate for payment.

Retention clauses are worth requesting on larger engagements. A retention of 5–10% of the final payment, held for 30–60 days after go-live, incentivises the agency to fix post-launch bugs promptly. Not all agencies will agree to this, but it is worth negotiating.

---

Confidentiality and NDA

Most software development contracts include a confidentiality clause. The question is whether it covers what you actually need protected.

What should be covered: your business concept, your data, your technical architecture, any trade secrets you disclose during discovery, your customer data, and the existence of the engagement itself if that is commercially sensitive.

Mutual vs. one-way NDA: In most cases, a mutual NDA is appropriate. The agency may share information about their methods, pricing structures, or tooling with you during the engagement — a one-way NDA that only protects you can create friction. Mutual NDAs are standard and should not be a point of contention.

Duration: Confidentiality obligations should survive the contract. A clause that says confidentiality applies "during the term of this agreement" is not protecting you after the engagement ends. The standard is two to five years post-termination for general confidential information, with no time limit for trade secrets.

Subcontractors: If the agency uses subcontractors or offshore developers on your project, ensure the confidentiality clause explicitly requires the agency to bind those parties to equivalent obligations. A confidentiality clause that only covers the agency's own employees is a gap.

---

Warranties and Liability

Software development contracts frequently contain warranties that sound comprehensive but offer little practical protection, and liability clauses that are either missing entirely or heavily stacked against the client.

What a software warranty should look like: A reasonable warranty provision commits the agency to correcting defects in the software that are reported within a defined period after go-live — typically 30 to 90 days. It should cover defects that cause the software to materially fail to perform as specified in the SOW. It should not require you to prove that the bug existed at launch, only that it exists within the warranty period.

What a warranty is not: No credible agency will or should guarantee that software contains no bugs. Software is complex. What they can reasonably guarantee is that they will fix bugs in the specified period at no additional cost. Be wary of sweeping warranties that promise perfection — they are either unenforceable or will be used to argue that every issue is outside scope.

Liability caps: Most contracts include a cap on the agency's total liability, typically equal to the fees paid under the contract. This is standard and broadly acceptable. What is not acceptable is a liability cap of a nominal figure (say, £500 or £1,000) on a £50,000 engagement, or a cap combined with a blanket exclusion of consequential losses that would prevent you recovering meaningful compensation for a failed delivery.

Indemnification: The contract should include a mutual indemnification clause covering third-party intellectual property claims. Specifically, the agency should indemnify you if the software they deliver infringes a third party's IP rights. You should also check whether you are indemnifying the agency for any IP you provide — this is reasonable, but ensure the scope is limited to the assets you actually contribute.

---

Termination

Your right to exit an engagement that is not working is one of the most important protections in any service contract, and it is one clients frequently fail to negotiate before signing.

Right to terminate for convenience: You should have the right to terminate the contract without cause, with reasonable notice. Typically 30 days is standard. Some contracts include only termination for cause — meaning you can only exit if the agency has materially breached the contract. This leaves you trapped in a failing relationship unless you can prove breach, which is often difficult and time-consuming to establish.

What you receive on termination: The contract should clearly state that on termination you receive: all code developed to date, in a deliverable state; all documentation; access credentials for any environments, repositories, or services set up on your behalf; and a clear transition plan. An agency that retains code until a dispute is resolved has significant leverage over you. Do not accept this.

Notice periods and payment on termination: If you terminate for convenience, you should expect to pay for work completed to the termination date. What you should not accept is a requirement to pay for work not yet started, or a "cancellation fee" that amounts to a significant percentage of the remaining contract value. Some contracts include liquidated damages on termination — review these carefully.

Termination for cause: You should also have the right to terminate immediately, without notice, if the agency commits a material breach that is not remedied within a reasonable cure period (typically 14–21 days after written notice).

---

Dispute Resolution

Disputes in software development are common — over scope, quality, timelines, payment, and IP. How a dispute is resolved, where it is resolved, and at what cost can matter as much as the outcome.

Jurisdiction: For domestic engagements, ensure the governing law and jurisdiction is your home jurisdiction. For international engagements, this is a material negotiation point. An agency based in Eastern Europe or South Asia may propose their local jurisdiction. The practical implication is that if you need to enforce a judgment, you need to do so in their country — which may be expensive, slow, or effectively impossible.

Escalation process: Good contracts include a staged escalation process: informal discussion between project leads, then senior management escalation, then formal mediation, then arbitration or litigation. This is both sensible and cost-effective — most disputes can be resolved without formal proceedings if there is a structured process.

Arbitration vs. litigation: Arbitration is generally faster, less expensive, and more private than litigation. For disputes under a certain threshold (often £50,000–£100,000), the cost of arbitration is proportionate. Ensure any arbitration clause specifies a recognised arbitral body and a seat of arbitration in your jurisdiction.

International note: If you are contracting with an agency outside your jurisdiction, consider requiring the contract to be governed by the law of England and Wales or another internationally neutral common-law jurisdiction. This gives you access to well-developed commercial law and a predictable enforcement regime.

---

Data Processing Agreement (GDPR)

If the software being developed will process personal data — of your customers, your staff, or any individuals in the EEA or UK — you are legally required to have a Data Processing Agreement (DPA) in place with any party that processes that data on your behalf.

This is not optional. It is a requirement under UK GDPR and the EU GDPR, and the absence of a DPA exposes you to regulatory risk if there is ever a data breach or a supervisory authority audit.

Who is who: In almost all software development relationships, you are the data controller — you determine the purpose and means of processing. The agency is the data processor — they process data according to your instructions. The DPA should reflect this clearly.

What the DPA should cover:

• The categories of personal data being processed and the purposes for processing
• The agency's obligations to process data only on your documented instructions
• Appropriate technical and organisational security measures
• Restrictions on sub-processing (the agency cannot pass your data to a third party without your authorisation)
• Assistance with data subject requests and breach notification
• Deletion or return of personal data at the end of the engagement
• Audit rights

If an agency refuses to sign a DPA or claims it is unnecessary for a development engagement, treat it as a serious red flag. Even in a development context, personal data is often loaded into test environments — and that data needs to be protected.

---

Red Flag Clauses to Reject

Some contract terms are not just unfavourable — they are provisions that experienced clients learn to identify and refuse. These are the clauses that look innocuous during the optimistic phase of signing and become damaging when things go wrong.

IP that reverts on missed payment. Any clause that transfers IP ownership back to the agency if you miss a payment, even temporarily, gives the agency a nuclear option over your product. A payment dispute — which can happen for legitimate reasons — should be resolved through payment recovery mechanisms, not through clawing back the IP of something you have already paid for in large part.

Unlimited client liability. Some contracts include clauses where the client indemnifies the agency broadly for any losses arising from the project. This can include losses caused by the agency's own errors. No client should accept unlimited liability or indemnities that extend beyond the assets and information they directly contribute.

No termination right without cause. If you cannot exit the contract without proving the agency breached it, you have signed away your ability to respond to a failing engagement without entering a legal dispute. Always insist on a termination-for-convenience right.

No staging environment access. This is a practical red flag rather than a legal one. If the contract does not guarantee you access to a staging environment throughout the build, you have no independent visibility of what is being built until the agency decides to show you. Insist on continuous access.

Auto-renewal with long notice periods. Retainer contracts that auto-renew for 12-month terms with 90-day cancellation windows are designed to trap clients in arrangements they want to leave. 30-day rolling notice on a monthly retainer is standard.

Broad non-solicitation clauses. Many agencies include clauses preventing you from hiring their developers for a period after the engagement. A narrow non-solicitation covering developers directly assigned to your project for 12 months is reasonable. A sweeping clause covering all agency staff for 24 months is an attempt to protect their labour pool at your expense.

---

How Our Contracts Are Structured at Cyberbeak

We are not neutral on this topic — we are a software development agency, and we have a view on how contracts should work. We think it is worth being transparent about how we approach our own.

Our standard agreements include full IP assignment to the client on receipt of final payment. There are no retained rights beyond standard pre-existing libraries and tools, which are listed and covered by an irrevocable licence. We use milestone-based payment structures for fixed-price projects, with milestones tied to acceptance criteria agreed in the SOW. We do not ask for more than 30% upfront.

Every engagement with personal data processing includes a DPA as standard. Confidentiality is mutual. Our liability cap is set at fees paid under the contract, with standard exclusions for fraud and wilful misconduct. Clients have a 30-day termination-for-convenience right. On termination, all code, documentation, and credentials are transferred within five business days.

We include a 60-day defect correction warranty post-launch on all fixed-price projects.

We believe these terms are fair to both sides, and we are comfortable with clients having a solicitor review them. If a prospective agency pushes back on any of these provisions, it is worth asking why.

---

Frequently Asked Questions

Do I need a solicitor to review a software development contract?

For any engagement above £15,000–£20,000, we would strongly recommend it. A commercial solicitor with technology contract experience can review a standard software development agreement in one to two hours. The cost is typically £300–£600. Given what is at stake — your IP, your ability to exit, your data obligations — it is one of the highest-return investments you can make. For smaller engagements, reading this guide and applying it yourself may be sufficient, but professional review is never wasted.

What if the agency won't negotiate the contract terms?

Most reputable agencies will negotiate on material points. If an agency refuses to discuss IP assignment, liability, or termination rights, that tells you something important about how they approach client relationships generally. Minor stylistic resistance is normal — blanket refusal to negotiate substantive protections is a red flag. If they genuinely have a non-negotiable standard form, ask them to explain every clause you are uncertain about in writing. Their explanations will tell you a great deal.

What about verbal agreements and email discussions?

Verbal agreements are legally binding in most jurisdictions, but they are extremely difficult to enforce because there is no clear record of what was agreed. Email discussions carry more weight and can constitute a binding agreement in some circumstances, but they create ambiguity about scope and terms. The only safe position is to ensure every material term — scope, payment, IP, termination — is captured in a signed written agreement before work begins. If an agency starts work on the basis of a verbal go-ahead and things go wrong, you may have very limited recourse.

Can I use a standard template contract instead of the agency's terms?

Yes, and in many cases it is preferable. If you commission software regularly, having your own standard terms drafted by a solicitor once and used consistently across engagements gives you a known baseline. The agency may request amendments, and that is a negotiation — but starting from your own template means you start from terms structured in your favour. Templates are also available from organisations like TechUK and the Law Society, though these should be reviewed by a solicitor to ensure they reflect your specific circumstances.

---

Getting the contract right is not about distrust. It is about ensuring that both parties have the same understanding of what they have agreed to, and that there is a clear, fair process for handling the things that inevitably go differently than planned.

If you are evaluating a software development engagement and would like to understand how our agreements are structured, or if you have questions about what specific contract terms mean in practice, we are happy to have that conversation. Reach out to us — no obligation, no sales pitch, just a straightforward discussion about what fair terms look like.