Proof and Pricing · Case study (composite) · Published Aug 17, 2026

Case Study: Our First PI Install (What Transferred, What Didn't)

We built our method in immigration, where the work is documents and deadline chains. Taking it into personal injury for the first time was a real test of what was universal in the playbook and what was just immigration wearing a systems costume. This is a composite, illustrative account of that transfer: which systems carried over unchanged, which had to be reshaped, and which we had to build new. No numbers, no outcome claims, just the structural lessons, because those are the parts that actually generalize.

A composite, illustrative account of taking the immigration systems playbook into PI for the first time. What transferred nearly unchanged: the core engine, capture, reminder lead-time ladder, escalation ladder, ownership, board discipline, because it solves a problem every firm has. What had to be built new: the PI pipeline and its stage systems, SOL discipline, medical-records chase, lien-and-disbursement cadence, and a stronger intake-speed emphasis, because PI's pipeline (lead to treatment to demand to litigation to settlement to disbursement) differs from immigration's document-and-deadline pipeline. In both, the attorney owns the law; the system owns the process. No metrics, no outcome claims. Each system supplements, never replaces, the firm's own processes.

A method built entirely in one practice area is always suspect until it survives contact with another, because it is easy to mistake the shape of one kind of work for a universal system. Our playbook grew up in immigration, where the work is fundamentally about documents and deadline chains: gather the right documents, hit the USCIS deadlines, chain the dependent dates. Personal injury is a different animal, a longer, stage-heavy pipeline running from lead through treatment, demand, litigation, settlement, and disbursement, with medical records and liens as its characteristic drags. Taking the immigration playbook into PI forced a clean separation between the parts of the method that were genuinely universal and the parts that were just immigration-specific habits we had not noticed were specific. That separation is the useful part to share, so this account is organized around it.

Why the transfer was the real test

The value of a first cross-practice install is diagnostic: it reveals which of your systems are load-bearing in general and which were solving a problem particular to where you started. Before the transfer, we could not fully know which was which, because everything had only ever run in one context. Moving into PI applied a forcing function: each system either carried over and worked, carried over and needed reshaping, or turned out not to fit at all and had to be replaced with something built for PI. The result is a cleaner, more honest picture of the method than any amount of theorizing inside immigration could have produced, and it is exactly the kind of structural knowledge that generalizes to the next practice area, which is why we are writing it down rather than reporting outcomes.

It is worth being explicit, again, about what this account withholds. We are not reporting how many cases moved, how fast anything went, or what any engagement produced, both because a single composite account is not evidence of results and because outcome claims in legal marketing are governed by advertising rules that vary by state. The honest and compliant thing to share is the architecture, and the architecture is also the genuinely transferable lesson, so nothing of value is lost by leaving numbers out. This is the same posture as our other proof pieces, described in the systems install overview and the deadline system case study.

What transferred unchanged

The core engine transferred almost without modification, which was the single most useful finding, because it confirmed that the engine solves a practice-agnostic problem rather than an immigration-specific one. That engine is the same set of primitives we describe everywhere: capture, so that nothing critical lives only in a person's memory; the reminder lead-time ladder, so that deadlines surface early rather than at the last moment; the escalation ladder, so that an approaching item nobody has handled climbs until someone does; clear ownership, so every item has a name attached; and the board discipline that makes the whole state of the work visible. These carried straight into PI because the problem they solve, critical work being dropped in a busy firm, is universal; every firm in every practice area has that problem, so the engine that fixes it is universal too.

What this told us is that the method's foundation is not really about immigration or PI at all; it is about how small firms lose track of important things and how a system stops them from doing so. That foundation, detailed in the immigration systems guide, is the part a firm in any practice area can adopt with confidence that it will transfer, because we have now watched it transfer.

What had to be built new

What did not transfer was everything shaped by PI's distinctive pipeline, because immigration's document-and-deadline structure simply does not map onto lead-to-treatment-to-demand-to-litigation-to-settlement-to-disbursement. The statute-of-limitations discipline was the first new build: PI lives under the SOL in a way immigration's varied deadline landscape does not, so we built the strict discipline where the attorney determines the limitations period and the system tracks it with heavy lead times and redundancy, described in the PI SOL system. The medical-records chase was the second: records are the characteristic thing that stalls a PI case, and immigration's document gathering, while related, did not have the same external-dependency chase problem at the same scale, so the records workflow was largely new. The lien-and-disbursement cadence was the third, an entire post-settlement phase that immigration simply does not have.

Beyond those stage systems, the front of the funnel needed a different emphasis. Intake speed matters in every practice, but in PI the competitive value of answering fast is higher and more direct, so the intake system carried over structurally but was tuned for speed in a way immigration had not demanded. The lesson from the new builds is the mirror image of the lesson from the transfers: where a system encodes something practice-specific, the pipeline, the stage-specific drags, the competitive dynamics, it has to be rebuilt for the new practice, and pretending otherwise produces a system that fits badly. Knowing which systems are which, before you start, is most of what makes a cross-practice install go smoothly.

What never moved

The most important thing about the whole transfer is the thing that did not change at all: the line between the attorney's domain and the system's. In immigration and in PI alike, the attorney owns the law, the deadlines, and the judgment, and the system owns the process around them; moving practice areas changed which processes the system runs, not who decides anything. The SOL discipline tracks the period the attorney determines; the records chase gathers what the attorney's case needs; the lien cadence moves tasks toward the disbursement the firm performs. At no point did the system start making legal or professional decisions, because that line is not a feature of immigration or PI, it is a feature of what an operations system is and is not, and it holds in every practice area we will ever work in.

That is the reassuring finding for any firm considering systems in a practice we have not named here: the engine transfers, the pipeline systems get built for your practice, and the line stays exactly where it should. A firm evaluating this can start with the free audit to see its own pipeline and risk clearly, then decide, with the architecture described in the Firm OS overview as the reference for how a full install is structured and owned by your own team.

Where to go next

• The Immigration Systems Method

  Where the engine was built.

• The PI SOL System

  The first new build for PI.

• The Firm OS

  How a full install is structured and owned.

• The Systems Install Overview

  What an install actually involves.

Frequently asked questions