Track Product Hunt Vote Velocity for Launch Detection (2026)

Thirdwatch's Product Hunt Scraper makes SaaS launch-detection a structured workflow with pay-per-result pricing — hourly vote-velocity tracking, breakout-launch alerts, category-segmented insights. Built for B2B SaaS investors, growth marketers, competitive-intelligence teams, and indie-hacker research platforms.

Why track Product Hunt vote velocity

Product Hunt is the canonical SaaS launch-discovery source. According to Product Hunt's 2024 report, the platform launches 100K+ products annually with top-3 daily launches typically exceeding 500 votes by midnight PT — providing real-time signal for breakout SaaS products. For B2B SaaS investors + growth marketers + competitive-intelligence teams, real-time vote-velocity tracking surfaces breakout launches before mainstream tech-press coverage.

The job-to-be-done is structured. A B2B SaaS investor scouts breakout launches daily for early-stage portfolio additions. A growth-marketing team tracks competitor launches to inform content + ads strategy. A SaaS competitive-intelligence function monitors category-level launches for product-strategy decisions. An indie-hacker research platform surfaces breakout launches to subscribers. All reduce to hourly per-launch queries during launch-day windows.

How does this compare to the alternatives?

Three options for launch-detection data:

The Product Hunt Scraper actor page gives you raw real-time launch + vote data at the lowest unit cost.

How to track velocity in 4 steps

Step 1: Authenticate

export APIFY_TOKEN="apify_api_xxxxxxxxxxxxxxxx"

Step 2: Hourly snapshots of daily launches

import os, requests, datetime, json, pathlib

ACTOR = "thirdwatch~producthunt-scraper"
TOKEN = os.environ["APIFY_TOKEN"]

# Pull today's launches every hour during launch-day (PT timezone)
resp = requests.post(
    f"https://api.apify.com/v2/acts/{ACTOR}/run-sync-get-dataset-items",
    params={"token": TOKEN},
    json={"maxResults": 50, "todayOnly": True},
    timeout=900,
)
records = resp.json()
ts = datetime.datetime.utcnow().strftime("%Y%m%d-%H")
pathlib.Path(f"snapshots/ph-velocity-{ts}.json").write_text(json.dumps(records))
print(f"{ts}: {len(records)} Product Hunt launches captured")

50 launches × 24 hourly snapshots = 1200 records — well within budget for a launch-day vote-velocity sweep.

Step 3: Compute hourly velocity per launch

import pandas as pd, glob

snapshots = sorted(glob.glob("snapshots/ph-velocity-*.json"))
all_dfs = []
for s in snapshots:
    df = pd.DataFrame(json.loads(open(s).read()))
    df["snapshot_ts"] = pd.to_datetime(s.split("ph-velocity-")[1].split(".")[0],
                                        format="%Y%m%d-%H")
    all_dfs.append(df)
combined = pd.concat(all_dfs, ignore_index=True)

velocity = (
    combined.groupby(["product_id", "snapshot_ts"])
    .agg(votes=("votes", "first"),
         comments=("comment_count", "first"),
         product_name=("product_name", "first"))
    .reset_index()
    .sort_values(["product_id", "snapshot_ts"])
)
velocity["hourly_vote_delta"] = velocity.groupby("product_id").votes.diff()

# Latest snapshot velocity ranking
latest = velocity[velocity.snapshot_ts == velocity.snapshot_ts.max()]
breakouts = latest[latest.votes >= 200]  # Already at 200+ votes
print(f"{len(breakouts)} launches breaking out today (200+ votes)")
print(breakouts.sort_values("votes", ascending=False).head(10))

Step 4: Alert on breakout-velocity launches

import requests as r

# Alert on launches hitting 50+ votes/hour for 2 consecutive hours
sustained_velocity = (
    velocity[velocity.hourly_vote_delta >= 50]
    .groupby("product_id")
    .filter(lambda x: len(x) >= 2)
)

for product_id, group in sustained_velocity.groupby("product_id"):
    name = group.product_name.iloc[0]
    peak_velocity = group.hourly_vote_delta.max()
    r.post("https://hooks.slack.com/services/.../...",
           json={"text": (f":rocket: Product Hunt breakout: *{name}* — "
                          f"{peak_velocity:.0f} votes/hour peak velocity")})

print(f"{len(sustained_velocity.product_id.unique())} sustained-velocity breakouts today")

Sample output

{
  "product_id": "ph-12345",
  "product_name": "Nimbus AI",
  "tagline": "AI-powered project management for distributed teams",
  "votes": 487,
  "comment_count": 124,
  "category": "Productivity",
  "subcategory": "AI Tools",
  "launch_date": "2026-04-28",
  "maker_name": "Sarah Chen",
  "url": "https://www.producthunt.com/posts/nimbus-ai"
}

Common pitfalls

Three things go wrong in vote-velocity pipelines. Time-zone confusion — Product Hunt resets daily 12:01am PT (8:08am UTC); for accurate velocity tracking, normalize timestamps to PT timezone. Vote-pattern inflation — some launches deploy paid + creator-network vote-acquisition (gray-area but common); cross-reference with comment-quality (real users vs generic "great launch!" patterns) to detect inflation. Category-baseline drift — AI category breakout-thresholds rose 3x from 2023 to 2025; for accurate velocity-ranking, segment per category and use 90-day rolling baseline.

Thirdwatch's actor handles the anti-bot work and proxy rotation so you can focus on the data. Pair Product Hunt with [Hacker News scraping] (custom build) and Reddit Scraper for cross-platform launch verification. A fourth subtle issue worth flagging: Product Hunt's "Featured" curation gives editorial-boosted launches disproportionate first-hour traffic — for accurate organic-velocity research, separate Featured from non-Featured cohorts. A fifth pattern unique to launch-detection: weekend launches typically underperform weekday launches by 30-40% (Product Hunt audience is B2B, weekday-skewed); founders launching on Saturday/Sunday show different velocity dynamics than Tuesday/Wednesday launches. A sixth and final pitfall: launches from established companies (Notion 4.0, Figma Slides) draw 3-5x baseline votes purely on brand-recognition; for accurate "indie breakout" detection, segment by maker-tier (indie vs established).

Operational best practices for production pipelines

Tier the cadence: Tier 1 (active launch-day, hourly), Tier 2 (post-launch week-1 sustained tracking, daily), Tier 3 (long-tail historical research, monthly). 60-80% cost reduction with negligible signal loss when watchlist is properly tiered.

Snapshot raw payloads with gzip compression. Re-derive velocity metrics from raw JSON as your breakout-detection logic evolves. Cross-snapshot diff alerts on category-leaderboard transitions catch breakout-launch signals before mainstream coverage.

Schema validation. Daily validation suite asserting expected core fields with non-null rates above 80% (required) and 50% (optional). Product Hunt schema occasionally changes during platform UI revisions — catch drift early. A seventh pattern at scale: cross-snapshot diff alerts for category-leaderboard transitions (launch entering top-3 within first 6 hours) catch breakout-launch signals before mainstream tech-press coverage. An eighth pattern for cost-controlled teams: implement an incremental-diff pipeline that only re-processes records whose hash changed since the previous snapshot. For watchlists where 90%+ of records are unchanged between snapshots, hash-comparison-driven incremental processing reduces downstream-compute by 80-90% while preserving full data fidelity.

A ninth pattern unique to research-grade data work: schema validation should run continuously, not just at pipeline build-time. Run a daily validation suite that asserts each scraper returns the expected core fields with non-null rates above 80% (for required fields) and 50% (for optional). Alert on schema breakage same-day so consumers don't degrade silently.

A tenth pattern around alert-fatigue management: tune alert thresholds quarterly based on actual investor-action rates. If investors ignore 80%+ of alerts at a given threshold, raise the threshold. If they manually surface signals the alerts missed, lower the threshold. The right threshold drifts as launch-volume + category-saturation evolve.

An eleventh and final pattern at production scale: cross-snapshot diff alerts. Beyond detecting individual changes, build alerts on cross-snapshot field-level diffs — name changes, category re-classifications, status changes. These structural changes precede or follow material events and are leading indicators of organization-level disruption. Persist a structured-diff log alongside aggregate snapshots: for each entity, persist (field, old_value, new_value) tuples per scrape. Surface high-leverage diffs to human reviewers; low-leverage diffs stay in the audit log.

A twelfth pattern: cost attribution per consumer. Tag every API call with a downstream-consumer identifier (team, product, feature) so you can attribute compute spend back to the workflow that drove it. When a downstream consumer's spend exceeds projected budget, you can have a precise conversation with them about the queries driving cost rather than a vague "scraping is expensive" debate.

Related use cases

• Scrape Product Hunt launches for trend research
• Find emerging SaaS tools via Product Hunt
• Track G2 rating changes for SaaS companies
• The complete guide to scraping business data
• All Thirdwatch use-case guides