A software contract is either a contract for work, which owes a finished result, or a contract for services, which owes the service itself. In court, agile software contracts often count as contracts for work, because the backlog defines what is owed. A few targeted clauses prevent liability risks that can drive a company into bankruptcy.
Key Takeaways
- In court, software built with agile methods almost always counts as a contract for work, even if the document is titled “service contract”, because judges look at what both parties intended, not at the heading.
- Freelancers are liable for defects in their work for up to two years without extra pay, unless the contract says otherwise.
- If you don’t meet your duty to warn and never tell the client that software defects can’t be avoided, you risk having to pay back the entire fee.
- The state of the art is judged at the time the product is handed over, not when the project was commissioned, which has serious technical and legal consequences for long projects.
- AI-based testing methods don’t count as state of the art yet, because scientific studies on their effectiveness are still missing.
Freelancers Owe a Result, Not an Effort
Legally, a freelancer owes something fundamentally different from an employee, and every software contract rests on that difference. A self-employed person owes a result, not just the time and effort put in. It isn’t enough to have spent many hours on a project. The project has to succeed.
That holds for a software developer just as much as for a tiler or a carpenter. If the tiler spends five hours laying tiles and something breaks, he has to fix it without extra pay. Applied to software, a freelancer who builds bugs into a system has no legal claim to be paid for fixing them.
In practice it works differently. Freelancers usually do get paid for fixing their own bugs. But that claim only exists if the contract says so. Without such a clause, bug fixing falls under the warranty, and you pay for it yourself.
How Freelancers Protect Themselves in a Software Contract
Write into the contract that defect-free software isn’t technically possible, and that fixing defects isn’t covered by the warranty but is billed as a regular service. That one sentence shifts the logic in your favor.
This applies to developers and testers alike. A client who hires a tester expects the tester to find the bugs. If the tester finds only 4,520 out of 4,521, liability becomes an issue, especially if damage results. Here, too, it helps to state clearly that no human being can find every defect.
One practical tip: never promise in your marketing that you’ll find all the bugs. Superlatives like that will work against you in court later.
Liability can be split up. You can’t exclude gross negligence. Slight negligence, meaning the everyday slips that happen to everyone, you can exclude in the contract.
How Long You’re Liable If Nothing Is Agreed
Unless something else is agreed, a two-year warranty period applies in Germany and Austria. In B2B, that period can be shortened, but not below six or twelve months.
Attempts to push the warranty lower or to exclude gross negligence will fail. If you write only three months of warranty and an exclusion of gross negligence into the contract, the judge throws that clause out. It’s treated as if it weren’t there, and the two years still apply.
Liability goes beyond the warranty. It covers not just fixing a defect but the cost of the damage it caused. With large software, that can bankrupt a freelancer much faster than any repair work.
Duty to Warn: No Warning, No Money
A freelancer who fails in the duty to warn and inform can lose the entire fee. If you never tell a client that software can contain defects, that omission can be used against you later, even after the work is done.
The client can then argue they were never told the software might contain bugs and demand every cent back. A single warning clause in the contract is enough to prevent that.
How strictly the duty to warn applies depends on the buyer’s experience. A client with an IT background is held to a different standard than one who has never commissioned software before. What counts is what the buyer can reasonably expect. Everyone expects a carpenter’s table not to collapse when you stand on it.
In practice, this rarely hits freelancers hard, because they’re usually not the first people on a well-established project. It gets tricky with small projects for clients without IT experience. There, the warning has to be in the contract.
How to Get a Contract Change Accepted Easily
Agencies and intermediaries often hand freelancers ready-made contracts without knowing the legal fine print behind them. They just pass the paperwork along. That makes things easier than many people think.
Instead of arguing over individual clauses, change the contract yourself, add your own clause and send it back signed. Experience shows that a signed document goes through more smoothly than an open negotiation over individual clauses.
Agile Software Contracts: Why the Heading Decides Nothing
The most dangerous mistake in agile projects is about the difference between a contract for work and a contract for services. At the core, there are only these two types. Under a contract for work, you owe a finished piece of work, defined in advance by a specification. Under a contract for services, you owe the service itself.
With custom software built the agile way, nobody knows at the start what the software will do in the end. That’s exactly what makes the legal classification hard. Many contracts carry the heading “service contract” and bill by the hour, on the assumption that this settles it.
It doesn’t count in court. Neither the heading nor hourly billing makes a contract for services. If the contract says that specific software is to be developed, it’s a contract for work. What decides is the intent of the contract, as a client without technical expertise would read it. And that client typically reads an agile software contract as a contract for work.
The Backlog Becomes What You Owe
If an agile contract is treated as a contract for work, you owe the defined content in full. And the only thing in an agile project that defines what the software is supposed to do is the backlog.
That leads to an uncomfortable conclusion: the software only counts as finished once the entire backlog is done. That includes the stories and features the product owner added two days ago. And in many projects, the product owner comes from the client.
It’s legally fine for the project scope to emerge over time. But that very mechanism is what tips a project into a contract for work, where you owe the whole thing.
One real case shows how explosive this is. A client kept adding new features to the backlog, fully in the agile spirit. At some point he stopped paying and sued to have all payments reversed, arguing that the backlog was still full, so the software wasn’t finished. Several million euros were at stake. For a small company, a ruling like that means bankruptcy.
Clauses That Turn a Contract for Work into a Contract for Services
A few precise wordings decide whether a court sees a contract as one for services or one for work. These points belong in it:
- The subject matter of the contract is not clearly defined at the start.
- The client works on the project jointly and can reprioritize features at any time.
- The client is closely involved in the process and gives instructions.
- The focus is on delivering the service, not on the finished software product.
- The contractor is not responsible for the project’s success, but for the quality of the service delivered.
The point about instructions is delicate, because it touches on the question of bogus self-employment. Two legal logics collide here, and the wording needs care.
These clauses are basically the agile idea in writing. They record that you don’t owe the project’s success, but the joint work on the product.
What “State of the Art” Really Means in a Software Contract
Almost no contract says what technical quality actually means. Often all you find is the boilerplate “corresponds to the state of the art.” In a dispute, an expert witness decides what that means, and the expert’s view depends heavily on what the contract says.
Be careful with superlatives. If the contract says “best quality” anywhere, a court reads that as “no defects.” Wording like that increases your liability instead of limiting it.
Instead of pinning down the state of the art in detail, agree on a process. Write into the contract that, as the project goes on, you and the client will decide according to defined rules what counts as state of the art. Then the expert, the judge and the opposing lawyer have an agreed process in hand that they only need to check for plausibility.
If that process defines, for example, that 30 percent test coverage is enough, that’s binding. Without such a definition, an expert shows up and demands 80 percent coverage, a figure that’s questionable anyway.
How an Expert Judges the State of the Art
A single technique counts as state of the art when the scientific literature backs it. The assessment happens in steps. First: is there any literature on the technique at all? Then: does that literature show the technique is more efficient and more effective than existing alternatives?
Mob programming versus pair programming shows the yardstick. There are scientific studies on pair programming showing it’s more efficient and effective than programming alone. For mob programming, there’s no clear scientific evidence of higher efficiency or effectiveness.
A method is still allowed without studies behind it. But if you want to use mob programming, gather experience that goes beyond gut feeling: measure times, compare two teams on the same task. Documented decisions, for example in Architecture Decision Records, give every technique you use a traceable justification.
Residual Defect Rate Instead of Code Coverage
When the question is whether an end product is usable, what counts isn’t the code coverage of the automated tests but the residual defect rate. The client rarely cares whether they paid too much. They care whether they can use the software at all.
The residual defect rate can be calculated. Above 0.5 bugs per 1,000 lines of code, the software counts as unfinished. For large software, the absolute number is naturally higher than for small software.
Reality is sobering. According to the literature, the average residual defect rate is much higher, at 20 to 30 bugs per 1,000 lines of code. So most software in use doesn’t meet the state of the art when it comes to residual defects.
When a Dispute Turns to the Techniques Used
A project’s techniques usually only get examined in a second step. First, an expert report settles whether the software is ready for acceptance. Only if it isn’t does the question of fault come up: was it poor technique in testing or in the code?
Then it matters whether everything was bet on a single approach. In testing, relying only on end-to-end tests is a bad idea. Several techniques side by side speak for careful work. A single approach speaks against it.
AI in Testing: Thin Legal Ice for Now
If you have software tested by artificial intelligence, you’re on shaky legal ground. There are almost no scientific studies on whether AI in software development and testing is state of the art.
The argument “good coverage thanks to AI-generated tests” doesn’t help, then. As long as the studies are missing, you can’t prove that using AI is state of the art.
State of the art and science are related, but they aren’t the same thing. As long as the science on a new method is vague, the old state of the art still applies. Only when studies show that a method is at least as good in quality and productivity does it automatically become the new state of the art.
The yardstick keeps moving. What is state of the art when a project starts may no longer be at the end. What counts is the state of the art at the time the product is handed over, not when it was ordered. On long projects, that can make a real difference.
Contracts Are Written for an Enemy, Not a Friend
A contract isn’t there to record how you work together. It’s there for when things go wrong.
“You always write a contract for your opponent. So always keep this in mind: the contract isn’t written for a friend, but for an enemy.”
(Sebastian Dietrich)
Even if the person across the table is nice today, a new lawyer could join the company tomorrow and change everything. That perspective changes what you look for when you read a contract.
The effort to protect yourself is small compared with the risk. In one real case where a company’s survival hangs by a thread, two sentences in a contract of hundreds would have been enough. There were pages on how great agile software development is. The crucial clauses were missing.
Frequently Asked Questions
Is a freelancer required to fix bugs in their own software for free?
Without a suitable contractual clause, yes. Self-employed individuals are legally obligated to deliver a successful result, not merely to exert effort, similar to a tiler who must repair damage without additional payment. Bug fixes then fall under the warranty and are therefore at the freelancer’s own expense. In practice, billing is usually handled differently, but this obligation only arises through an explicit agreement in the contract.
How long are you liable for software bugs if the contract doesn’t specify anything?
In Germany and Austria, a two-year warranty applies. In the B2B sector, this period can be shortened, but not to less than six or twelve months. Anyone who nevertheless specifies three months or excludes gross negligence will have the clause ruled invalid in court: it is deemed null and void, and the two-year warranty period continues to apply. Minor negligence, on the other hand, can be excluded.
What happens if a client was never made aware of potential software defects?
The client can demand a full refund of the fee paid, even after the work has been completed, because the duty to warn and inform was violated. How strictly this standard is applied depends on the client’s experience: Different rules apply to a client from the IT sector than to someone who has never had software developed before. A single warning clause in the contract is sufficient for protection.
Is the heading “Service Contract” enough to avoid a contract for work?
No. Neither the heading nor billing by the hour determines the type of contract. Courts assess the intent of the contract based on how a non-expert client would understand it. If the contract specifies that a particular piece of software is to be developed, it is a contract for work. Custom software developed using agile methods therefore almost always falls into this category.
What risk arises if an agile project is classified as a contract for work?
In that case, you are obligated to fully implement the backlog, as it is the only thing that defines the scope of work. This includes even user stories that the client’s product owner added two days ago. In one case, a client suspended payments and sued for rescission, arguing that the backlog was still full. Several million euros were at stake.
How can “state of the art” be defined concretely in the contract?
Instead of specifying technical details, agree on a process: As the project progresses, you and the client will jointly decide, according to established rules, what constitutes the state of the art. If, for example, you specify a test coverage of 30 percent, that is binding. Without such a specification, an expert might demand 80 percent coverage. Superlatives like “best quality” are interpreted by a court as meaning “no errors.”
At what residual error rate is software considered incomplete?
Software is considered incomplete if it has more than 0.5 bugs per 1,000 lines of code. When determining whether a final product is usable, this metric is more important than the code coverage of automated tests. According to the literature, however, the average is 20 to 30 bugs per 1,000 lines of code. Most software in use therefore does not meet the state of the art.
Is the use of AI in testing considered state of the art?
No. There is a lack of scientific studies on whether AI in development and testing meets the state of the art, which is why the argument that AI-generated tests provide good coverage does not hold up. As long as the scientific evidence remains vague, the old state of the art continues to apply. In any case, what matters is the state of the art at the time of product handover, not at the time the project was commissioned.
