Comprehensive guide to working effectively with software engineering experts in IT disputes; from when to engage them, through evidence gathering and technical assessment, to expert discussions and trial preparation.
When an IT dispute lands on your desk, the technical questions come quickly. Did the supplier follow professional standards? Was the code quality adequate? Was testing appropriate? Were the architectural decisions reasonable? You need answers to advise your client properly, and these aren’t easy questions to answer. You need a technical expert.
This guide is how I work with instructing solicitors through the technical assessment, from first contact to trial. It covers when to engage a software expert, how to gather and frame the evidence, what a Letter of Instruction needs to contain, and what the CPR Part 35 process actually involves. I write it from twenty-plus years of software engineering practice and from the procedural framework I work under as an expert: CPR Part 35, Practice Direction 35, the Civil Justice Council Guidance for Experts (2014), and the Ikarian Reefer duties.
Why Software Disputes Are Different
Software disputes aren’t like construction defects or professional negligence cases, where the problems are visible and the standards reasonably well known. The evidence is scattered across code repositories, email threads, test records, and deployment logs. Determining technical competence requires specialised knowledge that courts don’t possess. Perhaps most importantly, both parties have almost always contributed to the failure in ways that aren’t immediately obvious.
A construction dispute might hinge on whether foundations were built to specification. An IT dispute more commonly involves questions like: Were the requirements adequately defined before development started? Did the supplier follow professional testing standards? Were changes managed through proper control processes? Did the client provide timely access to stakeholders? These questions require examining evidence that exists in multiple sources and understanding professional standards that vary by project type, sector, and contractual requirements.
Courts rely on expert witnesses to bridge this gap. CPR Part 35 exists precisely because technical questions in disputes like these require independent expert assessment. Your role as instructing solicitor is to engage the right expert at the right time, provide them with complete evidence, and work with them through the technical discovery process to expert discussions and potentially trial.
When to Engage a Technical Expert
The timing of expert engagement significantly affects both the value you get and the cost to your client. Experts are typically instructed at three distinct stages, each with different purposes and outcomes.
Pre-Litigation Advisory
Pre-litigation advisory is where I see the strongest leverage. Before you send the Letter of Claim, before your client commits to litigation, you engage an expert to assess what actually happened technically. This isn’t about building a case; it’s about understanding the technical reality so you can advise your client properly.
In my experience, pre-litigation assessments can reveal clear violations of professional standards that strengthen the client’s position dramatically, making settlement discussions very different. They can also reveal uncomfortable findings: both parties contributed to failure, or the supplier actually met professional standards despite the client’s unhappiness. These findings are equally valuable. Better to understand your position before committing to expensive litigation, only to discover weaknesses during disclosure.
Pre-litigation assessment typically takes the form of a technical report that documents findings objectively. It isn’t CPR Part 35 compliant at this stage because you aren’t in litigation, but it can inform Pre-Action Protocol correspondence and settlement discussions. If the case proceeds to litigation, the same expert can provide a CPR Part 35 compliant report that builds on the earlier assessment.
Many clients often resist early engagement, concerned about discovering weaknesses in their position. I explain why engaging an expert early actually protects clients, in an article you can share with them directly.
Post-Proceedings Expert Witness Instruction
Post-proceedings expert witness instruction is the more traditional engagement. Proceedings have been issued, the court has given directions for expert evidence, and you’re instructing under CPR Part 35. I provide a formal report, respond to Part 35 questions, participate in expert discussions, and may give evidence at trial.
This works, but it’s more expensive than early engagement. The technical assessment happens anyway, as you still need to understand what the evidence shows, but now it’s happening under court timelines and formal procedures. If the findings reveal weaknesses you didn’t anticipate, you’re already committed to litigation.
Late Instruction
Late instruction, after disclosure but before trial, is where solicitors often struggle most. They’ve been managing the case based on their client’s narrative and the opponent’s pleadings. Then disclosure reveals technical evidence that doesn’t fit the narrative. Suddenly, they need an expert to interpret code repositories, test records, or deployment logs.
Late instruction is better than no instruction, but it creates time pressure and might limit what the expert can do. Evidence has often degraded: emails deleted, system access revoked, key personnel moved on. Litigation positions have hardened. The expert is trying to understand complex technical issues under compressed timelines.
Why Timing Matters
The pattern across cases is clear: solicitors who engage experts early get better outcomes for their clients. They understand technical reality before positions harden. They avoid pursuing weak claims or defending weak positions. They negotiate settlements from positions of strength. And when cases do proceed to trial, they’re well-prepared with expert evidence that withstands scrutiny.
Choosing a Software Expert Witness
The credentials that matter for a software dispute aren’t the same as those for a construction or clinical dispute, and the choice requires attention before the instruction goes out.
The first question is technical currency. A software expert should still be working with software, not remembering it. Practice changes faster than most disciplines, and an opinion grounded in current engineering work carries weight; a memory-based opinion doesn’t. Ask what the expert has written, deployed, or reviewed recently. Static credentials, however senior, aren’t enough.
The second is procedural training. CPR Part 35, Practice Direction 35, and the Ikarian Reefer duties shape what a compliant report looks like and what an expert is permitted to do at each stage. Formal Bond Solon Expert Witness Training (or an equivalent) is the floor; experience under cross-examination is the next signal. An expert who has never been cross-examined is an unknown quantity at trial.
The third is domain fit. “Software” covers everything from embedded systems through enterprise data platforms to web stacks to AI agents. An expert whose career has been in financial services systems will read a payments platform dispute differently from one whose work has been in healthcare or public-sector procurement. The fit doesn’t need to be exact, but the expert should be able to name the engineering particulars of your domain credibly.
The fourth is fee transparency, which matters under CPR 35.4(2) proportionality. Hidden rates are a risk to the case budget and a flag in their own right. My own published rates and indicative case-stage totals are on the Fees and Charges page; whatever expert you instruct, the equivalent ought to be available before the engagement letter goes out.
The Resources hub contains methodology guides that inform my technical work.
How Evidence Gathering Works
Technical assessment depends entirely on evidence. Without access to what actually happened, experts can’t assess whether professional standards were followed. Evidence gathering is one of the most critical aspects of working with technical experts, and your role as an instructing solicitor is essential to making it work.
The Collaborative Process
Evidence gathering is a collaboration between you, your client, and me. I identify what’s needed based on the technical questions at issue. You facilitate access through the appropriate legal mechanisms. Your client provides what they have and helps navigate their organisation to locate relevant materials.
This is rarely a one-time document dump at the start. Evidence needs often emerge during assessment. I might request specific emails, access to systems, or interviews with technical staff as understanding develops. Sometimes clients don’t realise they have relevant evidence until asked for it. Sometimes the most important evidence is what’s missing: the requirements document that should exist but doesn’t, the test plan that was never created, the risk register that wasn’t maintained.
Don’t Filter Evidence
This is critical: don’t filter evidence for the expert. I need to see everything, including evidence that might not help your case.
The expert’s duty under CPR Part 35 is to the court, not to your client. Complete evidence is needed to form independent opinions. If there’s an email where your client made a decision that contributed to the problem, I need to see it. If a test report shows the supplier conducted testing despite your client’s claim that they didn’t, I need that report as well.
Incomplete evidence leads to an incomplete assessment. When experts discover during disclosure that relevant evidence was withheld, it undermines the assessment and your case. Courts recognise when evidence has been filtered, and it reflects poorly on both the instructing solicitor and the client.
Timing Matters
Evidence degrades over time. Emails get deleted. System access gets revoked. Key personnel leave organisations. Memories fade. The earlier you engage an expert and begin evidence gathering, the more complete your evidence picture will be.
This is one reason early engagement, during Pre-Action Protocol rather than after proceedings, often yields better results. Evidence is fresher, access is easier to arrange, and the expert can identify gaps while there’s still time to address them.
Evidence Access Mechanisms
How evidence is accessed depends on where you are in the dispute process.
Pre-litigation: Your client provides what they have — contracts, emails, documents received during the project. If your client is the party who commissioned the work, they might have limited technical evidence. If your client is the supplier, they’ll have code repositories and internal project records, but might not have complete records of client communications.
Pre-Action Protocol: Evidence exchange obligations help both parties access each other’s materials. This is often when you can obtain evidence that your client alone couldn’t provide.
After proceedings: Standard disclosure provides access to documents. For technical evidence, such as code repositories or production systems, parties sometimes agree to grant access outside formal disclosure to ensure both experts can examine the same evidence.
CPR 35.9: This provision gives the court power to order parties to provide information where one party has access to information that isn’t readily available to the other party. This becomes important when one party controls production systems and refuses to provide access to logs or allow technical inspection. The court can order access to previously withheld evidence.
What Evidence the Expert Needs
With the evidence gathering framework established, here are the specific types of evidence technical experts typically need to assess against industry standards and best practices.
Contractual Documents
Start with the contractual documents. The contract itself, statements of work, any schedules or appendices. These establish what was promised, what methodologies were required (PRINCE2, Agile, specific testing standards), what deliverables were specified, and what obligations each party had. If the contract required PRINCE2 methodology, I assess whether PRINCE2 was actually followed. If it specified particular security standards, I examine whether those standards were met.
Requirements Evidence
Requirements documents are critical. So is evidence about requirements, because often the problem is that requirements documents don’t exist. I look at what requirements were documented, how they were reviewed and approved, how changes were managed, whether acceptance criteria were defined. If there’s a signed requirements specification, that needs examination. If requirements were managed through user stories in Jira, access to that is needed. If requirements were never properly documented, the email record showing requirements discussions becomes essential evidence. The methodology I bring to this category, how requirements become evidence, is set out in a dedicated guide.
Project Communications
Project communications tell the story of what happened as it happened. Email threads showing issues being raised and how the supplier responded. Meeting minutes from project boards or sprint reviews. Slack or Teams conversations about technical decisions. These communications often reveal things that neither party wants to admit — problems that were known but not escalated, decisions that were made verbally without proper documentation, warnings that were ignored.
Technical Evidence
For technical evidence, I need access to code repositories where possible, test records and defect reports, deployment procedures and production logs, project management artefacts like plans and risk registers. The code repository history shows whether professional development practices were followed: code reviews, branching strategies, commit messages. Test records show whether testing was planned and executed systematically or done ad hoc. Deployment logs reveal whether releases were controlled and monitored.
Source code in particular is procedurally distinct from non-software evidence. Access to a defendant’s production repositories raises confidentiality, IP, and CPR 35.4(2) proportionality questions that don’t arise in clinical or construction disputes. The repository history is itself part of the evidence: it shows whether professional development practices were followed, who made which decisions and when, and whether the engineering record matches the contractual narrative. Pre-litigation, code review is usually handled under NDA and restricted access; once proceedings begin, the framework shifts to formal disclosure under CPR Part 31, and the material I rely on becomes part of the report record. How source code is accessed under CPR Part 35, what I report on without exposing protected IP, and how code review interacts with disclosure are covered in my guide to examining source code in disputes.
How to Frame the Letter of Instruction
The Letter of Instruction establishes what you need from the expert and what will be assessed. Clear instructions lead to focused, useful reports. Vague instructions lead to reports that don’t quite answer the questions you need answered.
Providing Complete Background
Start with a complete background. Who are the parties? What was the project? What was contracted for? What went wrong and when? Give the timeline of key events: when the contract was signed, when development was supposed to start and finish, when deliveries occurred or didn’t, and when the relationship broke down. Identify the key players: who was the project manager, who were the technical leads, who were the client stakeholders? This context helps the expert understand what they’re examining.
Framing the Technical Questions
The strongest Letters of Instruction frame technical questions against specific professional standards. They ask the expert to assess what was actually done against what the standard requires, and stop short of asking for legal or commercial conclusions that sit with the solicitor.
A composite example from a typical financial-services system dispute illustrates the form. The specifics below are illustrative composites drawn from typical engagements; details have been adjusted to preserve confidentiality.
- Did the supplier follow professional standards for software testing appropriate to a regulated financial services system, with reference to ISO/IEC/IEEE 29119 and the ISTQB body of knowledge?
- Was the code quality of the delivered system adequate for an application handling sensitive customer data, with reference to OWASP secure-coding guidance and applicable industry practice for the technology stack?
- Were the architectural decisions reasonable, given the documented requirements and constraints? Where decisions were taken without documented justification, what evidence of decision-making is visible in the project record?
- Was the project managed in accordance with the PRINCE2 methodology, as specified in the contract, with particular reference to change control, risk management, and stage-gate governance?
- Did the client provide timely access to stakeholders and make decisions within contractually required timeframes, with reference to the responsibility matrix in Schedule 3 of the contract?
- Where the supplier raised issues during the project, were those issues escalated and addressed in accordance with the agreed governance process?
- To the extent that the project didn’t deliver against the contracted scope, what evidence does the technical record provide on the causes of that shortfall, and how is responsibility distributed across supplier and client conduct?
These are technical assessment questions. They don’t ask about legal merit, quantum, or apportionment of blame; those determinations rest with the solicitor based on the technical findings and the legal framework around them. Questions that step into legal merit (“do we have a good case?”) or quantum (“how much can we recover?”) are out of scope for the expert.
Pre-Litigation Advisory vs. CPR Part 35 Engagement
You’ll also need to clarify whether you’re instructing for pre-litigation advisory work or as a CPR Part 35 expert witness. The engagement scope differs. Pre-litigation work is advisory: helping you understand technical reality so you can advise your client. CPR Part 35 work involves formal obligations to the court, specific report requirements, and potential involvement in expert discussions and trial. Both are valuable, but the formality and process differ.
Facilitating Evidence Access and Interviews
One aspect of the instruction that matters more than solicitors often realise: facilitating access to evidence and interviews. Technical assessment isn’t just document review. I typically need to interview your client to understand context, decisions made, problems encountered, and attempts at resolution. Sometimes interviews with technical staff who worked on the project are needed. If appropriate and agreed, interviews with personnel from the opposing party might be necessary.
Your role is to facilitate these interviews, arrange access to evidence that requires cooperation (such as code repositories or test environments), and help navigate the practicalities of evidence gathering. Experts can’t compel anyone to provide access or answer questions unless you’re in proceedings and the court orders it. Before proceedings, I rely on voluntary cooperation facilitated by you.
Timeline Expectations
The timeline for all this depends on case complexity, evidence volume, and accessibility. I don’t commit to fixed timelines without understanding what I’m assessing. Simple cases with complete evidence and clear violations of standards might take weeks. Complex cases with extensive code review, multiple systems, incomplete documentation, and nuanced technical questions might take months. Realistic timelines should be discussed during the initial consultation, based on your case.
What Technical Assessment Reveals
For a detailed example of what a technical assessment reveals in practice, I recommend reading my analysis of a typical compliance system dispute, which illustrates how the assessment uncovered shared responsibility: both supplier project management failures and client decision-making delays contributed to the project’s failure. That case study shows how technical clarity transforms legal strategy.
Technical reality in disputes is rarely as simple as either party believes when they’re entrenched in conflict. Three outcomes are common, and all three provide value to you as an instructing solicitor.
1. Clear Technical Failure
Sometimes the evidence clearly shows technical failure by the supplier. No testing was conducted before production deployment. Code quality violates basic professional standards: security vulnerabilities from negligence, architecture that couldn’t possibly scale, no error handling. Project management artefacts promised in the contract simply don’t exist. Professional standards like PRINCE2 or ISTQB that were contractually required weren’t followed. When a technical assessment reveals this pattern, the expert report documents these failures objectively with evidence. The supplier violated professional standards in ways that competent software engineers would recognise immediately.
This outcome substantially strengthens your negotiating position. You can approach settlement discussions or litigation with confidence that the technical foundations of your case are solid. The expert report documents specific standard violations, cites the evidence supporting these findings, and explains why these failures represent breaches of professional duty. When opposing counsel or their expert sees findings like this backed by thorough evidence, settlement discussions tend to become more realistic.
2. Shared Responsibility
More commonly, a technical assessment finds shared responsibility. Both parties failed to follow professional practices in different ways. The supplier’s project management was inadequate: no risk management, poor communication, acceptance of verbal changes without impact assessment. But the client also failed contractual obligations: provided slow decision-making despite contractual timeframes, withheld access to stakeholders despite requirements for their input, signed off UAT then later claimed features didn’t work. The technical work itself might be professionally competent, but project governance failed on both sides.
This outcome is uncomfortable but valuable. It enables realistic client advice about prospects and strategic case management. You can explain to your client that while the supplier bears some responsibility, they do too, and this shared responsibility will affect both liability findings and damages calculations. Settlement discussions can focus on proportional responsibility rather than all-or-nothing positions. And if the case proceeds to trial, you aren’t surprised when disclosure reveals your client’s contributions to the failure.
3. No Technical Failure
Sometimes, less common but it does happen, the assessment shows the supplier actually followed professional standards despite the client’s unhappiness. The code quality is good. Testing was professionally conducted. The supplier delivered what was specified in the (admittedly poor) requirements document. The problems stem from unclear requirements definition, changing priorities, or infrastructure issues on the client’s side, rather than supplier incompetence.
This outcome saves your client from expensive litigation they’d likely lose. Better to understand this reality during initial assessment than after spending six figures on litigation, only to face adverse findings during expert discussions or trial. You can advise your client about their realistic position, explore whether there are non-technical grounds for claims, or focus on commercial resolution rather than litigation.
How This Informs Your Strategy
All three outcomes provide essential clarity: the technical reality before legal strategy is set in stone. This clarity informs how you advise your client, how you approach settlement discussions, whether you pursue litigation, and how you present your case if litigation proceeds.
Financial breakdown can often be quantified. In the compliance system case referenced earlier, technical assessment documented that approximately £280,000 of work was delivered and functional, approximately £90,000 of additional costs resulted from client-requested scope changes, and approximately £80,000 represented legitimate failure to complete contracted work. This quantification transformed settlement discussions from “they owe us everything” versus “we owe them nothing” into a realistic negotiation about proportional responsibility.
The CPR Part 35 Process
When you instruct an expert witness under CPR Part 35, specific obligations and processes apply. Understanding these helps you work effectively with the expert and manage your client’s expectations.
The Expert’s Overriding Duty
The expert’s overriding duty is to the court, not to your client or you. This means examining evidence objectively and forming independent opinions, whether or not those opinions help your case. If the evidence shows your client contributed to the failure, the report will say so. If the opposing expert’s position has merit, that will be acknowledged in expert discussions.
Your strongest expert witness is one who tells the truth objectively, because that credibility withstands cross-examination.
Expert Report Requirements
The expert report complies with CPR Part 35 and Practice Direction 35 requirements, including a statement of duty, the substance of instructions, qualifications, distinguishing fact from opinion, and a statement of truth. These requirements ensure transparency into the evidence examined, the instructions received, and the opinions formed.
Part 35 Questions
Part 35 questions provide a mechanism for clarification. I answer directly and honestly: correcting genuine errors, addressing valid points not fully considered, or noting when questions are argumentative rather than clarifying. Your role includes reviewing proposed questions before they’re sent.
Expert Discussions and Joint Statements
Expert discussions identify areas of agreement and disagreement, narrowing technical issues for trial. The process involves an agreed agenda, a meeting between experts (solicitors don’t attend), and a joint statement documenting what was agreed and what wasn’t. These discussions happen without prejudice.
Expert discussions work best when both experts thoroughly examine the evidence and collaborate. What doesn’t help is experts who refuse to acknowledge any merit in opposing positions or treat discussions as adversarial combat. Good opposing experts seek truth rather than victory, and courts appreciate joint statements that genuinely narrow issues.
Trial Preparation
If the case proceeds to trial, the expert must prepare to provide evidence. This includes reviewing the report and case file, identifying the technical issues in dispute, anticipating questions during examination and cross-examination, and ensuring complex technical matters are explained in a way judges without technical backgrounds can understand. Your role includes briefing the expert on how the trial will proceed, what other evidence will be presented, and what technical issues you need addressed clearly in testimony.
I will not accept instructions where I know I will be unavailable for the realistic trial window. Trial commitments are part of the engagement decision, and an expert who can’t show up when needed is worse than one not yet instructed.
Single Joint Expert Appointments
Single joint expert instructions under CPR Part 35.7 are appointments I’m pleased to accept where the procedural conditions are appropriate.
A single joint expert serves both parties to the dispute. The duty of independence to the court — which applies to every expert instruction under CPR Part 35 — carries particular weight in single joint expert work, where one expert’s analysis must address both sides’ technical concerns fairly and be capable of being relied on by either party.
In practice, this means I approach single joint expert appointments with the same procedural rigour as any party-appointed instruction, but with additional care in scoping the questions to be answered, in seeking input from both parties on the technical issues, and in writing findings that survive examination from either direction.
Solicitors considering a single joint expert appointment may find it useful to agree the scope of the expert’s questions in advance; I am happy to assist with that scoping where helpful.
Working With Opposing Experts
One aspect of expert witness work that surprises solicitors is how collaborative expert discussions actually are. Expert discussions aren’t adversarial; they’re technical professionals trying to establish facts and narrow disputes.
Collaborative, Not Adversarial
The opposing expert isn’t your enemy. They’re another professional bound by CPR Part 35 duties to the court. Good opposing experts examine evidence objectively, form independent opinions, and engage professionally in discussions. When both experts are operating properly, substantial agreement on technical facts often emerges even when clients’ cases differ.
Expert discussions can produce agreement on specific technical facts while disagreeing on others. For example, experts might agree that code quality was professionally adequate, but disagree on whether architectural decisions were reasonable given the constraints. That significantly narrows the dispute: the court doesn’t need to resolve code-quality questions, only architectural-judgment questions. Or experts might agree that both parties contributed to the failure, differing only on proportional responsibility. That makes settlement negotiations much more focused.
What Joint Statements Achieve
The joint statement produced after expert discussions has real weight. It documents what technical facts are agreed (courts can rely on these without hearing contested evidence) and what remains disputed (courts need to resolve these through trial). Courts appreciate joint statements that genuinely narrow issues rather than simply restating opposing positions.
Your Role During Expert Discussions
Your role during expert discussions is mostly facilitative. You help develop the agenda in advance, identifying which technical issues need discussion. You ensure the expert has all necessary documents and context before discussions begin. You don’t attend the discussions themselves; they work better as technical conversations between experts without solicitors present. Afterwards, you review the draft joint statement to ensure it accurately reflects discussions and that nothing agreed upon exceeds the expert’s instructions.
When Experts Are Professional (and When They’re Not)
Sometimes, opposing experts are problematic. They act as advocates rather than independent experts. They refuse to acknowledge any merit in opposing positions. They introduce new opinions in expert discussions that weren’t in their reports. When this happens, the joint statement documents these issues. Courts recognise when one expert is properly operating under CPR Part 35 and the other isn’t, and adjust the weight given to the evidence accordingly.
But more often, opposing experts are professionals doing their jobs competently. They might reach different conclusions on some issues, but they examine evidence thoroughly, explain their reasoning clearly, and engage respectfully in discussions. This professionalism serves clients better than adversarial posturing would.