SongSai

Inspiration

Most of the scams ordinary Cambodians actually encounter don't come from some abstract "online scam economy," they come through Telegram and Messenger, as a fake job offer, a fake bank alert, a "friend" whose account has been hijacked. Cambodia's Telecommunication Regulator has publicly warned about a surge in exactly this kind of Telegram-based scam, and local reporting has documented Telegram groups openly recruiting with vague job listings and salaries well above market rate. I'm a third-year software engineering student who also leads my school's Network & Security club, and that specific kind of job scam targets people exactly like me and my classmates, students looking for part-time or remote work.

I looked at the existing tools people are pointed to, and almost all of them are the same shape: a static quiz. Read eight messages, sort them into "phishing" or "legitimate," get a score. Google's own Jigsaw quiz is the best-known example, and it's well made, but it tests whether you can recognize a scam after the fact, calmly, with no pressure, no clock, no emotion. Real scams don't work that way. They work by making you feel something first and think second. I wanted to build something that rehearses that feeling, not just the recognition.

What it does

SongSai (meaning "suspicious" in Khmer, សង្ស័យ) drops you into a live, adaptive chat with a simulated scammer, styled like the real Telegram or Messenger conversation it's imitating, in Khmer or English. You reply the way you actually would. The scammer reacts, escalates, and pushes back if you try to verify. At the end, a walkthrough names the tactic behind each message, points at the exact reply that mattered, and teaches one durable habit: check outside the chat, through a number or app you already had, not one the scammer just handed you. One scenario is a genuine, harmless message, deliberately included so that reflexively blocking everything stops being a winning strategy.

How I built it

The stack is Next.js, Supabase, and an LLM (Gemini, later DeepSeek) for the adversary's live dialogue, but the design choice I care about most is that the AI never writes the scenario itself. Every scam is authored by me as a fixed sequence of "beats," each with an objective, a tactic tag, and a hand-written fallback line. The model's only job is to phrase that beat naturally and react to what the trainee typed; it can't introduce a new request or drift off-script, and a denylist and digit-run filter block it from ever naming a real bank or leaking a real-looking phone number. If the API is slow or down, the app falls back to the scripted line with no visible error. I worked with Claude Code as a coding agent throughout, but the architecture, the guardrails, and every round of design critique were mine, working prompt by prompt, screenshot by screenshot, through dozens of iterations on the UI until it stopped looking like a generic AI-generated template.

Challenges I ran into

The hardest bug wasn't technical, it was psychological: early on, leaving the chat the instant it looked suspicious was always the winning move, for every scenario, because everything was a scam. That teaches reflexive distrust, not judgment. I fixed it by adding a genuine, harmless scenario and turning "leaving" into an actual choice, block, verify, or just leave, scored differently depending on whether the message was real. On the technical side, the classifier that decides whether a reply counts as a "leak" needed real tuning: a naive version would flag anything containing a six-digit number, or would let someone by typing "sending it now" walk away with a win because a bank OTP and a promise to send money don't look alike to a language model unless you tell it they're the same kind of failure. I also hit a real infrastructure snag when my LLM provider's billing entered a broken half-funded state mid-build and I had to migrate the whole render/classify pipeline to a different provider under deadline pressure, which is what pushed me to isolate the LLM behind one swappable module in the first place.

What I learned

The research on this surprised me: the largest real-world study of phishing training, at UC San Diego Health, found that a year of training and simulated phishing emails reduced click rates by less than 2%. What worked in follow-up studies, from Cambridge's misinformation-inoculation research, was teaching the technique behind an attack rather than examples of it. That reframed the whole project for me, away from "here are ten scams to memorize" and toward "here's the pattern every scam shares, and the one move that defeats it regardless of the story." I also learned, the hard way, how much good product design is subtraction: my instinct on almost every screen was to add more explanation, more detail, more warnings, and nearly every real improvement came from cutting something down to the one thing that actually mattered.

What's next

The habit only really sticks with more practice surfaces: more genuine control scenarios so "just block it" never becomes safe again, a legit-vs-fake file-extension guide already built for the most common malware trick in Cambodian Telegram scams, and a "check" action that lets someone call a number inside the chat and get burned by it once, safely, which is how people actually learn not to do it for real.

Built With

• css
• css3
• deepseek
• git
• github
• html5
• next.js
• pg-cron
• postgresql
• pwa
• react
• service
• supabase
• tailwind
• typescript
• vercel
• workers