This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.
What I Built
Have you ever received a message that made you stop and think:
"Is this actually legitimate, or is this a scam?"
That was the problem I wanted to solve for a friend.
Instead of building another generic AI chatbot, I built ScamShield Local a small, privacy focused AI tool that gives you a second opinion when a message looks suspicious.
You paste a suspicious SMS, WhatsApp message, email, job offer, payment request, or investment message into the application, and it analyzes the text and gives you:
- a risk level
- a risk score
- the warning signs it detected
- recommended actions
The idea is simple:
Pause before you trust.
Why I Built It
I wanted to build something that could actually be useful to someone I know.
Scam messages are becoming increasingly convincing. They often create urgency, impersonate companies or people, promise unrealistic rewards, or ask for sensitive information.
The problem is not always knowing that something feels suspicious.
The problem is understanding why it is suspicious.
That's what ScamShield tries to help with.
Instead of just saying:
"This is a scam."
it explains the signals that made the message risky and gives the user safer next steps.
Demo
Here is a short demonstration of ScamShield Local:
In the demo, I paste a suspicious message into the application and let the local AI analyse it.
The application identifies the warning signs, produces a risk score, and recommends what the user should do next.
Code
The complete project is available here:
https://github.com/Samearth17/scamshield-local
How I Built It
I wanted the application to be small, fast, and easy to run locally.
The stack is:
- FastAPI for the backend
- HTML, CSS, and JavaScript for the frontend
- Ollama for local AI inference
- an open-weight model running locally
- Pydantic for structured response validation
- pytest for automated testing
The architecture looks like this:
Browser
|
| POST /analyze
v
FastAPI
|
| Local request
v
Ollama + Open-Weight Model
|
v
Structured JSON
|
v
Risk Analysis
|
+-- Risk Level
+-- Risk Score
+-- Red Flags
+-- Recommended Actions
The application doesn't require a hosted AI API or a database.
The message is sent to the local FastAPI application, which communicates with Ollama running on the same machine.
I also added validation and safeguards around the model response so that malformed output does not directly reach the user.
The risk score is normalized so that the displayed score always agrees with the risk level. For example, a HIGH-risk result cannot end up displaying something contradictory like 10/100.
Why Local Open-Source AI?
This is probably my favorite part of the project.
A person might paste a very personal message into a scam detector. It could contain a phone number, someone's name, payment information, or part of a private conversation.
I did not want the basic workflow to require sending that information to a third party AI API.
With local inference, the model can run directly on the user's machine.
That means:
- the message doesn't need to be sent to a third-party AI provider
- the user has more control over their data
- there is no requirement for a hosted AI API key
- the underlying model can be changed for another compatible open-weight model
- the application can continue to work independently of a hosted AI service
For this particular problem, open and local AI isn't just a technical choice it is part of the product's privacy story.
Building It With AI
I also used AI coding tools during development to accelerate implementation, debugging, testing, and iteration.
But the goal wasn't to simply generate a chatbot and call it a project.
The interesting work was deciding:
- what information the user actually needs
- how the model should structure its response
- how to handle malformed model output
- how to keep the risk score consistent
- what safety guidance should appear for high-risk messages
- what the application should explicitly not claim
That distinction became especially important while building a tool that deals with potentially sensitive messages.
What I Learned
One thing I learned from this project is that getting an LLM to produce an answer is relatively easy.
Getting that answer to be useful, predictable, and responsible is much harder.
I ended up spending significant effort on things that aren't immediately visible in the UI:
- structured output validation
- malformed-response handling
- input validation
- risk-score normalization
- safety guidance
- automated tests
- clear limitations
I also learned that a small project can sometimes make a stronger demo than an overly ambitious one.
Instead of building a huge platform, I focused on solving one problem well.
Limitations
ScamShield is not a guarantee that a message is fraudulent or safe.
It only analyzes the text provided to it. It does not independently verify:
- sender identity
- URLs or their destinations
- attachments
- account activity
- transaction history
- the wider conversation context
A LOW risk result does not mean that a message is safe.
The application is intended to provide an additional perspective and encourage users to verify important requests independently.
Built for a Friend
The whole reason this project exists is that I wanted to build something practical for someone I know.
The workflow is intentionally simple:
Paste → Analyze → Understand → Make a safer decision
No complicated setup in the interface.
No account.
No database.
No need to send the message to a hosted AI API.
Just a small local AI tool that can help someone stop for a moment before clicking, paying, or sharing sensitive information.
Final Thoughts
This started as a weekend challenge, but I liked the idea behind it: build technology for a person, not just for a portfolio.
ScamShield Local is small, but it gave me a chance to explore local AI, structured LLM outputs, safety-focused UX, and privacy-aware application design in one project.
If you try it out, I would genuinely love to hear:
What would you want an AI scam detector to explain before you decide whether to trust a message?
Top comments (0)