ClaimGuard
A platform that helps freight carriers recover money they are owed — reading their paperwork, building the claim, and tracking it to payment.
Please note: A business I own and operate.
- My role
- Founder and sole developer — product, platform, AI subsystems and security.
- Built for
- Freight & logistics
- Current status
- Live in production. The document-retrieval subsystem is deployed and measured, but is not yet answering questions against real customer documents.
- Built with
- Next.js · Supabase · Stripe · Anthropic Claude · Vector search · S3 document storage · Redis rate limiting
The story
What problem existed, and what we built.
The problem
Carriers are routinely owed money for detention, layovers and short pay. Recovering it means finding the right documents, reading the fine print, assembling a claim, and chasing it. Most small carriers simply don't, because the effort per claim is larger than the claim feels.
What I built
A platform that takes the paperwork, extracts what matters from it, walks the carrier through building the right kind of claim, and then manages that claim through to payment.
What it had to achieve
- Make a claim worth filing by making filing it cheap
- Read the paperwork so the carrier doesn't have to
- Keep one clear path into the product
- Treat other people's shipping documents as seriously as they deserve
The customer's experience
A carrier uploads the paperwork for a load. The system pulls out the details that matter, guides them through the right claim, and then tracks it. What used to be an afternoon of document archaeology becomes a short guided flow.
What customers can do
- A guided wizard covering every claim type, with one front door instead of several
- Upload documents and have the relevant details pulled out automatically
- Track claims through to payment
- Two-factor authentication on accounts
The owner & staff experience
Claims, documents and their status are all in one platform, with payments and notifications wired through it.
What the business can do
- Document intelligence that reads uploaded paperwork
- A retrieval system that can answer questions against a claim's own documents
- An audit trail designed so sensitive question text stays out of the permanent record
- Payments, email, rate limiting and bot detection wired in
How it works
The system, explained without the jargon.
If a technical term is needed below, it's explained right where it appears.
Documents in, structured facts out
Uploaded paperwork is read by a language model and turned into the specific fields a claim needs, rather than staying a pile of PDFs someone has to open one at a time.
Answers grounded in the actual documents
Questions are answered from a claim's own documents. Before any excerpt is used, the system verifies it genuinely belongs to that claim — so one customer's paperwork can never inform another's answer.
One front door
Several older entry points were deleted and now redirect to a single wizard. Multiple half-maintained intake paths are how products quietly break.
Design decisions
The choices that shaped it — and why.
Rebuilt intake on one engine
Every claim type now runs through the same schema-driven wizard. The dead legacy forms were deleted rather than left in place, so there is one thing to fix when something is wrong.
Releases are explicit
Merging to the main branch produces a preview here, not a release. Shipping is a deliberate, separate act — which prevents work-in-progress reaching customers by accident.
Privacy in the audit trail
The permanent audit record deliberately excludes the text of administrator questions. An audit log is supposed to prove what happened, not become a second copy of sensitive content.
How it was built
Development process
- 1Built the two-service platform and the freight lead engine
- 2Added document intelligence
- 3Built and shipped the document-retrieval subsystem, with evaluation gates it has to pass
- 4Hardened retrieval so document scope is verified before any excerpt is returned
- 5Rebuilt intake so all claim types run through one wizard
- 6Currently measuring how relevant the retrieved citations actually are
Where it stands
Status & outcome
Current status
Live in production. The document-retrieval subsystem is deployed and measured, but is not yet answering questions against real customer documents.
Outcome
The most technically demanding system in this portfolio, and the reason the AI and document work described elsewhere is grounded in something real. No recovery totals are published here.
Related projects
You might also want to see
J Kiss LLC
Operations platform for a service business · My own venture
A Dallas–Fort Worth hauling company that takes quotes, books jobs, dispatches crews, hires staff and runs payroll from one connected system rather than six disconnected ones.
Read the case studyNuHQ
Portfolio operations dashboard · Internal tool
The dashboard I use to run everything else — health, deployments and priorities across every project, where every number has to say where it came from.
Read the case studyWant something like this for your business?
Tell me how your days go and what you'd like to stop doing by hand. I'll tell you honestly what would help.