Twenty minutes. That is all it takes for an experienced opposing counsel to dismantle a carelessly prepared software expert opinion. I have watched it happen. Here are the three failures that repeat themselves.
The context: when an opinion reaches the courtroom
When a litigation partner at a large firm calls me after “our expert was destroyed in cross-examination”, the conversation always starts with the same description: “He knew the material. He had years in the industry. But fifteen minutes with opposing counsel — everything fell apart.”
The problem was not the expert’s technical knowledge. The problem was the opinion itself.
A software expert opinion submitted to an Israeli court passes through two non-technical filters: the first is the judge, who must understand and accept the analysis as the basis for a factual finding; the second is opposing counsel, whose sole task is to find the fracture point in the opinion and widen it. A technically excellent expert who writes a technically excellent opinion — but not one calibrated for these two filters — will not survive cross-examination.
First failure: mixing findings with opinions
The most common failure is the expert presenting opinions as findings.
”The system was unfit for use” — that is an opinion. “Testing 47 edge cases defined in the original specification showed 31 failures; a failure rate of 66%” — that is a finding you can stand behind under cross-examination.
An experienced opposing counsel looks for the moment the expert said something not grounded in direct examination. Once found, they work backwards from it to the rest of the opinion: “If you did not test this yourself, perhaps you also did not test…” — and that is where credibility breaks.
Working rule: every claim in the opinion is accompanied by its source marker — code line X, log line Y, version document Z. No marker, no claim.
Second failure: a methodology that cannot be reproduced
A software opinion collapses under cross-examination when opposing counsel asks: “How did you arrive at this result?” — and the expert cannot describe it step by step.
I saw this in a mid-scale Israeli SaaS dispute. The expert for one of the parties drew conclusions from a performance analysis — but did not document the test environment, did not specify the tool versions used, and did not preserve the raw data. When asked to explain how he arrived at the central figure in the opinion, he was forced to say “based on my professional experience” — a phrasing that invites experienced counsel to ask precisely how many years of experience are required to obtain a different result.
The dispute ended in a settlement on terms that did not reflect the position of the party that retained the expert. The settlement came after the opinion was damaged, not before.
Working rule: every methodology is documented such that another expert, given the same materials, would reach the same result — or identify precisely where they disagree. Reproducibility is a shield, not an indulgence.
Third failure: an opinion written for a technical reader, not for a judge
The third failure is the most sophisticated: an opinion that is technically correct — but written in a language only an engineer will understand.
Judges in Israel, even in district courts handling complex commercial disputes, are not software engineers. An opinion that assumes baseline knowledge of computer architecture, network protocols, or the names of specific tools places the judge in a position where they must take things on faith that they do not understand. That is an uncomfortable position, and it causes judges to discount opinions that seem to them like a “black box.”
Opposing counsel exploits this: “Could you describe this concept in non-technical language?” — and if the expert cannot, they lose the room.
Working rule: every non-standard technical concept is explained in a short paragraph in the body of the opinion, without sacrificing precision. The explanation is written for the judge, not for technical colleagues.
What survives cross-examination
An opinion survives cross-examination when it answers three questions before they are asked:
- What exactly did you examine? — list of materials, working environment, tools, and versions.
- How did you reach the finding? — a step-by-step description a judge can read and follow.
- What did you not examine, and why? — defining the opinion’s boundaries openly is more protective than silence.
An opinion built on these principles works in your client’s favour not only when filed — but also when opposing counsel is searching for the crack that will break it.
Identifying details have been changed; all scenarios described reflect patterns from actual engagements.
If you are about to appoint a software expert for a case, Tech Expert Opinion — two-week turnaround explains how we build opinions that hold up.