Inspiration
People representing themselves at the Small Claims Tribunals (SCT) increasingly turn to generic AI chatbots for help, and those chatbots have no idea what the SCT actually requires. They make up case law, back up whatever version of events the user already believes, and give confident answers to people who have no way to check them. The Singapore Courts' own guide on generative AI puts the responsibility for accuracy squarely on the user, but the tools available to that user don't help them meet that responsibility. We built Case Helper to close that gap: a tool that organises a claim from someone's real evidence, without ever pretending to be their lawyer.
What it does
Case Helper walks someone representing themselves through building an SCT claim from their own files and their own account of events. A fixed rule check tests the claim against the actual rules (the S$20k/S$30k limit, the 2-year time limit, excluded categories) before anything else happens. Uploaded evidence (contracts, chat exports, screenshots, receipts, photos) is read and ranked by strength, with every fact traced back to the exact page, message, or timestamp it came from. The tool then shows what's still missing, sorted by evidence type rather than legal terms, and asks the user a set of questions about blind spots: what the other side might bring, what the user may have overlooked, without ever answering those questions for the user. Where the user's own account contradicts their own uploaded evidence, the tool flags it directly rather than smoothing it over. At the end, it exports an evidence sheet and a claim pack formatted for filing on CJTS (the Community Justice and Tribunals System, Singapore's online filing portal).
How we built it
We built Case Helper on a MERN stack (a common set of JavaScript tools for web apps) with a strict Routes to Controller to Service to Model backend structure, keeping every layer honest about what it's allowed to know. Fixed rules, such as the eligibility check and the time-limit clock, live entirely in plain code with no AI model involved. The AI model is scoped narrowly to tasks like sorting uploaded evidence against a claim-type checklist and comparing a user's account against their own documents for contradictions. Claim-type templates for tenancy and sale-of-goods disputes (what evidence types matter, what blind-spot questions apply) are written by hand rather than generated per session, so the tool behaves the same way every time and can be checked. The instructions given to the AI model are deliberately narrow: no numeric confidence scores, no AI-written arguments for either side, and reminders of the Courts' guide on generative AI at every step where the user might lean on the output too much.
Challenges we ran into
The hardest problem was not reading the evidence. It was holding the AI back. Early versions of the "what the other side may say" screen slid naturally into the AI writing counterarguments for the user, which felt useful but was really closer to legal advice, and risked backing up whichever side of the story the AI happened to build. We rebuilt that whole screen around a fixed list of neutral questions instead. The AI never says what the other party would argue, it only prompts the user to go and check. We also had to separate two things that looked similar but weren't: a checklist sorted by evidence type (useful for someone with no legal training figuring out what kind of file to go find) and a map of the legal elements that actually decide whether the claim is well supported. Merging them into one screen made the tool either too legal or too vague, so we kept both, quietly linked underneath.
What we're proud of
We're proud that every claim our tool puts together can be traced fully: no fact appears without a link back to the exact evidence it came from, and no case-law reference appears without being checked against a real source first. We're proud of the contradiction check, which catches a mismatch between what a user says happened and what their own uploaded chat log actually shows, a genuinely different approach from tools that just go along with whatever story they're given. And we're proud that the tool knows when to stop: a claim that isn't eligible never reaches a filing pack, an unclear fact never gets silently guessed at, and the user is never told a claim will win.
What we learned
We learned that the safest and most useful thing a legal AI tool can do is often not to generate more, but to ask better questions and step back. Every time we tried to make the assistant more useful by having it draw conclusions or take a side, we made it less trustworthy. The strongest version of this product is the one that treats the user as capable of thinking for themselves. It just makes sure they're thinking about the right things, backed by their own evidence.
Built With
- claude
- codex
- javascript
- python