How pre-litigation technical discovery clarifies facts before positions harden, informs strategy before costs escalate, and points to settlement before proceedings issue.
Most of the published guidance on instructing a software expert witness focuses on the CPR Part 35 report: what it must contain, how it survives cross-examination, when the court will admit it. The work that decides whether the report is needed, what it should cover, and what it is likely to find happens earlier, and gets discussed less.
This earlier work is early technical assessment. It costs a fraction of the formal report it might inform, and often determines whether one is needed at all. Solicitors at the pre-action stage of a software or IT dispute are typically the ones commissioning it, with the work producing a written scoping memo for the file.
This guide documents how I approach the scoping work. It is written for solicitors at the pre-action stage who are deciding whether to commission expert work and want to understand what a rigorous early assessment looks like (this guide should be read alongside the guide for instructing solicitors). The scoping memo is informal advice to the instructing solicitor, not court-compliant expert evidence under CPR Part 35. However, the independence that makes the eventual report carry weight is the same independence that shapes the scoping work; the expert’s stance does not change between the two.
What an Early Assessment Produces
The memo runs to six or twelve pages, drawn from the documentation and code available before proceedings commence, and covers four things.
First, the technical questions the dispute turns on. Most software disputes look like a single failure from the outside but resolve into three or four distinct technical questions when examined: was the system fit for the contractual purpose, was it built to the standards the contract implied, were the parties’ respective obligations discharged in practice, and where did the chain of cause and effect run. Naming the questions clearly is most of the work.
Second, the early indications on each question. Not findings, not opinions under CPR Part 35; those come later if the matter proceeds. Indications are what the available evidence appears to show, where the gaps are, and what would need to be examined to move from indication to opinion.
Third, a scope-and-cost view of what a full expert report would cover, against the proportionality test in CPR 35.4(2). This is the section solicitors use most often. It frames the engagement against the dispute’s value, the issues in play, and the procedural stage.
Fourth, evidence-preservation guidance where it is needed. In software disputes, evidence degrades quickly. Emails get deleted, system access is revoked when staff move on, deployment logs roll off, source control histories get pruned. Naming what to preserve, and when, costs nothing at the scoping stage and saves substantial recovery work later.
What the Engineering Examination Looks At
The evidence base for an early assessment is a triangle: code, project artefacts, and contract. Each tells the others’ story differently. The code shows what was built. The artefacts show what was decided and signed off. The contract shows what was supposed to be delivered. The dispute usually lives in the gaps between the three.
On the code side: the source repository history (commits, branches, merge points, signed-off releases), the deployment pipeline (CI/CD configuration, build logs, deployment history), the defect tracker (raised, triaged, resolved, deferred), the test suites and their coverage, and static-analysis output where it exists. Code quality is assessed against ISO/IEC 25010 sub-characteristics where they apply (functional suitability, reliability, maintainability), set against recognised industry-standard benchmarks rather than a generic standard of “good code”.
On the project-artefact side: the requirements documentation, the design artefacts, the project plans and their revisions, the change-control records, the user acceptance test reports and sign-offs, the steering-group minutes, and the email and instant-message record of decisions taken outside formal documentation. The SWEBOK knowledge areas (Requirements Engineering, Software Configuration Management, Software Quality, Software Engineering Process) give the taxonomy for what should exist; absence is itself evidence.
On the contract side: the technical schedules, the acceptance criteria, the service-level commitments, and the change-control procedure. The contract sets the standard by which the code and the artefacts are judged.
In practice, the early-assessment work is mostly about getting access to enough of each to form indications without yet doing the deep analytical work a full report would require. The assessment names what was reviewed, what was not, and why.
When to Instruct and How Early Assessment Fits Procedural Staging
The simplest answer is: as early as the question of expert evidence arises. The fuller answer depends on which stage of dispute you are at.
Before Letter of Claim. Most useful here. The assessment informs whether to send the Letter at all, what to put in it, and what scope of expert evidence to anticipate. No court permission is required at this stage. Early scoping is informal advice to the instructing solicitor, not yet expert evidence within the meaning of CPR Part 35. Cost is typically in the low thousands, well within the proportionality test, and small enough that the cost itself rarely drives the decision.
During the Pre-Action Protocol period. Useful for responding to a Letter of Claim, for shaping the Letter of Response, and for assessing whether the technical case being made against the client holds together. There is no specific Pre-Action Protocol for software disputes, but the Practice Direction on Pre-Action Conduct and Protocols applies generally, and the Technology and Construction Court’s protocol applies to disputes within its jurisdiction.
After proceedings commence. Permission to adduce expert evidence is governed by CPR 35.4 and is now an active question. The scoping work done earlier feeds the permission application, covering both the scope and the cost estimate. The transition from scoping memo to formal CPR Part 35 report begins here.
Post-disclosure. The disclosure exercise often reveals evidence (emails, change requests, sign-offs) that materially shifts the technical picture. A second scoping pass after disclosure is sometimes warranted, particularly where the early-stage indications looked different from what disclosure now suggests.
Pre-trial. Outside the scope of early assessment. By this stage the CPR Part 35 report is final and the work is in joint statements, expert meetings, and trial preparation.
The cost of waiting is asymmetric. Waiting until the need is obvious means evidence has degraded, positions have hardened, and legal costs have already accrued. Early assessment is cheaper than late assessment and more complete because the evidence is still there to examine.
The Independence Requirement
The expert’s overriding duty is to the court, not to the instructing party. That duty is set out in CPR 35.3 and elaborated in the Ikarian Reefer principles, and it is what makes independent expert evidence carry weight at settlement and at trial.
Solicitors meeting this for the first time sometimes find themselves explaining it to a client who has heard “independent” and worried about it. The framing I have found useful is this: a partisan technical report does not survive contact with the other side’s solicitors. Its findings are dismissed as paid-for advocacy, the negotiation reverts to competing narratives, and the technical evidence, which is the strongest part of most software disputes, is lost to the case. An independent report, by contrast, names what is true about both sides. Where it names supplier failures, those findings carry weight precisely because the report has also acknowledged problems on the instructing party’s side. The settlement conversation shifts from “whose consultant is right” to “what the evidence shows”.
This is not a procedural inconvenience to be tolerated. It is what makes the technical evidence useful.
What Assessment Reveals — Three Patterns
Early assessments resolve into one of three shapes. The proportions vary by dispute type, but in my experience all three are common enough that the instructing solicitor should be prepared for any of them.
Clear supplier failure. The assessment finds substantive failures on the supplier’s side: inadequate testing before production deployment, code quality that fails the contractual standard, project-management artefacts the contract required but that do not exist, or design decisions that caused the outcome the client is now complaining about. The scoping memo names the standards engaged, points to the evidence, and frames the scope of a full report. The instructing solicitor proceeds with confidence: the technical case is solid, and the strategic question shifts from liability to quantum, much as it does in a full failed software project assessment.
Shared responsibility. More commonly, the assessment finds that both sides contributed. The supplier’s work has identifiable failures, but so does the client’s. Requirements that changed without contractual change control. Sign-offs given for features now claimed to be broken. Decisions taken outside the documented process. The scoping memo names both. This is the most useful of the three patterns even though it rarely feels that way to the client at first; proportional responsibility, named pre-action, lets the solicitor frame settlement realistically rather than discover it during disclosure.
Weak case. The assessment finds the supplier met the standards the contract engaged. The work is not perfect, but it meets the professional baseline. The problems the client is experiencing stem from unclear requirements, infrastructure constraints, or commercial decisions taken outside the contract. The scoping memo says so, honestly. This is the most uncomfortable finding for the client and the most valuable for the case: a weak claim taken to trial is more expensive than a weak claim identified at scoping and either restructured (contractual rather than negligence-based) or dropped.
None of these outcomes is engineered for the client’s comfort. Each follows from what the evidence shows. The pattern that matters is not which outcome occurs, but that the outcome is named clearly and early, before the legal costs of pursuing the wrong strategy have accumulated.