What this project is

CaseTrends was an immigration intelligence tool for F2A applicants — the family-sponsored visa category for spouses and minor children of green card holders. It was not a USCIS receipt tracker, and it was never meant to be legal advice. What it did was combine public applicant reports, official government data, and a person’s own saved case details into a single, contextual “case read”: here’s where you sit, here’s how that compares to similar cases, here’s what tends to happen next.

I built, launched, and monetized it. Then, on July 1, 2026, I shut it down. Both halves of that story are the point of this write-up.

CaseTrends landing page reading 'Your intelligence hub for cases like yours,' with a sample case read showing 214 similar reports, an 11-month timeline, and a Visa Bulletin status of Current for filing.
The landing page framed the product around a single question: how does your case compare to similar ones, not just what does USCIS say today.

Why I built it

F2A cases can sit in a queue for months or years with very little context. USCIS will tell you what your own case status is today, but it won’t tell you how your timeline compares to people who filed around the same time, whether the monthly Visa Bulletin is currently helping or hurting your category, or what usually happens next for someone in your position. That gap is not a data problem so much as a synthesis problem: the information exists, scattered across a government bulletin, agency status pages, and thousands of individual reports on communities like r/USCIS_F2A. Nobody had put it together in one place with enough rigor to be trustworthy.

I also had a personal stake in getting the framing right — I was living through the same uncertainty as a lot of the people this product was meant to help, which is part of why I was careful never to let it slide into legal advice.

CaseTrends Learn hub with guides titled F2A processing times, F2A Visa Bulletin explained, F2A AOS vs consular processing, USCIS receipt tracker alternative for F2A, and F2A case status meanings.
A Learn hub explaining the terms and mechanics behind F2A cases in plain English, including an explicit page on why CaseTrends is not a receipt tracker.

What I shipped

CaseTrends was a full Next.js App Router application, not a demo. What actually shipped:

Pricing comparison between a Free tier at $0 with public case reads and one saved case file, and a Pro tier at $9.99 per month with monitoring reads, meaningful-change email alerts, weekly case review email, and peer cohort comparison.
Pro was scoped around ongoing monitoring, not just a one-time read — the paid tier is what earned the saved-timeline data and the weekly check-ins.

How the system worked

The core design problem was keeping three kinds of evidence from blurring together: public Reddit-derived signals, official Visa Bulletin and USCIS facts, and a user’s own saved timeline. Each source mode made explicit which of those the case read was allowed to draw from, and the UI surfaced that boundary rather than hiding it behind a single “AI says” output. A pro subscriber’s case read could lean on their own saved history; a free user’s could not, and the interface said so.

Ingestion ran daily, pulling and normalizing new applicant reports, then extraction ran on top of that raw text to turn scattered posts into structured, comparable data points. The Visa Bulletin side worked differently on purpose — drafts were imported but held for admin review before going live, because a wrong Visa Bulletin date is a much more serious error than a slightly off community read.

Three-step how-it-works diagram: Start with your case, Let the hub do the looking, Read the signal.
The pipeline in three steps: the user's own case details, daily-gathered applicant and official signals, and a synthesized read built for scanning, not for guesswork.

For saved cases, monitoring ran quietly in the background rather than asking users to keep checking back.

CaseTrends monitoring panel titled 'Sit back while the signal changes,' listing rerun history, alerts for meaningful movement, and a weekly review digest.
Monitoring was built to only interrupt the user when something meaningful actually changed, not on a fixed schedule.

How AI was involved

I used Claude throughout the build — for implementation, debugging, test-writing, copy iteration, and documentation. That’s a real and material part of how this got built, and I’m not going to understate it. But AI didn’t decide what CaseTrends should be, what data it was allowed to touch, or when it was safe to charge someone for it. Those were mine.

The clearest example is the extraction guardrails. A model, left alone, will happily summarize “this case is basically current” from ambiguous inputs. The hard part was not generating that summary; it was deciding what evidence the summary was allowed to use and building the checks that stopped the model from collapsing “filing chart current” into “final action current” — a distinction that determines whether someone’s next step is to wait or to act. AI helped me test and refine those guardrails quickly. It did not decide they were necessary; catching that failure mode in the first place was product judgment, not a prompt.

Same pattern with the source-mode boundaries: AI helped me implement three cleanly separated data paths fast, but drawing the boundaries — what free users see, what only paying subscribers with saved timelines see, what only admins can query — was a call about trust and privacy that had to be made by a person, not inferred from a spec.

AI helped me move faster across the whole stack, especially in unfamiliar territory like Stripe webhook edge cases and Supabase auth flows. It also made verification more important, not less: every AI-assisted change to billing state, entitlement logic, or the extraction guardrails got manually checked against what I actually wanted the product to guarantee.

What I learned

The core feature — combining public signals with official data into a case read — was maybe a third of the actual work. The rest was everything that makes a prototype into a product you can responsibly put in front of strangers: data retention and deletion, clear boundaries between source types, billing states and duplicate-checkout edge cases, admin tooling to catch bad ingestion before it reaches users, cost controls on AI calls, monitoring for a system running unattended every day, and documentation for all of it. None of that shows up in a demo, and all of it is where a project actually lives or dies.

Why I shut it down

CaseTrends reached a genuinely live state: real analysis, real saved cases, real auth, real billing with a completed live-payment test, monitoring and alerting, admin tooling, daily ingestion, and the legal pages a product handling immigration data needs to have. I disabled new Stripe subscriptions in code and sunset it from there.

I did not shut it down because it failed technically. I shut it down because I did the math on what continuing would require as a solo project — ongoing legal exposure in an immigration-adjacent space, data privacy obligations that only grow with more users, and real operational upkeep for ingestion and monitoring — and it didn’t make sense to keep carrying that alone. There was also a plain constraint I should have weighed earlier: I was still waiting on my own USCIS decision, and monetizing a product in this exact space while that was pending wasn’t something I was willing to keep doing. That’s not a failure story. It’s the same kind of judgment call that decided the source-mode boundaries and the extraction guardrails, just applied to the project as a whole.

What I would do differently next time