Note: This article offers practical guidance for attorneys engaging technical experts. It is general commentary, not legal advice. Consult counsel about any specific matter.
In a modern software patent, copyright, or trade secret case, the source code review is rarely one expert alone in a room. The productions are too large for that. Millions of lines of code, multiple repositories, years of version history, and a protective order that confines the work to a locked review room on an air-gapped machine. So the work gets distributed: a testifying expert directs the analysis, and a team of reviewers does much of the day-to-day examination at lower hourly rates.
That structure is legitimate, and it is usually the right call. Distributing the review controls cost, parallelizes the work, and gets a large production covered before the discovery cutoff. We build review teams this way ourselves.
But as this part of the market has grown, it has also begun to commoditize. Some providers now compete almost entirely on rate, staffing reviews with whoever is available rather than whoever is qualified. The bid looks attractive. The risk shows up later, at deposition or at the Daubert stage, when the opinions built on that review have to hold up. By then the money saved on the review is a rounding error against what is at stake.
This article is a buyer's guide: how the team model is supposed to work, where cut-rate reviews go wrong, and a checklist attorneys can use before signing the engagement letter.
The split that matters: who testifies, and who reviews
Every distributed code review has two layers.
The testifying expert signs the report, sits for deposition, and takes the stand. Under Federal Rule of Civil Procedure 26 and the cases applying it, the opinions must be the expert's own. An expert may rely on assistants, but courts and opposing counsel probe whether the expert genuinely directed and understood the underlying work or merely adopted someone else's conclusions.
The review team does much of the hands-on examination: locating the accused functionality, tracing call paths, mapping code to claim limitations or to the allegedly copied or misappropriated material, and documenting what they find.
The quality of the second layer determines whether the first layer survives. A testifying expert is only as strong as the review beneath the opinions. When cross-examining counsel asks "Did you personally review this file?" and "How do you know your team's characterization of this function is accurate?", the answers need to reflect a review the expert actually supervised, checked, and can defend. If the honest answer is that the expert took a low-cost team's spreadsheet on faith, the opinions are exposed, and so is the case.
Where bargain reviews go wrong
Patterns we have observed from across the table, and in matters that came to us after other review teams failed, stated generally and without reference to any particular provider:
No testifier ownership of the review. The testifying expert is bolted on at the end, handed summaries produced by people the expert never directed and may never have met. The methodology was not the expert's, so the expert cannot defend it as their own.
No second pass. Nobody re-derives or spot-checks the key findings. A single reviewer's misreading of a critical function flows straight into the expert report, and the first person to test it is opposing counsel's expert.
Reviewers mismatched to the codebase. A review team is not interchangeable across technologies. A reviewer fluent in web application code can be lost in embedded firmware, a real-time operating system, an FPGA hardware description, or a decade-old proprietary build system. Generic "code reviewers" without depth in the language, stack, and domain of the accused product miss what matters and mischaracterize what they find.
No defensible methodology or audit trail. Ad hoc searching with no documented plan, no record of what was examined and what was not, and no consistent note-taking that maps findings to source files and versions. When the deposition turns to coverage ("What fraction of the production did your team examine, and how did you choose?"), there is no good answer.
Throughput too good to be true. A quote promising that a huge production will be meaningfully reviewed in an implausibly short time, at an implausibly low price, is describing a shallower review than the case needs. Speed claims should come with an explanation of method, not just a rate card.
None of this means low-cost reviewers are always bad, or that every premium team is rigorous. It means rate alone tells you nothing about whether the work will survive adversarial scrutiny. That is what the vetting is for.
The vetting checklist
Questions to ask any code review team before engagement, and the answers to listen for:
- Who will testify, and when do they join the review? The testifying expert should be identified up front and involved from the start: shaping the review plan, directing priorities, and checking work throughout. Be wary of a team that treats the testifier as a late-stage signature.
- Who exactly will be in the review room? Ask for names and CVs of the actual reviewers, not a generic staffing pool. Then ask how each reviewer's background maps to this codebase: the languages, the platform (embedded, mobile, cloud, hardware description), and the industry.
- What is your quality-control process? Listen for specifics: second-pass verification of key findings, findings traceable to specific files and versions, periodic review sessions with the testifying expert. "Our people are experienced" is not a QC process.
- How will you document the review? There should be a methodology the testifying expert can articulate under oath: how the review was scoped, how files were prioritized, what tools were used within the protective order's limits, and how findings were recorded. Ask the team to describe the format findings are recorded in. Do not expect to see actual work product from past matters; that material is confidential to other clients and other cases, and a team willing to show you someone else's review materials is telling you how yours would be treated.
- How do you handle protective-order logistics? Experienced teams speak fluently about review-room protocols, source code computers, note restrictions, and printing limits. Fumbling on these basics predicts fumbling on the substance, and protective-order violations put counsel's own standing at risk.
- What happens when the schedule compresses? Discovery schedules slip and productions arrive late. Ask how the team scales without diluting quality, and who the additional reviewers would be. "We add bodies" is the wrong answer; "we add people with the same domain screening, under the same QC" is the right one.
- Can the testifying expert defend this review as their own? This is the question behind all the others. If the structure of the engagement would leave the expert adopting conclusions they did not direct and cannot personally stand behind, the savings are illusory.
What quality looks like
For contrast, the model we consider defensible, and the one we run at Barr Group: the testifying expert leads the review from day one, and we provide the names and CVs of the actual reviewers up front. Reviewers are matched to the technology, drawn from engineers with real depth in the codebase's domain. The testifying expert supervises the review throughout and personally verifies the key code findings that support the opinions before they reach a report. The methodology is documented as the review proceeds, so the expert's answers at deposition describe work the expert actually directed, checked, and owns.
That model costs more per hour than a commodity review shop. It costs far less than an opinion that collapses under cross-examination.
The takeaway
Distributing a source code review across a team is standard practice, and hiring lower-rate reviewers for the volume work is a reasonable way to control cost. The mistake is treating the review as a commodity and selecting a team on rate alone. The review is the foundation of every technical opinion in the case. Vet the team like it matters: insist on testifier ownership, domain-matched reviewers, real quality control, and a documented methodology. The cheapest team is not the safest team, and the difference tends to reveal itself at the worst possible moment.
Barr Group's team of electronics and software expert witnesses provide experienced and unbiased source code reviews, expert reports and testimony for product liability, patent infringement, software copyright, and trade secrets litigation involving computer-based technology and software. HIRE AN EXPERT