Standing up a competitive intelligence dashboard in a week

Most competitive intelligence work is one analyst, two browser windows, and a Notion doc nobody else reads. The signal is real. The format is wrong. By the time the analyst has clipped the screenshot, written the summary, and pinged Slack, the moment is gone.

A competitive intelligence dashboard fixes the format. The signal is captured automatically, scored against rules the team writes once, and surfaced in the place product and marketing already look every morning.

We ship this kind of dashboard in a week. It is the same pattern every time. This is what we build and why.

What a competitive intelligence dashboard actually does

The job is small and specific:

• Watch a defined set of competitor surfaces. Pricing pages, changelogs, careers, blogs, status, app store listings, ad creative.
• Detect material changes. Not every diff. The ones that mean something.
• Score each change so the analyst opens the right ten things per week, not the wrong hundred.
• Deliver a digest at the cadence the audience already lives on.

That is the entire dashboard. Anything beyond it is decoration. Decoration kills opens.

The data model that scales

Three tables do most of the work:

The discipline is keeping signals separate from snapshots. Snapshots are immutable and noisy. Signals are curated and small. The dashboard reads signals. The analyst occasionally drills into snapshots when something looks off.

A fourth table, watchlists, lets each user follow a subset of competitors so the digest is personalized without forking the data layer.

Five tables total. No more. The instant the schema sprawls, the dashboard slows down and the analyst goes back to browser tabs.

How we scrape

We use Firecrawl for the actual fetch. Three reasons: it handles JavaScript-heavy pages, it gives clean markdown back, and it does not get blocked the way naive scraping does after week three.

The pattern:

• Schedule a scrape per source on a cadence that matches the surface. Pricing once a day. Changelog every six hours. Ad creative every twelve hours.
• Hash the cleaned output. If the hash matches the last snapshot, nothing happened. Skip the diff.
• If the hash changed, diff against the last snapshot. Feed the diff into the scoring step.

The hash check saves most of the compute. Most pages do not change most days. Detecting that cheaply is what makes the dashboard affordable to run.

Scoring signals so the right ten surface

This is the part that decides whether the dashboard gets opened. Without scoring you ship a firehose. With scoring you ship a feed.

Three layers of scoring, in order:

1. Material change detection.

Layout-only changes are filtered out. Word changes count. Number changes count more. New sections count most. The rule we ship is:

A change is material if it would survive a 30-second scan by the analyst.

In practice, the analyst writes the first ten "what counts" rules in a single sitting. The dashboard learns the rest from which signals get clicked into vs ignored.

2. Topic categorization.

Every signal gets a topic: pricing, product, hiring, messaging, partnerships, support. The topics are not fancy. They map to the questions the team will ask the analyst on Monday.

3. Priority scoring.

A pricing change on a direct competitor is a 10. A blog post on a tangential competitor is a 2. The exact scoring is a table the team owns and edits monthly. The dashboard does not invent priority. It applies the team's rules.

Together: the analyst sees a feed of 30 signals a week instead of 800.

The refresh cadence that holds up

Daily for most surfaces. Hourly for pricing and changelogs during active competitor launches. Weekly for slow-moving surfaces like careers pages or annual reports.

The mistake teams make is running everything at the same cadence. Hourly across the board is expensive and noisy. Weekly across the board misses the launches that matter. Per-source cadence is what we ship.

The cadence is written in the sources table next to the URL. The scrape job reads it. No special cases. No code paths per competitor.

The digest that actually gets opened

The dashboard itself gets opened a few times a week. The digest gets opened every day. The digest is the format.

What works:

• One email at 8am, before the day starts.
• Three sections: must-read, worth scanning, low priority.
• Three bullets per signal, max. Headline, what changed, link.
• The "must read" section never has more than five items. If you cannot rank the top five, the scoring is wrong.

What does not work:

• A Slack channel that fires every signal. The team mutes it inside a week.
• A weekly summary. The signal is stale by Wednesday.
• A dashboard with no digest. The dashboard becomes a tool only the analyst opens.

Digest first, dashboard second. The dashboard is the drill-down.

What we explicitly do not build

• No AI-generated commentary in the digest. The analyst writes the takeaways for the top five. Auto-generated takeaways are noise, and the team stops trusting the digest the first time the AI is wrong about a competitor.
• No sentiment scoring on competitor blog posts. Sentiment is decorative. Did the price go up or down is operational.
• No public-facing version. Competitive intel is for the team that owns it. Sharing it externally turns the dashboard into a PR liability.

The week-long build

The cadence we run on every competitive intel project:

• Day 1. Source list workshop with the analyst. We end the day with the sources table populated and the scoring rules written.
• Day 2-3. Firecrawl wired in. Snapshots running. First diffs landing.
• Day 4. Signal scoring live. Topic tagging working.
• Day 5. Dashboard skeleton. Four panels. The digest renders.
• Day 6. Analyst uses the digest for a real morning. We sit next to them. Tune the scoring.
• Day 7. Polish, alerts, deploy. The analyst writes the first real digest from the tool.

Seven days. By week two the analyst has stopped opening competitor pricing pages by hand. That is the success metric.

Want this run on your competitor set?

If you have a competitive intel function that runs on browser tabs and Notion docs, the call is thirty minutes. We design the source list with you and quote the build.

Book a discovery call and bring your current competitor list. The messier the better.