How Will Adams builds systems that power high-stakes litigation

By the time a litigation manager pulls a docket report or a firm team checks case completeness, the hardest work is already done. Someone had to take terabytes of inconsistent, unstructured medical and legal documents and turn them into something accurate, organized, and queryable. That’s Will Adams’ job. When he does it well, nobody thinks about it at all.

Will is a Senior Software Engineer at Pattern, where he designs and maintains the backend systems and core API that power the platform from end to end. His work touches everything: what case data looks like when it comes in, how it moves through the system, and what firm teams see when they open a report. There’s no interface with his name on it. What there is, is a platform that either holds up under pressure or doesn’t.

From a small town in West Texas to state champions

Will didn’t find engineering through a carefully considered career plan. He found it on a whim. In ninth grade, he and his friends needed an elective and landed on computer science mostly because they couldn’t agree on anything else. The teacher turned out to be exceptional. One class became seven.

Will went to high school in a small farming community in West Texas. Not exactly a known pipeline for competitive programmers. His school’s computer science team won the UIL state championship seven years in a row. Will was on two of those teams. By the time he got to college, he already knew more than most of his professors were teaching in the first two years.

He was terrible at it initially, he’ll tell you that himself. But something clicked. And once it did, the direction was set.

“I took a computer science class… I was terrible at it at first… it eventually clicked.”

The problems that stuck

What kept Will engaged wasn’t just getting things to work. It was the layer underneath: the data structures, the architecture, the decisions that determine how a system behaves when something unexpected happens.

In college, a course on data structures and algorithms required students to build their own implementations from scratch and then apply them to solve abstract problems. That combination of low-level detail and real-world application was what made it interesting. Not just learning the concept, but understanding why it was built that way and what broke when it wasn’t.

That same instinct carries into how he approaches the work at Pattern today. Good engineering, in his view, means designing for what you don’t know yet, building systems flexible enough that the first new feature request doesn’t require a full rewrite.

Building for how things change, not just how they are

Mass tort litigation doesn’t hold still. Criteria shift. New rulings come in. What counted as qualifying evidence last quarter may need to be re-evaluated this quarter. The systems underneath all of that have to absorb those changes without breaking what’s already been built.

Will’s approach starts at the design stage. If you assume from the beginning that things will need to change and build accordingly, you avoid the worst outcome in software engineering: a system that has to be refactored the moment a new need arrives. The goal is code that’s extendable without requiring giant new pieces just to support small changes.

As he puts it: the worst thing you can do is design something that needs to be rebuilt the first time a new request comes in.

A different kind of data problem

Before Pattern, Will spent five years in the ticketing industry building integrations with every major ticketing platform you can name. The data was high volume but largely uniform. Pattern was a different challenge entirely.

Every litigation comes with its own requirements. Medical records arrive from different providers, span different time periods, and use inconsistent terminology. What works as a data schema for one case doesn’t necessarily hold for the next. What drew Will to the problem was exactly that variability. Systems that handle clean, predictable data are a solved problem. Systems that have to reason about messy, real-world information at litigation scale are not.

That integration background is now directly relevant. Will is part of the team working on Pattern’s integration with Litify, a case management platform built on Salesforce. He’s approaching it the way he approaches everything: building it generically enough that it can support future integrations with limited additional work, rather than solving narrowly for the immediate need.

When the system works, no one asks why

Pattern processes millions of documents across active litigations, and that volume continues to grow. Keeping the platform fast and accurate under that load isn’t a one-time engineering decision. It’s an ongoing discipline: how services are structured, how the API performs, how the system surfaces problems before they reach firm teams.

Most of that work is invisible. A firm pulling a report doesn’t see the architecture. They see results. Will’s measure of a good day is that nothing stood out. Reviews moved, data was clean, and the system did what it was supposed to do.

He has a straightforward way of putting it: “The best deploys are the ones that no one even notices.”

Life outside the code

When work ends, Will is done with work. No side projects, no hackathons, no bleed-over. He has dogs, a ping pong table, a tennis racket, and a pickleball court somewhere in the rotation. He watches a lot of sports and plays a lot of video games.

His wife is a dentist. She explains dentistry, he explains software engineering, and neither one fully follows what the other is saying. It works.

That separation is intentional. He enjoys the work and takes it seriously, but the boundary matters. It’s probably part of why he’s good at it.

Quiet improvements, lasting impact

The things that make Will feel most accomplished aren’t the client-facing features. They’re the changes nobody notices: infrastructure updates, performance improvements, architectural decisions that keep the platform running smoothly without anyone downstream having any idea something changed.

“Engineers thrive off not being noticed,” he says. “The things that keep me going are the things that just keep things running smoothly behind the scenes.”

For firms managing thousands of cases under real pressure, that kind of invisible reliability isn’t incidental. It’s what everything else runs on.

That’s the version of engineering Will is building toward. Not features, but foundations.