track-startup-competitors

Track Startup Competitors

Build durable competitive intelligence from public evidence. Search broadly, conclude conservatively, and keep every observation, change, inference, and recommendation traceable to its source.

Language

• Conduct research, analysis, labels, exports, and reports in English.
• Preserve non-English source text separately from a labeled English translation.
• Never translate, paraphrase, or summarize a statement and present it as a verbatim quote.

Read the relevant references

• Read references/source-strategy.md before researching any competitor.
• Read references/identity-and-deduplication.md before resolving domains, handles, repositories, people, or duplicate coverage.
• Read references/evidence-and-confidence.md before classifying observations, changes, or inferences.
• Read references/impact-scoring.md before ranking changes or recommending a response.
• Read references/snapshot-schema.md before creating or updating a snapshot.
• Read references/report-schema.md before generating the analysis JSON or report.
• Read references/research-safety.md before accessing social, community, archived, blocked, or login-gated sources.

Choose the mode

• baseline — Create the first verified snapshot. Never claim change detection without an earlier comparable snapshot.
• pulse — Find material activity within a stated window, normally 7 or 30 days.
• compare — Compare two saved snapshots and explain confirmed additions, removals, and modifications.
• deep-dive — Investigate one competitor across all accessible public source groups.
• market-shift — Find a pattern supported across multiple competitors without treating correlation as causation.
• watchlist — Refresh every competitor and produce a change map. Do not schedule recurring runs unless the user explicitly asks.

Run the workflow

1. Establish the watchlist

• Inspect the startup URL, supplied competitor list, previous snapshots, and existing research before asking questions.
• Record the startup's product, target segment, geography, business model, and decisions this research should inform.
• Resolve each competitor's canonical name, domain, public social handles, GitHub organization, product names, and known aliases.
• Keep direct competitors, adjacent alternatives, incumbents, and substitutes visibly separate.
• Ask only for missing context that materially changes the scan or response.

2. Create a source plan

• Search official product surfaces first, then code and release surfaces, search discovery, social and community sources, company signals, and archives.
• Allocate a bounded source budget per competitor. Prioritize material surfaces over exhaustive low-value crawling.
• Record every attempted source group as available, partial, blocked, not_found, or not_applicable.
• Treat Google and other search results as discovery only. Open the underlying page before using it as evidence.
• If X, LinkedIn, a review site, or an archive is inaccessible, mark it unavailable. Never reconstruct missing content from snippets or memory.

3. Build an immutable evidence ledger

• Create one evidence item per source observation with a stable ID.
• Preserve source URL, source type, authority, competitor, captured time, published time when available, title, exact short excerpt, normalized observation, and access status.
• Separate facts from public opinions and from analyst interpretation.
• Prefer primary sources. Use secondary sources to discover or corroborate, not to overwrite official evidence.
• De-duplicate syndicated announcements, reposts, copied reviews, mirrored documentation, and the same claim repeated across pages.

4. Create or refresh the snapshot

• Represent every comparable fact as a stable signal key such as pricing:pro:monthly, positioning:primary-audience, or github:api-sdk:latest-release.
• Store normalized values separately from display text.
• Cite the evidence IDs behind every signal.
• Preserve unknown values as unknown; absence of evidence is not evidence of removal.
• Save the snapshot before interpreting it.

5. Detect changes deterministically

• When two snapshots exist, run:

node track-startup-competitors/scripts/compare_snapshots.mjs <previous.json> <current.json> <changes.json>

• Treat a signal as added, removed, or modified only when both snapshots had comparable source coverage.
• Downgrade or suppress changes caused by blocked pages, missing scans, reordered text, cookie banners, dates, counters, tracking parameters, or cosmetic markup.
• Never claim that a strategy changed solely because a page changed.

6. Corroborate and interpret

• Classify each item as confirmed_change, corroborated_signal, unconfirmed_signal, community_reaction, or noise.
• Connect signals only when their timing, entity identity, and business meaning align.
• Label strategic interpretations explicitly as inferences.
• Look for counter-evidence and unchanged signals that weaken the interpretation.
• Distinguish what changed, why it may matter, and what remains unknown.

7. Score impact and choose a response

• Score relevance, magnitude, strategic proximity, commercial consequence, persistence, evidence strength, and urgency.
• Keep confidence separate from impact. A high-impact rumor remains low confidence.
• Place each change into act, investigate, watch, or ignore.
• Recommend customer research, measurement, messaging changes, product work, or no action as appropriate.
• Never recommend copying a competitor merely because it launched something.

8. Create the deliverables

• Save snapshots as competitor-radar/snapshots/<date>-<watchlist-slug>.json.
• Save the structured analysis as outputs/<startup-slug>-competitor-analysis.json.
• Generate the interactive report:

node track-startup-competitors/scripts/generate_report.mjs <analysis.json> <report.html>

• Export the evidence ledger:

node track-startup-competitors/scripts/export_evidence.mjs <analysis.json> <evidence.csv>

• Save the report as outputs/<startup-slug>-competitor-change-map.html.
• Save the ledger as outputs/<startup-slug>-competitor-evidence.csv.
• Create outputs/<startup-slug>-response-brief.md when the analysis supports actionable responses.
• Return clickable absolute links to every artifact.

9. Verify before delivery

• Open the report and test search, filters, evidence links, responsive layout, and empty states.
• Confirm that every displayed change points to both old and new evidence when applicable.
• Confirm that every inference is labeled and includes counter-evidence or uncertainty.
• Confirm that blocked sources are shown as coverage gaps, not silently omitted.
• State the strongest confirmed move, the most important weak signal, the most dangerous uncertainty, and the next monitoring step.

Enforce research integrity

• Never bypass authentication, private accounts, paywalls, CAPTCHAs, robots restrictions, or access controls.
• Never invent a post, page, price, release, quote, date, handle, metric, or archived version.
• Never use a search-result snippet as final evidence.
• Never treat stars, followers, likes, hiring counts, or posting frequency as business success without support.
• Never treat a feature announcement as proof of availability, adoption, quality, or revenue impact.
• Never treat community sentiment as representative market research.
• Never infer a removal when the current source was blocked or not scanned.
• Prefer INSUFFICIENT_EVIDENCE to a confident unsupported conclusion.

Default report order

1. Executive market pulse
2. Coverage and source health
3. Material changes
4. Market movement timeline
5. Cross-competitor themes
6. Act / Investigate / Watch / Ignore board
7. Competitor profiles
8. Uncertainty and counter-evidence
9. Filterable evidence ledger
10. Snapshot and methodology details