Sebastian Dietrich is not a typical conference speaker. He’s a certified court expert in software – one of the people judges call when a software project ends in a lawsuit. He’s seen the inside of disputes most developers never want to imagine.
The case he opened with is instructive. A typical agile project: a vendor wins a tender, presents their methodology, tells the client to appoint a Product Owner, and starts building. The design firm delivers a month late, the deadline slips, and the vendor flags the problem two months in advance. So far, so familiar.
Then the January invoice doesn’t get paid.
The client was unhappy. They commissioned their own audit – from the design firm, which had a competing interest. The verdict: unusable architecture, poor code, badly documented, needs to be rebuilt from scratch. A court expert confirmed the finding. Then came the lawsuit: €1.5 million in repayment, plus another €1.5 million in damages for the cost of restarting the whole process.
That’s the context in which Sebastian makes his argument. Not theory. Cases he has personally worked on, this year.
Most people on agile projects have never read the contract. Not the Scrum Master. Not the Product Owner. Not the developers. They don’t know what was actually promised – and that gap is where disputes are born.
The first mistake: contracts written to impress, not to protect. Sebastian is blunt – a contract full of superlatives is a gift to opposing counsel. “Best quality” means zero defects to a judge. “Industry-leading processes” sets a standard no team can meet. Write for the bad times, not the good ones.
The second mistake: assuming the label matches the legal reality. Writing “service contract (time and material)” at the top of a document does not make it a service contract. Austrian courts – confirmed at Supreme Court level – routinely classify software development as a Werkvertrag: a work contract in which the vendor is ultimately responsible for delivering something that functions. Even if the scope was unclear at the start. Even if payment was incremental.
The practical implication: if your contract doesn’t explicitly establish that the client is directing the work, that the scope is defined by the client’s instructions, and that you have no control over what ends up in the product – you may be liable for outcomes you never agreed to.
Key language to include: that the client is giving instructions (weisungsgebunden), that you have no sovereignty over the content of the software (keine Hoheit über den Inhalt), and that what is to be built is not fixed at the start. These are not comfortable words. But they are the words that matter in court.
If a contract says nothing about quality, a judge defaults to recognised standards of the trade – which in software means ISO norms. Sebastian has read them. His assessment: catastrophic. They describe processes, not outcomes. They don’t say how good anything needs to be. And many include clauses that allow deviations as long as they’re documented, which means they effectively have no teeth at all.
“State of the art” sounds reassuring. It is not. In Austrian law, the phrase appears in more than 250 statutes, and it carries a specific legal meaning: based on scientific evidence, progressive, and proven to be efficient and effective. Almost no standard engineering practice – not Scrum, not Kanban, not pair programming, not any particular framework – has been validated by peer-reviewed scientific study. Which means “we built this to state of the art” is a claim most teams cannot defend.
Sebastian’s advice: define quality yourself, in the contract, with measurable terms. Not vague commitments – actual numbers. Architecture rules (e.g. maximum depth of component nesting, dependency constraints). Mandatory code review requirements. And critically: residual defect rates.
Sebastian’s most practical recommendation is one most development teams have never heard of: the residual defect rate.
The logic is simple. Research gives us reasonable estimates for how many bugs developers introduce per 1,000 lines of code, and how many are caught by each type of testing. From your bug tracking system, you can see how many have been found. Which means you can calculate – roughly – how many are still hiding in production.
The thresholds that matter legally: 2 defects per 1,000 lines of code for standard software. 0.5 defects per 1,000 lines for anything safety-critical – which includes software handling personal data under GDPR. To reach 0.5, you need every testing technique working together: unit tests, integration tests, end-to-end tests, performance tests, and – most importantly – code reviews.
Code reviews, Sebastian argues, are the single highest-leverage testing activity available. In any given time window, reviews find and prevent more defects than automated testing alone. If you have ten hours to improve quality, spend them on reviews – not on increasing coverage metrics that can be gamed without improving the underlying code.
One of Sebastian’s sharpest observations has nothing to do with law. It’s about expectations.
The customer doesn’t want a Product Owner role. They don’t want sprint reviews or backlog refinement sessions. They want their problem solved – on time, within budget. They came to a software firm because they expect expertise, not a process for co-creating their own requirements.
The uncomfortable truth: asking a client to define their own product is setting them up to be a bad Product Owner, and setting you up to be blamed when the result doesn’t match what they actually needed. The firms that avoid this trap are the ones who lead with domain expertise – who say “we build the best school software” rather than “we build software using agile processes.” The method is irrelevant to the client. The outcome is everything.
Sebastian closes with a number that should concern everyone in the industry. The cost of defective software worldwide – already before AI entered the picture – is large enough that it could, by his calculation, fund meaningful action on global hunger through 2050 or on climate change. Agile methods have not improved this. Shift-left testing has, in practice, often reduced the rigour of late-stage testing without replacing it with something equally robust.
AI-generated code makes this harder, not easier. Sebastian’s description of current code-generation tools – a highly confident junior developer who makes frequent mistakes and defends every one of them – will land differently depending on how much you’ve used them. But his underlying point holds: the question of who tests the testers, who validates the output, remains unanswered in most teams today.
