PH Radar BI is now live.
by•
What started as a Product Hunt companion has become a BI layer for launches.
Custom dashboards, momentum, opportunity radar, hunter analytics, repeat launches, race replay, maker responsiveness — and more.
Special thanks to @oshylabs and everyone in this forum whose feedback shaped a lot of this — repeat launches and the responsiveness signal came straight out of conversations here. (The responsiveness metric even caught a question I'd missed on my own launch.)
What's still missing? If you could add one metric to Product Hunt itself, what would it be?
42 views
Replies
This is the right build, and the badges are clean. One trap to design around before it ships: absence of a detected update is not evidence of death.
Plenty of real products sit on a static marketing page with no blog, no changelog and no public commits, yet ship constantly behind a login. If the crawler reads silence as decay, your most heads down builders get punished for not performing in public. I would keep site is live as the hard binary and treat recent updates as a positive signal that adds confidence, never a negative one that revokes it. A live site with no visible changelog is unknown, not dead.
Two edge cases worth handling early. A domain or brand change reads as a dead link but is often a pivot that worked, so a rename is not a death. And a parked or expired domain should score differently from a 200 that still serves the product. Get those right and the 90 day survivor badge becomes a number people actually trust. Good to see it going in.
@oshylabs @Arnold Oshenye
This nails a bias I hadn't caught: silence isn't death. Redesigning around it—
Site-alive stays the hard binary (dead = truly unreachable or parked/expired
domain, not just "no changelog"). Recent updates become a positive-only signal:
they add confidence, never subtract it. A quiet SaaS behind a login gets
"Still Alive," not "presumed dead."
Also building in your two edge cases:
- Domain/brand change → tracked as "Rebranded," not death (follows redirects,
checks if the new domain still serves a real product)
- Parked/expired domains scored separately from an actual 200 serving the product
Three states now instead of two: Dead / Alive (unverified) / Actively Maintained.
This is the second time you've sharpened this feature before it shipped.
Appreciate the rigor—makes the badge something people can actually trust.
@m_m_carvalho Three states is the right shape for this. One more edge case worth stress testing: a crawler getting blocked by a WAF or aggressive bot protection will look identical to a genuinely dead site if you are reading response codes alone. That is the same bias we just fixed for silent updates, just showing up on the infrastructure side instead of the content side. Worth a distinct state, or at least a confidence flag, for could not verify due to blocking rather than folding that into Dead. Good shipping, will keep testing it against a few of mine.
@oshylabs You called it — and we'd already hit this exact false positive without
realizing it was the same bias. When we tested the checker against
producthunt.com itself, it came back "403" and we tagged it dead — turns out
that was Cloudflare's bot challenge, not PH being down. Same silent-update
bias, just showing up on the infra layer instead of content, exactly like
you said.
Fixed: added a third state, "blocked" — distinct from "dead". Triggers on
403/429/503 combined with either a Cloudflare header (cf-ray) or known
challenge-page markers ("just a moment", "checking your browser",
"attention required", captcha pages, etc). A WAF block now reads as
"could not verify," never as "dead."
Tested it live against producthunt.com just now — correctly comes back
"blocked," not "dead." Would've shipped a real bug without this.
You've now caught two blind spots before either shipped. Appreciate the
adversarial testing — keep throwing it at yours, it's making this better
each round.
@m_m_carvalho That is a clean three state model. One more that will bite: client rendered sites. A raw fetch returns 200 with an almost empty shell, so alive holds, but any changelog or version check that reads the HTML finds nothing and the product looks frozen. Same false negative as the WAF case, one layer up. Cheapest guards are a rendered check on a sample, or reading a sitemap or feed last modified date instead of the page body. Get that in and the survival badge is genuinely trustworthy. Good work shipping it.
@m_m_carvalho Congrats on shipping it, and the thanks runs both ways. That back and forth sharpened how I think about what a launch actually signals.
One metric PH itself is missing: survival. Does the product still have a live site and a shipped update ninety days after launch day? Most launches are dead links within months, but the leaderboard treats day one as the whole story. A simple still alive at 90 days marker would tell people which launches became real products and which were launch day theatre. It is the one number that separates a milestone from a tombstone, and PH already holds the data to compute it.
@oshylabs @Arnold Oshenye
You nailed it. That's exactly the gap—PH celebrates day 1, but the real metric is day 90.
We're adding this to PH Radar PRO: Product Longevity
How it works:
- Automatic crawler checks if the product's site is still live
- Detects recent updates (changelog, blog, public commits, social activity)
- Badges: "Still Active", "90-day Survivor", "Recently Updated"
- Historical view: track which launches became real products vs which were theater
The insight you pointed out sharpens everything. Launch signals don't mean much
without the follow-through metric. A product that ships updates 90 days later
tells a different story than the rank ever could.
Thanks for the back-and-forth—it pushed us to build something that actually
separates signal from noise.
Launching in the next release.
Live on Chrome + Firefox — free to explore. Link: https://nodus-ai.app/ph-radar/ Happy to break down how any metric is computed.