I Built BouncerBot Without Knowing What Email Validation Even Was

A buddy came to me with an idea

“What if we could tell if an email is from a real person or a bot?”

I said sure, let’s build a POC.

The thing was, I didn’t actually know what email validation was. I knew emails had an @ symbol. That was about it.

So I vibe coded it.

I kept asking AI to write code, then reviewed what it produced. That was it. No deep domain knowledge, no heavy research. Just prompts, reviews, and iteration.

Somehow, it worked.

Meet BouncerBot.

Or siao lang bot when I’m being less professional, which is what I call it in my head.

Here’s what it looks like when you first open it:

Main interface

What It Does

Most email validators stop at very basic checks. If there’s an @, it probably passes.

BouncerBot tries to answer a more useful question:

does this email look like it belongs to a real human, or a bot?

With the help of AI, it evaluates three main signals:

• Domain : does it look legitimate or disposable?
• Username : does it resemble human patterns or bot-generated noise?
• Name match : if a name is provided, does it reasonably align with the email?

There are three modes:

• AI-only : pattern recognition and contextual reasoning
• Non-AI only : DNS checks and traditional validation
• Hybrid : a combination of both

Hybrid works best.

Single email analysis is useful for quick checks. The real use case is batch processing, where you upload a list, let it analyze everything, then make decisions before doing any whitelisting or blacklisting.

Let me show you how it works. First, you enter an email:

Email Analysis Input: Email Analysis tab active, input field showing [e-mail], name field showing “Marcus Chan”

Then you get a result with the full breakdown:

Classification Result: Same email now showing results. Large “ALLOW” badge with green checkmark, confidence score prominently displayed, overall score and decision summary visible.

Why This Exists

The goal is to reduce unnecessary human effort.

People shouldn’t have to manually eyeball long lists of emails just to guess whether they’re bots. That should be a first-pass problem, not a final decision.

The intended workflow is simple:

1. Upload your email list
2. Run batch analysis
3. Review the results
4. Decide what to whitelist or blacklist

In some cases, you might let AI make the call entirely. In others, it simply narrows things down so humans can focus on edge cases.

Either way, it removes a lot of manual work.

The Tech Stack

• Backend : FastAPI
• AI runtime : Ollama running locally
• Frontend : Next.js with TypeScript

AI suggested most of the initial structure. I approved what made sense, rejected what didn’t, and refactored where needed.

It supports email analysis and batch processing. The analysis goes deep. When you expand the detailed sections, you can see exactly what was checked.

AI Analysis: showing Domain Analysis verdict and score, Name Context Analysis with name-email coherence and cultural consistency, and AI reasoning text.

Comprehensive Validation: Comprehensive Validation expanded, showing AI score and Non-AI score side by side, combined score, DNS checks (MX, SPF, DKIM, DMARC), reputation and domain security details.

Does It Work?

Based on internal test datasets:

• It catches the majority of obvious bot or disposable emails
• False positives are relatively low
• International patterns are handled better than expected

Single email analysis is meant for quick checks. Batch processing scans every row in your list and helps with decision making before any whitelisting or blacklisting happens.

Here’s an example where it does exactly what it’s meant to do:

Bot Detection Example: Email [e-mail] showing a large red “BLOCK” result, low confidence score, and explanation of why it was flagged.

And here’s a case that taught me something important:

Cultural Intelligence: Email [e-mail] showing “ALLOW”, high confidence score, and explanation that numeric usernames are culturally normal for QQ.com users.

For batch processing, you upload a CSV and let it run:

Batch Processing: Batch Processing tab active, CSV being processed, progress bar updating in real time, results table filling with Allow, Block, and Challenge outcomes.

What I Learned

Early on, the AI flagged [e-mail] as suspicious. I caught it during review. It turns out numeric usernames are common for QQ.com users in China.

That wasn’t a model failure. It was a cultural blind spot.

Other things I learned:

• Hybrid approaches work better than pure AI or pure rule-based validation
• AI will happily duplicate logic everywhere if you let it
• Refactoring still matters, even when the code is generated

At one point, I forced a refactor that removed more than 50 duplicated logic blocks.

The Prompts I Used

Since I vibe coded this, it felt fair to show the kinds of prompts I kept using.

Nothing fancy. Just very direct instructions, followed by review and iteration.

For building the system

These were the prompts I used to get the initial structure in place:

• “Build a FastAPI endpoint that classifies emails using AI”
• “Create a frontend with Next.js that shows email classification results”
• “Add batch processing for CSV files with real-time streaming”

Most of the architecture came from these. I kept what made sense, removed what didn’t, and refactored heavily after.

For the AI analysis

These prompts live in the config used for the LLM agent calls. Each one focuses on a specific signal.

• Email anomaly detection —  Analyzes whether an email shows bot-like or human-like patterns. Looks for random character combinations, alternating sequences, and suspicious structures.
• Name analysis —  Checks whether names look legitimate, whether they match the email, and whether they make sense culturally. Evaluates name–email coherence.
• Domain reputation —  Analyzes domain quality, professionalism, and legitimacy. Considers MX records and underlying infrastructure.
• Pure AI analysis —  Performs pattern recognition on the domain structure, local part, and name context. Includes word segmentation for compound domains, for example turning “capitalandmall” into “capitaland mall”.
• Comprehensive analysis —  The main decision-making prompt. Combines domain analysis, local-part patterns, name context, and DNS data to produce the final result.
• Domain structure analysis —  Looks at TLDs, subdomains, and domain naming conventions.
• Behavioral analysis —  Focuses on signals that suggest human versus automated behavior
• Temporal pattern detection —  Checks for time-based patterns that might indicate automation.

For fixing issues

These were the kinds of prompts I used once problems started surfacing:

• “This is flagging legitimate Chinese emails as bots, fix the cultural bias”
• “Refactor this duplicate code into a shared utility”
• “Make the UI cleaner and more intuitive”

That was basically the loop. Prompt, review, fix, repeat.

If you want to see the full versions, all the AI prompts live in backend/core/config.py.

Try It

This project is for local use only. No plans to deploy it to the cloud.

git clone https://github.com/MarcusCJH/BouncerBot.git
cd BouncerBot
make start-local

Repo link: https://github.com/MarcusCJH/BouncerBot

API docs are available at http://localhost:8000/docs.

The main endpoint is POST /classify.

If you want to integrate it, the API docs show everything you need:

API Documentation: Swagger UI showing /classify endpoint, request and response schemas, and example JSON payloads.

TL;DR

I didn’t start with expertise in email validation.

I started by iterating quickly, reviewing carefully, and fixing what didn’t make sense.

AI accelerated the build, but it didn’t replace thinking.

The useful part wasn’t the model, it was knowing when to trust it and when to override it.

That’s what made this work.