# Build brief — a focused alternative to Debriefing

> **Verdict:** Partly, if you narrow it · **Buildability:** 48/100 · **Category:** RSS Research
> **Source:** https://www.canitbevibecoded.com/debriefing
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Debriefing. Verify current pricing and capabilities before acting.

## Context

**Debriefing** — Watches your competitors' pages, pricing, changelogs and hiring, then writes the brief with what changed and what to do. It currently costs $80/mo.

Diffing a competitor's pricing page on a cron and asking a model what changed is genuinely an afternoon. changedetection.io will do the watching for you before you write a line. The gap is everything between a diff and a brief. Most page changes are noise: a rotated testimonial, a reordered nav, a CDN hash. Deciding which changes are real, tying them to hiring and funding signals, and turning that into three sentences a founder acts on is judgement encoded over many iterations. Build it and your first month is mostly you deleting alerts about nothing.

This brief describes a focused, single-operator replacement for the part of Debriefing that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

Snapshot each competitor's key pages on a schedule, diff against the last version, and have a model summarise the meaningful changes into a digest.

- Poll feeds, filter entries by rules, and compile a digest worth reading.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- A scheduler and somewhere to keep page snapshots.
- A headless browser for pages that render client-side.
- Patience for the first month of false positives.

### Data and integrations

- An OpenAI or Anthropic API key.
- SMTP or a Slack webhook for delivery.

Each of these needs a real account, credential, or quota. Set them up before writing feature code.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build me a local competitor watch that emails me a weekly brief, to replace Debriefing. Requirements:

- Node 22, TypeScript, SQLite via better-sqlite3, Playwright for fetching, node-cron for
  the schedule. CLI only. No accounts, no telemetry, keys in .env.
- competitors.json lists each rival: name, and the URLs that matter (homepage, pricing,
  changelog, careers). Ship it seeded with 3 competitors and 4 URLs each.
- `watch snapshot` fetches every URL with Playwright, strips scripts, styles, nav and
  footer, converts the main content to plain text, and stores it with a SHA-256 hash and
  a timestamp. Skip storage entirely when the hash is unchanged.
- Diff each new snapshot against the previous one as unified text diff. Discard diffs
  under 40 changed characters, and drop lines matching an editable noise.json of regexes
  (dates, cache-busting hashes, view counts, testimonial rotations).
- `watch brief` sends the surviving diffs for the period to Claude or GPT in one call
  and asks for, per competitor: what changed, why it matters, and one suggested response.
  Require a citation back to the exact URL for every claim, and drop any bullet without
  one.
- Render the brief to Markdown in ~/CompetitorBriefs/YYYY-MM-DD.md and send it via SMTP
  from .env. The file is the source of truth, email is just delivery.
- Keep every snapshot and every brief. `watch history <competitor>` prints that rival's
  changes over time, which is the only way a single diff becomes a trend.
- Out of scope: hiring feeds, funding data, traffic estimates, dashboards and any login
  wall. Public pages only, respect robots.txt, one request per URL per run.
- README: setup, a cron line for the weekly run, the per-brief token cost, and a warning
  that month one is mostly tuning noise.json.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- Noise filtering, which is the actual product: most diffs are rotated testimonials and changed asset hashes, not competitive moves.
- Horizon watch, meaning the substitutes and new entrants you did not think to add to the list.
- The non-page signals stitched into the same brief: hiring, funding, traffic and LinkedIn movement.
- The analytical step from what changed to why it matters to what to do next.
- An archive going back far enough that a change reads as a trend rather than an event.

## What you still own after launch

- Secure credentials, rotate secrets, and handle provider rate limits.
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.

## Risk

**Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost.

Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.

## Existing alternatives

Before building, compare these checked options:

- [changedetection.io](https://changedetection.io) — Tells you a competitor's pricing page moved. Deciding whether that mattered is back to being your job

## Prior art

Working open-source software you can read, fork, or borrow from before starting:

- [changedetection.io](https://github.com/dgtlmoon/changedetection.io) — Apache-2.0 web page change monitor with browser rendering, CSS/xpath filters and notification hooks; the watching layer, ready-made

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/debriefing