The contract arrived on a Thursday afternoon. A Berlin-based SaaS founder had spent three months vetting agencies, reviewing portfolios, and negotiating price. She'd done everything right — or so she thought. Six months after launch, a billing dispute with the agency revealed a clause she'd never noticed: the agency retained a perpetual licence to the codebase. Switching providers meant starting from scratch.
That scenario plays out more often than most founders realise. Across the UK, Ireland, Germany, and the Netherlands, development contracts are routinely signed with far less scrutiny than the agency selection process that preceded them. The portfolio gets reviewed for hours. The contract gets twenty minutes.
This post identifies seven specific terms in a typical development contract that consistently disadvantage the client — and explains exactly how to negotiate each one before you sign. These are not theoretical concerns. They are the clauses that generate disputes, budget overruns, and legal exposure when projects go sideways.
Most founders treat the contract as a formality that follows the real decision. The agency has been chosen. The price has been agreed. The contract is just paperwork. That assumption is expensive.
A development contract governs what you own, what you're entitled to if something goes wrong, how much you'll pay for changes, and what happens if the relationship breaks down. None of those things feel urgent when you're excited about starting a build. All of them feel urgent when a dispute arises.
The seven terms below are not obscure legal technicalities. They are standard clauses that appear in the majority of agency contracts — often written in language that sounds neutral but operates in the agency's favour. Understanding them before you sign is not about distrust. It is about protecting the investment you're about to make.
A well-negotiated development contract protects both parties. An agency that refuses to discuss any of these terms is telling you something important about how they operate.
This is the most consequential clause in any development contract, and the one most frequently misunderstood by clients. Paying for software to be built does not automatically mean you own it. In most jurisdictions, including the UK and Germany, copyright in software defaults to the creator unless explicitly assigned in writing.
Many agency contracts grant the client a "licence to use" the software rather than full ownership. Others include IP assignment language but carve out "pre-existing materials", which can include reusable components, frameworks, and libraries that form a significant portion of the actual codebase. Some contracts assign IP only after all invoices are paid in full, which creates leverage for the agency in any billing dispute.
Push for a full IP assignment clause that transfers ownership of all custom-developed code to you upon final payment. The assignment should cover the source code, documentation, and any derivative works created specifically for your project. Ask the agency to list any pre-existing materials they intend to retain, and confirm you have a perpetual, irrevocable licence to use those components in your product.
If the agency uses a "work for hire" framework (more common in US-influenced contracts), verify that this is explicitly stated and that it covers all contributors, including subcontractors. A subcontractor who wasn't party to the work-for-hire agreement can create an IP gap that surfaces years later.
For founders building SaaS platforms or products they intend to sell or raise investment on, clean IP ownership is not optional. Investors and acquirers will conduct IP due diligence. Ambiguous ownership clauses will either kill a deal or require expensive legal remediation.
The second term to scrutinise is how the contract defines what the agency is actually building. Contracts that reference "the project" or "the software described in the proposal" without attaching a detailed specification are leaving the definition of done entirely open to interpretation.
Ambiguous deliverable definitions create two problems for clients. First, they make it easy for an agency to argue that a feature you expected is out of scope. Second, they make it difficult to hold an agency accountable for quality, because there's no agreed standard against which to measure the output.
A contract that says "a responsive e-commerce website with product listings and checkout functionality" could describe a £5,000 build or a £50,000 one. Without a detailed specification attached as a contract exhibit, you have no legal basis to dispute what was delivered.
Before signing, ensure the contract references a detailed scope document, sometimes called a Statement of Work or Technical Specification, as a binding exhibit. This document should list every feature, user flow, integration, and acceptance criterion. It should define what "complete" means for each deliverable.
If the agency hasn't produced a detailed scope document before asking you to sign, that is a red flag. A professional agency should be able to specify what they're building before they build it. Our post on how to define project scope covers the nine elements every specification should include, use it as a checklist before you sign anything.
Fixed-price contracts feel safe. They're not, if the change request clause is poorly drafted. This is the mechanism by which a fixed-price engagement quietly becomes a time-and-materials project, and it's one of the most common sources of budget overruns for European founders.
Most development contracts include a change request process: if the client requests something outside the agreed scope, the agency raises a change request with a cost estimate, and the client approves it before work begins. In principle, this is reasonable. In practice, the problems arise in the details.
Contracts that specify change requests will be priced at the agency's "standard hourly rate" without defining what that rate is create open-ended exposure. Contracts that allow the agency to determine unilaterally whether something constitutes a change request, rather than a defect or a scope clarification, give the agency significant leverage. A German SaaS founder we spoke with found that nearly 30% of his final invoice consisted of change requests for features he believed were included in the original scope. The contract gave him no mechanism to dispute the classification.
Negotiate three specific protections into the change request clause. First, define the hourly rate for change requests explicitly in the contract, not by reference to a rate card that can change. Second, require written approval from you before any change request work begins; verbal approvals should be explicitly excluded. Third, establish a clear definition of what constitutes a change request versus a defect fix or a scope clarification, so that the agency cannot reclassify bugs as billable changes.
For larger projects, consider negotiating a change request budget, a fixed pool of hours included in the contract price for minor adjustments, with a defined process for anything beyond that threshold.
Software rarely launches without defects. The question is not whether bugs will appear, but who is responsible for fixing them and for how long. The warranty clause in your development contract determines the answer.
Many agency contracts include a warranty period of 30 days post-launch. Within that window, the agency will fix defects at no charge. After 30 days, any fix is billable. For complex web applications or mobile apps, 30 days is often not enough time to surface all defects, particularly those that only appear under real user load or in edge-case scenarios.
The warranty clause also needs to define what counts as a defect. A defect is a failure of the software to perform as specified in the agreed scope. A new feature request is not a defect. Without a clear definition, agencies can reclassify legitimate bugs as feature requests and charge for fixes that should be covered under warranty. For a detailed look at what post-launch support typically costs, our website maintenance costs breakdown covers the full picture.
Push for a minimum 90-day warranty period for web applications and 120 days for mobile apps, where the testing cycle is longer and platform-specific issues can take time to surface. Ensure the contract defines "defect" by reference to the agreed specification, not by the agency's subjective assessment. Include a clear escalation process for disputed defect classifications, so you have a mechanism to challenge a reclassification without immediately resorting to legal action.
Also check whether the warranty covers performance defects, not just functional ones. A page that loads in eight seconds is technically functional but practically broken. If performance benchmarks were part of the original brief, they should be part of the warranty scope.
Every professional services contract includes a liability cap, a ceiling on the amount the agency can be held responsible for, regardless of the damage caused. In most agency contracts, that cap is set at the total contract value. For a £30,000 development project, the agency's maximum liability is £30,000.
Consider what a serious failure could actually cost you. A data breach on a platform handling personal data of EU or UK residents triggers GDPR obligations: notification costs, regulatory investigation, potential fines, and reputational damage. A payment processing failure on an e-commerce platform means lost revenue, chargebacks, and customer trust damage. In either scenario, the actual loss could far exceed the contract value, but the agency's liability is capped at what you paid them.
Most contracts also include a consequential loss exclusion, which means the agency is not liable for lost profits, lost business, or indirect losses even within the cap. For a SaaS platform where downtime directly translates to churn, this exclusion can be devastating.
Negotiate separate, higher liability caps for specific categories of failure. Data breaches and GDPR violations should carry a higher cap than general defects, given the regulatory exposure involved. If the agency is handling payment processing or integrating with financial APIs, consider whether the standard cap is adequate given the transaction volumes involved.
You are unlikely to remove the consequential loss exclusion entirely, it is standard practice and most agencies will not sign a contract without it. But you can negotiate carve-outs for gross negligence and wilful misconduct, which ensures the agency cannot hide behind the exclusion if they have behaved recklessly.
Modern software is not built from scratch. Every web application or mobile app contains dozens of third-party components: open-source libraries, paid APIs, SaaS tools, and cloud services. Your development contract needs to address who is responsible for these dependencies, both during development and after handover.
Open-source licences are not all the same. Some (MIT, Apache 2.0) are permissive and impose minimal obligations. Others (GPL, AGPL) require that any software incorporating them also be released under the same licence, which can create serious problems for proprietary SaaS products. If your agency uses GPL-licensed components in your codebase without disclosing this, you may have an open-source licence obligation you didn't know about.
Third-party APIs and SaaS tools embedded in your build also carry ongoing cost and compliance obligations. If the agency integrates a paid API without documenting it, you may discover unexpected subscription costs after handover. If they use a data processing tool that doesn't meet GDPR requirements, you inherit the compliance risk. For a deeper look at how API integrations work and what they involve, our API integration FAQ covers the key questions in plain language.
Require the agency to provide a full dependency manifest as part of the project handover, a complete list of all third-party libraries, APIs, and tools used in the build, along with their licence types and any ongoing cost obligations. This should be a contractual deliverable, not an optional extra.
For GDPR compliance, ensure the contract specifies that all third-party tools used in the build must meet EU or UK data protection standards, and that the agency is responsible for any compliance failures arising from tools they selected. If the agency acts as a data processor on your behalf during development, a Data Processing Agreement (DPA) should be included as a contract exhibit.
No founder signs a development contract expecting to terminate it early. But relationships break down, agencies miss milestones, and business circumstances change. The termination clause determines what you walk away with if that happens, and in many standard contracts, the answer is less than you'd expect.
Agencies that host your codebase on their own repositories, manage your cloud infrastructure, or hold your domain credentials have significant leverage in a termination scenario. Contracts that don't specify handover obligations, or that tie handover to the resolution of billing disputes, can leave you locked out of your own product while a dispute is ongoing.
Work-in-progress ownership is another gap. If you terminate a project at the 60% mark, what do you own? Many contracts are silent on this point, which means the agency retains the IP for all work completed until final payment is made. If the termination is triggered by the agency's failure to deliver, you may find yourself in a position where you've paid for work you can't access.
Negotiate staged IP transfer, ownership of completed work transfers to you at each milestone payment, not only at final payment. This ensures that if the relationship ends mid-project, you own what you've paid for. Require the contract to specify that repository access, hosting credentials, and domain access must be transferred to you within a defined timeframe (typically 5-10 business days) upon termination, regardless of whether billing disputes are ongoing.
Also ensure the contract specifies what documentation the agency must provide on handover: codebase documentation, deployment instructions, environment configuration, and a list of all credentials and access points. Without this, even a clean handover can leave your next agency spending weeks reverse-engineering what was built. Our post on development contract essentials covers the full set of clauses worth reviewing before you sign.
Raising contract terms before signing is not adversarial. It is professional due diligence, and any agency that has worked with experienced clients will expect it. The way you frame these conversations matters, though.
Approach contract negotiation as something you do with every professional services provider, not as a signal that you distrust this particular agency. Most of the terms above are standard asks that experienced agencies have addressed before. Framing your requests as "our standard requirements for any development engagement" removes the personal element and makes the conversation easier for both sides.
IP ownership and repository access are non-negotiable for any serious build. Warranty period length and change request rate definitions are standard negotiating points that most agencies will accommodate. Liability cap increases for GDPR-specific failures are a harder ask but worth raising, particularly if you're building a platform that handles significant personal data.
For projects above £50,000, or for any build that will handle personal data, payment information, or form the core of a product you intend to raise investment on, involve a solicitor before signing. In the UK, a commercial solicitor with technology experience can review a development contract in two to four hours. In Germany, a Rechtsanwalt specialising in IT-Vertragsrecht can do the same. The cost is modest relative to the contract value and the risk.
A professional agency will engage with these requests constructively. They may push back on specific points, particularly liability caps and warranty periods, but they will do so with reasoned explanations, not blanket refusals. An agency that refuses to discuss any contract terms, or that treats negotiation as a sign of bad faith, is telling you something important about how they handle disputes when they arise.
At Axire Infotech, we work with founders across the UK, Ireland, Germany, Belgium, and the Netherlands who have been through difficult agency experiences. Our contracts are designed to be transparent on all seven of the terms above, because we believe that clear agreements protect both sides. You can view our project portfolio to see the kind of work we deliver, and explore our full range of services to understand how we structure engagements.
No. Under the Copyright, Designs and Patents Act 1988, copyright in software belongs to the author, the person or company that created it, unless there is a written agreement to the contrary. If you commission software from an agency, you do not automatically own the copyright. You need an explicit IP assignment clause in your contract. This is one of the most common misconceptions among UK founders.
Technically, yes, both parties can agree to amend a contract at any time. In practice, your negotiating position is significantly weaker after signing, particularly once work has begun. The time to negotiate is before you sign, when you have the option to walk away. Once a project is underway, the switching costs make it much harder to push back on unfavourable terms.
A minimum viable development contract should cover: IP ownership and assignment, a detailed scope of work as an exhibit, payment terms and milestones, change request process and pricing, warranty period and defect definitions, liability cap and exclusions, termination rights and handover obligations, and confidentiality provisions. For a comprehensive checklist, our post on development contract essentials covers all eleven critical clauses in detail.
A 90-day warranty period is a reasonable minimum for most web applications. For complex platforms with significant backend logic, payment integrations, or high user volumes, 120 days is more appropriate. Mobile apps should carry at least 90-120 days given the additional complexity of platform-specific testing. Anything below 30 days is inadequate for any non-trivial build.
If your agency processes personal data on your behalf during development, for example, by accessing a staging environment with real user data, they are acting as a data processor under GDPR. This requires a Data Processing Agreement (DPA) between you and the agency. The DPA should specify what data is processed, for what purpose, and what security measures are in place. Failing to have a DPA in place is a GDPR compliance gap that sits with you as the data controller, not the agency. This applies to both UK GDPR and EU GDPR, depending on where your users are located.
A poorly negotiated development contract is not just a legal risk, it is a business risk. The seven terms above are the ones that most frequently turn promising agency relationships into expensive disputes. Understanding them before you sign puts you in a fundamentally stronger position, regardless of which agency you choose to work with.
If you're evaluating development partners and want to understand how a well-structured engagement should work, from contract terms to delivery process, our team at Axire Infotech is happy to walk you through our approach. We work with founders and SMBs across Europe building everything from MVPs to full SaaS platforms, and we're used to working with clients who ask the right questions before they commit.
Explore our web development services, app development capabilities, or UI/UX design process to see how we approach each type of engagement. When you're ready to talk specifics, get in touch with our team, we'll give you a straight answer on scope, timeline, and what a fair contract for your project should look like.
Let's discuss your project and create something amazing together.
