Brand Guard

Most brands discover they've been cybersquatted the wrong way. A customer emails to say they got a phishing link from yourcompany-careers.co.uk. Legal receives a cease-and-desist from a fake storefront at yourcompanyshop.de. A journalist finds a counterfeit site ranking above the real one in Germany. By the time the brand team finds out, the damage — stolen credentials, fake job applications, eroded trust — is already underway.

The economics of inaction are brutal. Registering a domain proactively costs $12–$20. Reclaiming a cybersquatted one through UDRP arbitration costs $1,500–$5,000 and takes 2–3 months — assuming you win. The problem isn't that brand teams don't care. It's that no tool existed to make proactive protection fast, cheap, and accessible without an IP attorney. BrandGuard is my attempt to fix that.

The Problem: Discovery Phase

Before writing a line of code, I spent time mapping the actual problem space.

The status quo is reactive by design. When I asked brand managers how they currently discover domain threats, the answers were consistent: customer complaints, Google Alerts that fire too late, and annual audits by IP attorneys. None of those workflows catch threats before they cause harm.

The existing alternatives all have the same fatal flaw — they're either too slow, too expensive, or too manual to use proactively:

• IP attorneys bill at $400–$800/hr for manual domain audits that happen annually at best. By the time the report lands, cybersquatters have had 12 months to act.
• Manual WHOIS lookups don't scale. Checking 50 brand variants across 80 ccTLDs manually is a full week's work, and the data comes back as unstructured text.
• Commercial brand monitoring platforms — MarkMonitor, CSC, AppDetex — are enterprise-priced, require procurement approval and legal sign-off, and take weeks to onboard. They're not accessible to a startup or a mid-size brand team acting quickly.

The gap I identified: No tool existed that could take a company name, understand its global footprint, enumerate every plausible domain variant, check live registration status for all of them, and return a prioritised action list — in minutes, for free.

The damage model is asymmetric. One cybersquatted domain in a key market can enable a phishing campaign targeting thousands of customers, a fake recruitment site that poisons your employer brand, or counterfeit product sales that generate customer service chaos. The attacker pays $12 to register it. The brand pays $5,000 and three months of lawyer time to get it back.

Who Feels This Pain

Three distinct personas emerged from my research, each with a different relationship to the same problem:

The key insight from this exercise: all three share the same underlying problem — reactive discovery — but they need different output formats. The brand manager needs a traffic-light risk summary and a "Register Now" button. Legal needs the full RDAP registrar and expiry data for a cease-and-desist. The founder needs a 10-minute pre-launch checklist. One report has to serve all three.

The Three Insights That Made It Buildable

I almost didn't build this. The scope felt large — you'd need a database of every company's trademark portfolio, their operating countries, their brand variations, and live domain status for hundreds of combinations. That's a data company, not a weekend product.

Three realisations changed my assessment:

Defining the MVP

With the problem clear and the approach validated, I wrote a PRD before touching any code. The discipline of forcing explicit goal definitions and non-goals before building pays off every time.

Goals

Non-Goals (Just as Important)

Explicit non-goals keep scope from expanding indefinitely. For v1, I ruled out:

• Automatic domain registration — requires payment integration, registrar API agreements, and legal liability for incorrect purchases
• Real-time trademark monitoring — out of scope; requires webhook integrations with multiple IP office APIs (USPTO, EUIPO)
• UDRP filing tooling — legal workflows require attorney involvement
• Persistent user accounts — requires auth and a database; deferred to v2
• Social handle monitoring — Twitter/X, Instagram, TikTok handles are a different data source and a different threat vector

Must-Have Requirements (P0)

Architecture: The 7-Agent, 4-Phase Pipeline

This was the most important design decision in the entire project. The naive approach — one big prompt asking Claude to "analyse brand X's domain exposure" — doesn't work reliably. The output is too long, the reasoning gets muddled, and you can't debug which part failed.

The key insight is that brand domain analysis is a dependent knowledge graph, not a single question. Each stage's output is the input to the next:

Brand name → Who are you? → Where do you operate? → What are you trademarked as?
                                    ↓
                       What domains should exist?
                                    ↓
              Which ones actually exist?  +  Who's squatting your brand?
                                    ↓
                       What should you do first?

This maps cleanly to 7 agents across 4 phases:

Why not one mega-prompt? Three reasons drove the multi-agent design:

• Debuggability. When Agent 2 returns the wrong countries for a company, I can test it in isolation. A single 4,000-token prompt that produces wrong output gives you nowhere to start.
• Parallelism saves ~60% of wall-clock time. Phases 1 and 3 run agents in parallel with Promise.all(). Running all 7 sequentially would take roughly 3× as long.
• Streaming works naturally. Each agent logs its reasoning token-by-token as the LLM generates it. Users watch the agents "think" in real time — which builds trust and makes wait time feel productive.

The most important architecture insight: Agent 5 — the domain status checker — uses zero AI tokens. The risk classification logic (assignRisk, classifyOwner, estimateCost) is pure deterministic JavaScript. This is the most data-intensive step (checking hundreds of RDAP responses), and removing the LLM from it dramatically reduces cost and latency.

The right tool for pattern-matching structured data isn't an LLM. It's a function. Save your AI tokens for the reasoning that actually requires intelligence.

Here's how the risk scoring works for every domain the scanner checks:

Tech Stack Decisions

Every technology choice was a deliberate decision, not a default. Here's the table I worked through before starting:

The Vercel decision deserves elaboration. Traditional serverless — one isolated invocation per request — would break this architecture entirely. The scan is started in one HTTP request and streamed in another; they need to share the same in-memory Map. Vercel's Fluid Compute keeps a warm instance alive for the duration of a scan, making this work without any external state store.

Build Order: Inside Out

The build sequence matters as much as the architecture. I followed one rule throughout: build from the innermost dependencies first, the entry point last.

1. services/rate-limiter.js    → Pure utility, no deps. Test it first.
2. services/rdap.js            → Domain lookup, depends on rate-limiter
3. services/tld-data.js        → Static country→ccTLD map, no logic to test
4. services/scan-store.js      → In-memory state + EventEmitter
5. services/claude.js          → AI provider abstraction (Anthropic / Gemini / Groq)
6. agents/agent1–7             → Each follows the same template; Agent 5 is pure RDAP, no AI
7. orchestrator.js             → Glues agents into the 4-phase pipeline
8. routes/scan.js              → POST start, GET SSE stream, GET results
9. server.js                   → Entry point, ties everything together
10. public/index.html          → Frontend — built last when the API shape is stable
11. demo/nike-demo.json        → Demo data — built after schema is finalised

Building the frontend last is counterintuitive but correct. Every time I've built the UI first, I've had to refactor it when the API shape changed. Build the API until it's stable, then build the thing that calls it.

The onChunk streaming pattern is the key implementation detail for the live dashboard:

const result = await runAgent({
  systemPrompt,
  userPrompt,
  onChunk: (text) => appendLog(scanId, 'agent1', text),
})

Every token the LLM generates is immediately forwarded to the SSE log stream. Users see the agent reasoning as it happens. This isn't just aesthetics — it builds trust. When users see the agent working through the logic ("I can see Nike operates in 38 countries, the key markets are the US, UK, Germany, Japan, Australia..."), they understand and believe the output.

Two other critical implementation decisions:

• Rate limiting lives at the call site, not the orchestrator. The token bucket is inside rdap.js. Any code anywhere in the codebase that calls checkDomain() is automatically rate-limited, without the orchestrator knowing or caring.
• Log lines are capped at 500 per agent. Without this cap, a verbose Llama 70B response streaming thousands of tokens will exhaust server memory. Defensive limits on unbounded data are always worth adding.

Multi-Provider AI Support

The original implementation used Anthropic Claude exclusively. I added two alternatives during development:

Google Gemini for free-tier access — useful for development without API spend. The free tier (15 RPM) is frequently hit during a 7-agent scan, so the implementation added retry logic around Gemini SDK calls.

Groq became the default for the .env.example template. Groq's API serves llama-3.3-70b-versatile with extremely generous free limits (~6,000 requests/minute) and very low latency. Development cost on Groq: $0.

The abstraction in claude.js kept all 7 agents unchanged — they call a single runAgent() function and have no awareness of which provider is underneath. Switching providers is one environment variable:

AI_PROVIDER=groq   # or: anthropic, gemini

Deployment: The Three Gotchas

Deployment went smoothly except for three issues worth documenting, because they're easy to hit and not obvious:

1. Vercel project names must be lowercase. My local directory was called "Brand Guard" (capital B, capital G, with a space). Running vercel link failed because Vercel uses the directory name as the project name and applies npm naming rules. Fix: add "name": "brandguard" explicitly to vercel.json.

{
  "version": 2,
  "name": "brandguard",
  "builds": [{ "src": "server.js", "use": "@vercel/node" }],
  "routes": [{ "src": "/(.*)", "dest": "/server.js" }]
}

2. AI_PROVIDER and the API key must both be set together. I set GOOGLE_API_KEY in the Vercel dashboard but forgot to also set AI_PROVIDER=gemini. The app defaulted to Anthropic, looked for ANTHROPIC_API_KEY, didn't find it, and failed silently on the first scan. Both variables are required.

3. Google API key format matters. Google API keys for Gemini start with AIza.... Keys generated from other Google services (service accounts, OAuth credentials) won't work with the Gemini SDK, even if they look like valid keys. Get the key specifically from Google AI Studio.

What Ships: The User Journey

The product is a single-page app with three views:

1. Scan input. Enter a company name. Optionally add focus countries and extra brand/product names. Click "Run BrandGuard Scan" — or try the Nike demo instantly, no API key needed.

2. Live scanning dashboard. Seven agent cards appear, each with a status indicator, a progress bar, and a live log stream showing the agent's reasoning in real time. A progress ring tracks overall completion (0/7 → 7/7) across the four phases.

3. Results report. On completion, the report shows:

• Summary bar: Domains checked, gaps found, HIGH / MEDIUM / LOW risk counts, countries scanned, total budget estimate
• Top 10 Priority Actions: Ranked table with domain, status, risk level, estimated cost, rationale, and a "Register Now" button that opens the registrar with the domain pre-filled
• All Domains Checked: Sortable, filterable table of every domain in the scan — filter by status, risk, TLD type, or country; expand any row to see raw RDAP data
• Competitor Threats: Domains where competitors are using your brand name
• Trademark Gaps: Trademarked names that don't have corresponding domain coverage

Export the full report as CSV for your legal team with one click.

What v1 Taught Me

What's Next

v1 validates the core hypothesis: AI can map a brand's domain exposure in minutes, for free, without an attorney. The most requested extensions point clearly to v2:

v1.1 — Persistence (Next):

• Persistent scan history with user accounts (Clerk auth)
• External state store (Redis) to replace the in-memory Map for multi-instance production scaling
• Brand Domain Protection Score — a single 0–100 score for any company, suitable for embedding in board reports

v2.0 — Monitoring (Future):

• Weekly monitoring cron with email diff alerts ("3 new squatters appeared this month")
• Bulk upload — scan 50 brand names from a CSV, useful for agencies
• Social handle monitoring — extend competitive intelligence to Twitter/X, Instagram, LinkedIn

v1's job was to prove the concept and ship something real. It did.

Try It

The product is live at brandguard-reachmayankagarwal.vercel.app. Try the Nike demo — no account or API key needed — to see the full output in under a minute.

The source is open at github.com/reachmayankagarwal/brandguard if you want to run your own instance or adapt the multi-agent architecture for a different domain.