Liability Caps in Contracts for UK Mobile App Developers

If you build, commission or outsource mobile apps in the UK, the liability cap in your contract can decide who carries the loss when something goes wrong. Founders often focus on price, deadlines and features, then accept a cap buried in standard terms without checking what it actually covers. Another common mistake is agreeing to a cap tied only to the fees paid, even where the app will process user data, handle payments or connect with core business systems. A third is assuming every type of loss can be capped in the same way.

The result is usually one of two problems. A developer ends up exposed to claims far bigger than the project fee, or a customer discovers the contract gives very little practical remedy after a serious failure. This guide explains how liability cap clauses work for UK mobile app developers, what limits the law places on them, what to check before you sign, and where founders and SMEs most often get caught.

Overview

A liability cap is the clause that limits how much one party can be required to pay if it breaches the contract or causes loss. In mobile app development deals, the cap often sits alongside exclusions for indirect loss, carve outs for specific risks, indemnities, warranty wording and service levels, so it should never be read in isolation.

• How the cap is calculated, for example a fixed sum, the fees paid, or a multiple of fees.
• Which claims fall inside the cap and which are carved out, such as confidentiality breaches, data protection issues or IP infringement.
• Whether the contract excludes certain losses, including loss of profit, revenue, goodwill or data.
• Whether separate caps apply to different risks, rather than one catch-all limit.
• Whether the clause is likely to be enforceable under UK rules on reasonableness and unfair terms.
• How the cap works with insurance, indemnities, warranties, support obligations and subcontracting.

What Liability Cap Contract Mobile App Developers Means For UK Businesses

A liability cap sets the financial boundary of contractual risk, and in app projects that boundary can be the difference between a manageable dispute and a very expensive one.

For a mobile app developer, the cap is usually there to stop a modestly priced project turning into an unlimited claim if the app fails, launches late or causes downstream losses. For the customer, the cap should still leave enough value in the contract to make the developer meaningfully accountable.

What a liability cap usually looks like

Most app development agreements use one of a few models.

• A fixed monetary cap, such as £50,000.
• A fees-based cap, such as 100 per cent of fees paid or payable under the contract.
• A multiple of fees, such as 125 per cent or 200 per cent of the charges.
• Different caps for different categories of risk, such as one cap for general breach and a higher cap for data protection or confidentiality claims.

The right model depends on the size of the job, the importance of the app to the customer's business, the sensitivity of the data involved, and whether the app will process payments, health information, location data or other higher-risk categories.

Why app projects create specific liability issues

Mobile apps are rarely simple brochure tools. They often connect to payment gateways, customer databases, analytics tools, APIs, cloud hosting and third-party software development kits. A bug in one part of the system can trigger losses well beyond the original coding fee.

That is why app contracts often raise a wider set of risks than a standard freelance services agreement. Common examples include:

• Security vulnerabilities exposing personal data.
• Defects that stop users from transacting or accessing paid services.
• Infringement claims relating to code, assets, libraries or app store content.
• Missed delivery dates linked to a marketing campaign or investor milestone.
• Confidentiality breaches involving roadmaps, algorithms or customer lists.
• Failures caused by subcontractors, offshore teams or third-party integrations.

When these risks are real, a single blanket cap can be too blunt. A better contract often separates them out.

Caps, exclusions and carve outs are not the same thing

Businesses often confuse the liability cap with the whole liability clause. They are related, but different.

The cap limits the amount payable. Exclusions remove certain types of loss altogether. Carve outs preserve liability for specific matters even if the general cap or exclusions would otherwise apply.

For example, a contract might say:

• general liability is capped at the total fees paid in the previous 12 months;
• neither party is liable for indirect or consequential loss, or for loss of profit or revenue; and
• the cap does not apply to death or personal injury caused by negligence, fraud, or breach of confidentiality.

That creates a very different risk position from a simple sentence saying liability is limited to the project fee.

What UK law does and does not allow

UK law does not let businesses exclude or limit every type of liability however they like. Some limits are restricted by statute, and others must pass a reasonableness test.

At a high level, you generally cannot exclude liability for fraud. Liability for death or personal injury caused by negligence cannot be excluded. Other attempts to restrict liability, especially in standard terms, may be tested for reasonableness under the Unfair Contract Terms Act 1977.

Reasonableness depends on the context, not a single formula. Relevant factors often include:

• the parties' relative bargaining power;
• whether the term was negotiated or simply imposed in standard terms;
• whether the customer knew or should have known about the clause;
• the availability of insurance;
• the practical ability of the supplier to meet the risk; and
• whether the cap bears a sensible relationship to the contract value and the potential harm.

That means a very low cap may not hold up just because it appears in writing. It also means a customer should not assume a harsh clause is automatically unenforceable. The drafting and commercial background both matter.

Why this matters before you accept the provider's standard terms

Many UK startups and SMEs buy development services on the developer's template or sell their own services on a lightweight contract downloaded years ago. This is where founders often get caught.

If you are the developer, a weak clause may leave you exposed for losses you never priced in. If you are the customer, a low cap may turn a serious problem into an uninsured business loss you cannot recover.

The right answer is not always to demand unlimited liability. In many projects, that is unrealistic and may simply stall the deal. The practical goal is a cap structure that reflects the real risks of the app, the project fee, and the parties' ability to insure against those risks.

Legal Issues To Check Before You Sign

The main legal question is not whether the contract contains a cap, but whether the cap matches the actual risk profile of the app project.

1. How is the cap calculated?

Read the formula carefully. A cap based on fees paid can be much lower than expected if the project fails early or payments are staged.

For example, if a £120,000 app project is terminated after £20,000 has been paid, a cap tied to fees paid may leave only £20,000 of recovery for the customer. If you intended the cap to reflect the whole contract value, the written terms should say so.

Key drafting points include:

• whether the cap is based on fees paid, fees payable, or total contract charges;
• whether it applies per claim or in aggregate;
• whether it resets annually in an ongoing support agreement; and
• whether separate statements of work have separate caps.

2. Which liabilities are carved out?

Most negotiated app contracts carve out some categories from the general cap. Those carve outs are often more important than the headline figure.

Common carve outs include:

• fraud or fraudulent misrepresentation;
• death or personal injury caused by negligence;
• breach of confidentiality;
• intellectual property infringement;
• data protection breaches;
• wilful default or deliberate misconduct; and
• non-payment of fees.

There is no universal market position on which carve outs should be unlimited and which should have a higher separate cap. A sensible result usually depends on the nature of the app and who controls the relevant risk.

3. Are important losses excluded entirely?

Many contracts exclude indirect loss and then go further by excluding named losses such as loss of profit, revenue, business, goodwill, anticipated savings or data. That can significantly reduce practical recovery.

Customers should ask whether those exclusions go too far for the project. Developers should ask whether the wording is still commercially acceptable and likely to be enforceable.

This matters most where the app is central to sales, booking, subscriptions or service delivery. If the app goes down for a launch weekend, the customer's real loss may be revenue. A contract excluding all revenue claims and capping the remainder at a low figure may offer very little protection.

4. How does the cap interact with data protection obligations?

If the app collects or processes personal data, the contract should deal with data protection separately and carefully. A basic cap clause is not enough.

Questions to check include:

• who is acting as controller and who is acting as processor;
• whether there is a compliant data processing clause;
• whether security obligations are clearly stated;
• whether personal data breaches are subject to a separate cap; and
• whether subcontractors can process data and on what terms.

Where user data is a core feature of the app, parties often negotiate a higher cap for data breaches than for ordinary delivery delays or defect claims.

5. What happens with IP infringement claims?

App projects often reuse libraries, frameworks, designs and third-party content. That creates real IP risk.

If the developer is giving an IP infringement indemnity, the customer will want to know whether that indemnity is inside or outside the general cap. If the developer is taking responsibility only for code it creates itself, that should be stated clearly. If the customer supplies content, branding or specifications, responsibility for those materials should also be allocated clearly.

Before you rely on a verbal promise that all code is fully original, make sure the written contract covers:

• ownership of bespoke code;
• licences for pre-existing materials and third-party components;
• warranties about authority to use supplied materials; and
• the remedy if an infringement claim arises, such as replacement, modification or suspension.

6. Does insurance support the agreed position?

A liability cap should make sense alongside the insurance each party carries. If a developer agrees to a very high cap for security or IP claims but has no meaningful cover, that promise may not be realistic.

Likewise, if a customer expects broad recovery for outages or data incidents, it should consider whether it has its own cyber or business interruption cover rather than relying solely on the contract.

Insurance does not replace good contract drafting, but it often influences what a reasonable cap looks like.

7. Are support and maintenance risks covered?

The biggest losses often happen after delivery, not during build. An app may launch on time but then fail under load, break after an operating system update, or suffer a security issue months later.

If support is included, check:

• whether service levels and response times are clear;
• whether the cap for support failures differs from the build cap;
• whether credits are the sole remedy for downtime; and
• whether the supplier can suspend support for third-party compatibility issues.

These details matter if your business depends on the app staying live.

Common Mistakes With Liability Cap Contract Mobile App Developers

The most common mistake is treating the liability cap as a standard boilerplate clause when it is actually one of the key commercial terms in the whole contract.

Accepting a cap that only reflects the supplier's fee

A low-value build can support a high-value business process. Founders often sign a contract where liability is capped at the project fee, even though the app handles bookings, subscriptions or customer accounts. If the app is mission critical, the cap should be negotiated with that in mind.

Using one cap for every kind of risk

Not all breaches create the same type of harm. Delay, ordinary defects, confidentiality breaches and IP claims rarely justify exactly the same limit.

A more balanced clause may use:

• a general cap for ordinary breach;
• a higher cap for data protection and confidentiality;
• a specific position on IP indemnities; and
• uncapped liability only for the narrow categories the law or commercial reality really requires.

Overlooking what has been excluded

Businesses often negotiate the cap figure and miss the exclusion list. A contract with a reasonable-looking cap can still be heavily one-sided if the main losses you would actually suffer are excluded altogether.

This is especially common where standard terms exclude:

• loss of profit;
• loss of revenue;
• loss of business opportunity;
• loss of data; and
• loss of goodwill.

If those are your most likely losses, the headline cap may not tell you much.

Assuming a clause is enforceable because it is in the contract

Some businesses rely on very aggressive supplier-friendly wording and assume that settles the issue. It may not.

Under UK law, particularly where standard terms are used, an exclusion or limitation clause can be challenged for reasonableness. That does not mean the clause will definitely fail, but it does mean unrealistic drafting can create false confidence.

Forgetting subcontractors and third-party tools

Many app developers use subcontractors, cloud services, APIs or off-the-shelf libraries. If your contract promises broad liability while upstream suppliers limit theirs, the risk gap sits with you.

Developers should align customer commitments with supplier arrangements where possible. Customers should ask who is actually building the app and whether third-party dependencies affect support, warranties or liability.

Relying on informal assurances

Founders often proceed because the other side says things like, "we always fix issues quickly" or "we would never rely on that clause". Those comments may help the relationship, but they are not a substitute for clear drafting.

Before you sign, make sure the contract records the agreed position on:

• delivery and acceptance;
• support obligations;
• security standards;
• ownership and licensing of code;
• indemnities; and
• the final liability structure.

FAQs

Can a UK mobile app developer exclude all liability?

No. Some liabilities cannot be excluded, such as fraud and liability for death or personal injury caused by negligence. Other limits may also need to satisfy a reasonableness test under UK law.

What is a typical liability cap in an app development contract?

There is no single standard figure. Many contracts use the fees paid, the total contract value, or a multiple of fees, sometimes with higher caps for data protection, confidentiality or IP claims.

Should data breaches sit outside the general cap?

Not always, but they often justify a separate and higher cap. The right position depends on the amount and sensitivity of personal data, each party's role, and the practical level of risk in the project.

Is unlimited liability normal for IP infringement?

No, not necessarily. Some contracts make IP claims uncapped, but many use a separate cap. The sensible position depends on who provides the materials, how much third-party code is used, and what insurance is available.

Does the liability cap cover breaches after launch?

Usually yes, if those breaches arise under the contract, but you need to check the wording. Support, maintenance and ongoing service terms may have their own liability structure, especially in longer-term arrangements.

Key Takeaways

• A liability cap in a mobile app development contract sets the financial limit for claims, but it only makes sense when read together with exclusions, carve outs, indemnities and support obligations.
• For UK businesses, the main issue is whether the cap reflects the app's real risk profile, especially where the app handles payments, personal data, subscriptions or core customer functions.
• Caps based only on fees paid can be much lower than expected, particularly if the project ends early or payments are staged.
• Data protection, confidentiality and IP infringement often need separate treatment rather than being folded into one general cap.
• Some limits on liability are restricted by UK law, and standard terms may be tested for reasonableness.
• Before you sign, check the cap formula, excluded losses, carve outs, insurance position, subcontracting arrangements and post-launch support terms.

If you want help with contract drafting, contract review, negotiating liability clauses, data protection terms, and IP risk allocation, you can reach us on 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.