A single immigration motion can take 15 to 20 hours. We built PleadAI to change that.

We talked to immigration lawyers and kept hearing the same thing. The hard part of a filing is rarely the legal reasoning. It is the volume of careful, repetitive document work that surrounds it.

A single motion exhibit packet can take 15 to 20 hours to assemble. Declarations and affidavits add hours of their own. Every document has to match USCIS formatting exactly, and a small inconsistency can mean a rejection or a delay that costs the client real time.

So the lawyers we spoke with were spending some of their most expensive hours on formatting and proofreading instead of on the people they represent. That is the gap PleadAI was built to close.

We did not want a generic writing assistant pointed at legal text. We wanted a tool that understands the specific structure and requirements of immigration filings, so its output starts close to correct instead of close to plausible.

PleadAI covers the full arc of a document. It drafts declarations, affidavits, and motion exhibit packets. It formats them to USCIS standards. It validates the result before anything leaves the lawyer's hands.

The result is the part that makes lawyers lean in: work that took 15 to 20 hours comes down to about 40 minutes, with the lawyer still reviewing every line.

The principle underneath all of it: save time while keeping the lawyer in control. The AI does the heavy lifting on the first draft and the formatting, and the lawyer stays the one who reviews, edits, and signs off. We spent the full 15 weeks staying close to immigration lawyers, mapping their real workflows, so the product fit the way they already work rather than asking them to change.

On the build side, this is a React and Next.js front end, and I owned the design system that holds it all together.

I owned the design system on PleadAI, and that is where the interesting craft problem lived. With AI writing a lot of the component code, every session is a chance for the system to slip. One eyedropped color here, a hard-coded spacing value there, and over a few weeks you get twelve slightly different shades of the same purple.

That is not a hypothetical. Three weeks in, the deep purple on the document upload card looked a touch lighter than everywhere else. Someone had pulled a hex value straight off a screenshot instead of using the token. Harmless once. Corrosive if it keeps happening.

When two people build with AI, does the design system hold, or does the codebase slowly become three different products? Writing the conventions down once, where the AI reads them every session, was the difference.

Our answer was to write the design conventions down once, in a place the AI reads automatically every session. We built the design system, then a Claude Code skill file that teaches the AI the system: the rules, the references, and documentation for every component. Tokens became the single source of truth, one place per color, spacing, radius, and shadow value, referenced everywhere. That is what makes consistency something you can actually enforce instead of police.

The most valuable part of the skill file turned out to be the anti-patterns list, written as plain rules. Never hard-code colors. Never hard-code spacing. Never import an icon package directly. Never rebuild a component that already exists, check the catalog first. A component catalog documented every component, its props and variants and usage, so the AI stopped reinventing things we had already built. A setup script made the system installable into any project and wrote the real import paths, so the AI imported correctly from the start.

We started monolithic, one big design system file, because that let us iterate fast early on. Then we went modular for production: a folder per component, logic and styles split, a clean barrel export. The division of labor was clear. I owned the rules, the token decisions, the anti-patterns, the catalog. The developer wired up the skill file. The AI enforced the system we had both defined.

We built this as my capstone at San Francisco Bay University and presented it at the Capstone Expo. People resonated with the problem immediately and appreciated how specific the focus was. A tool that does one hard thing well, for one profession, tends to land.

PleadAI is live and preparing for a wider launch, and it has already seen early interest from potential investors. We are not claiming usage numbers we do not have yet. What we can claim is a real product, grounded in real lawyer workflows, that you can try today.

The design system technique paid off in a way that is easy to undersell. Writing the skill file forced the four of us to agree on our conventions explicitly, out loud, instead of each carrying a slightly different version in our heads. The system held. And the discipline that kept it coherent is the same discipline I would bring to any product team.

The team. PleadAI was a 15-week capstone built by a team of four at San Francisco Bay University, advised by Prof. Ahmed Banafa. Saurav Bhatta led backend and integration, Nyan Wai Phyo led AI integration, Ali Khalilabadi led database and testing, and I led UX and front end and owned the design system. Shown at the Capstone Expo, 2026. I wrote up the design-system technique behind this build in my article Stop Re-Explaining Your Design System Every Session.