Case study · interactive demo

Watchdog

A Do Not Call compliance layer for a sales team's CRM. A Chrome extension that blocks the call before it happens, plus an admin dashboard for the shared DNC list, rep permissions, and audit history.

This is a demo build. Every name, company, phone number and email in it is fabricated (555-01xx is the range reserved for fictional use). It ships no credentials and makes no network calls — the dashboard runs the real application code against seeded in-memory data.

Explore

Extension showcase →

Interactive. Pick a scenario, hit Call, and see the block fire. Plus all three popup surfaces.

Admin dashboard →

Fully working. Live tables, role assignment, kill switch, audit log, and warning history per number.

Rep guide →

What a sales rep sees day to day and how to report something the tool got wrong.

Admin guide →

Every dashboard tab explained, with the reasoning behind each one.

Install instructions →

The rollout doc that shipped to the team. OS-specific, with real UI screenshots.

The problem

A single call to a Do Not Call number carries real regulatory exposure. The list lived in a spreadsheet nobody checked mid-call, and there was no way to know whether a number had already been flagged by someone else on the team.

Results

enforcement surfaces: record page, dialer, and pre-dial network layer

~99%

reduction in database reads after moving to incremental sync

6,000+

numbers migrated from CRM exports, deduplicated and normalized

infrastructure cost — runs inside the free tier at team scale

Engineering notes

Detection is line-paired, not text matching. The property label "DNC?" appears on every record, so a naive search self-triggers. Parsing label-value pairs also meant handling a dropdown option that rendered identically to a written note — both were real false positives caught in testing.
Enforcement follows the number, not the record. A number flagged once protects the whole team, including duplicate contacts carrying the same line that were never flagged themselves.
Removals propagate through tombstones. Under incremental sync a hard delete is invisible to a "what changed since X" query, so removal is a soft flag the clients can actually observe.
Security is server-side. Database rules are the boundary, not the UI. Reps can update presence fields on a cached number but cannot change its type, name, or removal state.
Fails safe by default. A failed sync keeps the existing cache and never advances its watermark. The kill switch defaults to protection ON, so a network fault can't silently disable it.

Stack

Chrome Extension (Manifest V3, service worker, content scripts), vanilla JS, Firebase Firestore with rules-based authorization, Firebase Hosting.