Inspiration
Students and first-time job seekers often receive job offers that look professional but quietly ask for money, personal information, or an immediate response. A fake-check request, an urgent onboarding message, or a recruiter who insists on moving the conversation to Telegram can be difficult to evaluate when someone is excited about a new opportunity.
We wanted to build a tool that helps people slow down and inspect the wording before they reply. Many safety tools hide behind a mysterious risk score, but a score alone does not tell a student what triggered the warning or what to do next. JobGuard was inspired by a simple idea: show the evidence first, explain the pattern, and keep the final decision with the user.
What JobGuard does
JobGuard lets users paste a recruiter message or upload a PNG, JPEG, or WebP screenshot of an email. For screenshots, the visible text is transcribed server-side. The resulting offer text is evaluated by a transparent, deterministic policy engine that looks for documented safety patterns.
The app can identify signals such as fake-check money movement, requests to move money, pressure to act immediately, premature requests for sensitive information, unofficial contact channels, and missing details that should be independently verified. Each signal keeps the important pieces together:
the exact phrase that triggered the signal;
the rule that explains why the phrase matters; and
a source link that gives the user additional context.
The result is an evidence ledger and a practical verification checklist—not a black-box score and not an employer-verification guarantee.

How we built it
We built JobGuard as a full-stack TypeScript application using React, Vite, Express, tRPC, Zod, and Tailwind CSS. The interface uses a repository-specific Trust Ledger design system with a calm white canvas, cobalt safety blue, orange risk signals, green safe actions, evidence labels, and the Doc Guard paper-and-shield mascot.
The analysis flow is deliberately narrow and explainable. Vision transcription is used only to read visible text from an uploaded screenshot. It does not decide whether an offer is fraudulent. Final signal severity comes from inspectable TypeScript rules in the repository:
const signal = matchPolicyPattern(offerText);
return {
quote: signal.exactPhrase,
rule: signal.policyRule,
severity: signal.severity,
source: signal.sourceUrl,
};
This separation makes the product easier to understand and safer to communicate. The system can say, “This phrase matches a documented risk pattern,” without claiming, “This employer is definitely fraudulent.”
The core product principle
JobGuard is designed around the relationship:
$$ \text{exact phrase} + \text{transparent rule} + \text{trusted source} \longrightarrow \text{safer next step} $$
The key distinction is:
$$\text{risk signal} \neq \text{final verdict}$$
That distinction shapes both the product logic and the interface language. JobGuard uses words such as review, signal, and verify rather than overstating what the system knows.
Challenges we faced
The biggest challenge was designing for trust without creating false confidence. A system that labels an employer as definitively fraudulent can lead to unfair accusations or make users stop thinking critically. We solved this by separating screenshot transcription from policy matching and by making every finding inspectable.
Another challenge was preserving the original wording. If a tool summarizes a suspicious message too aggressively, the user may never see the phrase that actually matters. We built the evidence ledger so the original quote, applied rule, and source remain together in one readable card.
We also had to balance urgency with calm. The product needs to communicate that money or personal data may be at risk, but it should not create panic. The final experience moves from a warning to an actionable checklist:
Do not deposit money or forward a check.
Find the company’s official website yourself.
Request role details through the employer’s official Human Resources channel.
Ask someone you trust to review the offer.
What we learned
We learned that transparency is not only an engineering property; it is a product experience. Showing the exact quote and the applied rule makes the analysis easier to question, understand, and verify.
We also learned that a narrow promise can be stronger than a broad one. JobGuard does not try to decide whether every employer is legitimate. It helps users notice patterns, gather context, and choose a safer next step before replying.
Most importantly, we learned that safety guidance becomes more useful when it ends with an action. A clear checklist can turn anxiety into a process and give the user back a sense of control.
Evidence and responsible guidance
The initial evidence pack is grounded in guidance from the U.S. Federal Trade Commission’s job scam resources, including its guidance that college students are targeted by job scams.
JobGuard should never be used to upload passwords, government ID numbers, bank account numbers, or other highly sensitive personal data. The product is intended to support independent verification—not replace it.
What is next
Future versions could add more documented policy patterns, stronger multilingual support, privacy-preserving local text extraction, an optional browser extension, and a consent-based review history. We also want to support bring-your-own-key deployments so self-hosters can operate the workflow with their own server-side credentials while keeping secrets out of the client and repository.
Try the project
Explore the project on GitHub. The live demo link can be added here once the final deployment URL is available.
Log in or sign up for Devpost to join the conversation.