Technical

How We Built a Competitor Change Monitor in 24 Hours

April 29, 2026 · 14 min read

When we set out to build Spyglass Tracker, we had a simple goal: detect when competitors change their websites and alert our users before their customers notice. The constraint? We had 24 hours from concept to working prototype.

Here's exactly how we built it: the architecture, the code patterns, the tradeoffs, and the lessons we learned along the way. If you're building your own monitoring tool, this blueprint will save you weeks of trial and error.

The Core Problem

Competitor websites change constantly. Pricing pages get updated. Feature lists get rewritten. Positioning copy gets refined. Enterprise SaaS companies spend $10K+/month on tools that detect these changes. We needed to build something comparable for indie founders — at 1/100th the cost.

The technical challenge breaks down into four sub-problems:

• Fetching: Retrieve competitor pages reliably without getting blocked
• Detecting: Determine what changed between two versions of a page
• Understanding: Categorize changes by type (pricing, features, positioning, etc.)
• Alerting: Notify users about meaningful changes without noise

Architecture Overview

Here's the stack we used and the reasoning behind each choice:

The system runs on a simple scheduled trigger: GitHub Actions pings our trigger endpoint every 4 hours. The trigger finds all active competitors with paid subscriptions, then for each one, runs a check function that follows this pipeline:

1. Fetch the competitor's homepage (8-second timeout, respectful user-agent)
2. Strip HTML tags, extract clean text content
3. Compute a SHA-256 hash of the extracted text
4. Compare against the last stored hash in the database
5. If hash matches → nothing changed, skip
6. If hash differs → send both old and new text to GPT-4o-mini for analysis
7. AI returns a structured summary: what changed, category (pricing/features/positioning/content), impact score
8. Store the change event in the database
9. AI-generated summary is readable by humans immediately — no manual analysis needed

Why SHA-256 Hashing?

We considered several change detection approaches before landing on content hashing:

• git-style diff: Too granular — a single character change in the footer would trigger an alert
• DOM tree comparison: Too complex for serverless, and fragile against layout changes
• Semantic embedding similarity: Over-engineered for the MVP — we can add this later for smarter deduplication
• Content hashing (chosen): Fast, simple, and reliable. Strip HTML → hash text → compare hashes

The key insight: we don't need to detect every pixel change. We need to detect meaningful content changes. By stripping HTML and computing a hash of the semantic content, we avoid false positives from CSS changes, A/B test variations, and dynamic elements like live chat widgets.

The AI Categorization Layer

When a change is detected, GPT-4o-mini analyzes the old vs new text and returns a structured JSON response. Here's the prompt pattern we use:

This costs approximately $0.002 per analysis and turns raw text diffs into actionable intelligence. A change from "Starting at $29/mo" to "Starting at $49/mo" gets categorized as "pricing" with an impact score of 8/10. A blog post title change gets categorized as "content" with a score of 2/10.

Lessons Learned

Building this in 24 hours forced us to make some deliberate tradeoffs:

1. Text extraction is harder than it sounds. Different websites use different HTML structures. Some load content via JavaScript (SPAs), which serverless fetches can't render. For the MVP, we accept this limitation — if a page requires JS rendering, we flag it for manual review. A headless browser solution (like Playwright or Puppeteer) would handle SPAs but adds cost and complexity.

2. Hash comparison is binary. A single character change flips the entire hash. This is by design — it forces us to review every change through AI rather than risk missing something. The AI layer handles the deduplication of minor changes (like whitespace fixes) by returning a low impact score.

3. AI categorization isn't perfect. Sometimes the AI misidentifies the change category. A feature announcement on a blog might be categorized as "content" when it's really a "feature" change. We handle this by storing the raw category and allowing users to provide feedback. Over time, the categorization improves.

4. Rate limiting matters. Even with respectful user-agents, hitting the same competitor site every 4 hours from the same IP can trigger rate limiting. We distribute checks across different times and respect robots.txt directives. For aggressive rate limiters, we back off to once per 24 hours.

What's Next

The MVP was built in 24 hours, but the real product is a continuous evolution. Here's what we're building next:

• Selective element monitoring: Monitor specific parts of a page (pricing section only, feature list only) instead of the full page
• Semantic change detection: Instead of binary hash comparison, use embeddings to understand the magnitude of changes
• Weekly digests: Bundle low-severity changes into a weekly email instead of alerting on every minor update
• Slack/webhook integration: Real-time alerts for high-severity changes via Command tier

The complete source architecture is open for any indie founder to study. We believe competitive intelligence should be accessible, not locked behind enterprise paywalls.

Try It Yourself

Want to see it in action? Our live monitoring dashboard shows real-time competitor change detection. Or start tracking your own competitors with Spyglass Tracker for $79/month.