From the outside, a class action or recall website looks like five simple pages. A home page explaining the case. An FAQ. A claim form. A status lookup. A way to contact the administrator. You can imagine building one in a weekend, and plenty of people have tried. Most of them spend the next two years regretting it.
What looks simple on the surface is a specialized discipline underneath — a combination of legal requirements, operational realities, and claimant behavior that has almost nothing in common with the average consumer web product. We've been building these sites for years, across administrators like Fidexis, across matters ranging from consumer product recalls to multi-jurisdiction class actions. The pattern we've landed on is the opposite of clever. It's boring, repeatable, and rigorously specific about what matters. Here's what actually goes into one.
The Claimant Lifecycle Is The Product
Every settlement website we build is, at its core, a pipeline that walks a claimant from "am I eligible?" to "my money arrived." Four steps, all of them easy to underestimate.
Eligibility is the first thing a class member hits, and it's where most naive implementations already fall short. The claimant needs to know — quickly and clearly — whether they qualify, what they qualify for, and what they need in order to file. For a product recall, eligibility might be as simple as confirming a UPC match. For a class action with millions of potential class members, eligibility involves a lookup against a sealed class list provided by counsel, with careful handling of PII the whole way through. Either way, the work is the same: make the answer obvious in the first thirty seconds, or the claimant leaves.
Claim submission is where the site earns or loses the administrator's reputation. The form needs to collect exactly what counsel and the court require — no more, no less — and it needs to accept the claimant's evidence (receipts, photos, serial numbers, proof of purchase) without making them feel like they're being interrogated. Fields phrased in plain English. Optional uploads that don't block completion if the claimant doesn't have a receipt handy. Validation that's strict where it has to be and forgiving where it doesn't. These sound like UX polish. In practice they're the difference between a claim rate that makes the notice program look good and one that triggers uncomfortable questions from the court.
Status lookup is what keeps the phone line from ringing off the hook in the weeks after submission. Every claimant wants to know whether their claim was received, whether it's been approved, and when their payment will land. A well-designed status lookup answers all three — without exposing anything the claimant shouldn't see, and updating in real time as the administrator processes submissions. We treat this page as a first-class feature, not an afterthought, because every status check that works is a phone call the administrator doesn't have to take.
Payout closes the loop. In a small matter, that might be a single disbursement method. In a modern settlement, claimants expect options — physical check, PayPal, Venmo, Zelle, ACH — and they expect to choose the one that works for them. Supporting all of those means integrating with payment processors that take audit, reversal, and fraud risk seriously, and it means the site has to be honest with the claimant about timing. Digital rails clear in days. Check delivery takes weeks. The worst thing the site can do is surprise the claimant about either one.
Audit Hygiene Is Non-Negotiable
A settlement website is a legal instrument. The court knows it. Class counsel knows it. Defense counsel knows it. That means everything the site does — every version it was deployed in, every change that was made, every piece of content that was displayed to a specific claimant on a specific day — has to be reconstructible after the fact.
The standard footer on every page of every site we run is a small, unassuming line that most visitors will never notice: a website version number, a deployment timestamp, and a content hash. It looks like this on a site we currently run:
Website Version v13 / 2026-03-12T10:11:02-04:00 Hash e6e7f11799eb2dfea1d3f4b75a20889e
That single line does a lot of quiet work. It tells anyone inspecting the site — including a party in litigation months or years later — exactly which version of the content was live at any given point. If a dispute arises about what a claimant saw on the day they filed, we can pull that version from our archive and prove it byte-for-byte. Change control is not an afterthought; it's baked into the deployment pipeline and stamped into every page render.
The same discipline applies to form submissions, content changes, FAQ updates, and deadline displays. Every material change requires documentation. Every deployment is traceable. Nothing ships during an active claim period without counsel sign-off. None of this is glamorous work. All of it is the foundation of a reputation a settlement administrator can stand behind in front of a judge.
Meeting Claimants Where They Are
The claimant population in a class action or recall is nothing like the user base of a typical consumer web product. It's wider, older, less technical, more geographically distributed, and considerably less tolerant of friction. A site that works perfectly for a 28-year-old on an iPhone can be completely unusable for a 72-year-old on a decade-old desktop browser — and the administrator bears the cost of every claimant who gives up partway through.
That changes how we build. Mobile-first, because a huge fraction of claim submissions come from phones. But also: browser compatibility that extends well past what any standard consumer product would bother supporting, because recall claimants tend to be on exactly the browsers that modern frameworks have quietly dropped. Every site we run ships an explicit outdated-browser notice, so a claimant on an older machine gets a clear message instead of a silently broken page. Plain-language copy throughout, written for a reader who is not a lawyer. A phone line and email address as first-class alternatives to the web form, because some claimants will never file online no matter how well the form works.
Privacy controls matter here too. Every site we build supports claimant-initiated data deletion requests, clear privacy policies, and careful handling of PII from the moment it's submitted to the moment it's purged after the case closes. The specific requirements vary by jurisdiction and case type, but the posture is uniform: design for the strictest applicable standard and apply it everywhere.
Running a settlement or recall and want the site to be the part you don't worry about? Let's talk about your administration →
Built Once, Run Many Times
One of the quieter advantages of running a real platform instead of hand-building every site is consistency. The sites we build for Fidexis and other administrators share a common codebase — the same eligibility flow patterns, the same status lookup, the same audit footer, the same disbursement plumbing, the same outdated-browser fallback. Each matter gets its own content, branding, and case-specific logic, but the underlying machinery has been hardened across dozens of deployments.
This matters for two reasons. First, every fix we make on one site makes every other site better. A subtle issue we caught in a status lookup during a consumer recall got patched into the platform and quietly improved every subsequent class action we ran. Second, when an administrator brings us a matter with an aggressive timeline, we're not starting from scratch. We're configuring something that has already survived real notice programs, real court scrutiny, and real claimant volume. That's faster, cheaper, and — more importantly — less likely to surprise anyone at launch.
Notice Day Is The Design Constraint
Every settlement website has a moment where the notice program activates and traffic goes from essentially nothing to a significant spike. Emails blast out, postcards arrive, a press release drops, and a large volume of claimants show up at the same URL over a short window. The shape repeats at every reminder wave and peaks in the final days before the claim deadline.
We build for this moment as a matter of default posture, not as a special case. The infrastructure each site runs on is sized for peak, not average; content is cached aggressively so the first page every claimant sees is fast regardless of where they are; the parts of the site that can fail safely do, and the parts that can't — claim submission, status lookup, audit logging — are built to keep working when everything else is under load. Infrastructure that holds under real load is a discipline we take seriously across every project we run, and settlement sites are where the consequences of getting it wrong are most public.
Why This Is The Work
Kevin and I have been building web platforms for a long time, and settlement administration has turned into one of the areas we care about most. The reason is simple. Most of what a settlement website does is invisible when it works. The claimant files a claim, gets a confirmation, checks status, gets paid. Nothing goes wrong. The administrator's phone doesn't ring. The court doesn't notice. The site does exactly what it was supposed to do, and then the case closes and the site gets archived and nobody thinks about it again.
That quiet competence is the product. It's also what the industry has historically struggled with — not because the problem is technically exotic, but because the discipline is specific and the constraints are genuinely different from general consumer web. The administrators we work with notice when a partner gets it right. Counsel notices. The bench notices. That's how reputations get built in this business, and it's why we've made the work itself into something we can repeat and improve on, settlement after settlement.
If you're a settlement administrator, class counsel evaluating administration partners, or an in-house team looking at your options for an upcoming matter, we're happy to walk through how we approach this work. Start a conversation — we'll be honest about what's a good fit and what isn't.
