Honest about the data. Sharp about the ops.
This is a public-data proxy — a decision-support tool, not a source of truth. It turns what users say in public into the actions an ops team would take this week. It never claims access to internal Cluely data.
What it is
- • A live triage layer over public Cluely + Bounty signal.
- • Repeated complaints clustered into the few issues worth acting on.
- • Each issue produces an owner-assigned, source-linked ticket draft.
- • A weekly memo a founder can read in two minutes.
What it is not
- • Not internal data — every claim is a public-signal observation.
- • Not “confirmed broken” — it says retest, never verified.
- • Not a CRM, billing tool, or Bounty clone.
- • Not a vanity dashboard — every number traces back to a real URL.
Where the data comes from
Status is read live from the connector layer — so this page can't quietly claim a source is live when it isn't.
Discrete, dated user complaints for the Cluely + Bounty iOS apps (US/UK/CA). The backbone of the live signal.
Community threads on r/Cluely + Cluely/Bounty search, via free RSS (no paid key). Real recent chatter and creator questions.
Dated public reviews (refunds, cancellations, billing) read from the public page — the strongest billing-trust signal.
Coverage layer — surfaces third-party articles/discussion. Used to widen context, not as discrete inbox complaints.
First-party page snapshots (terms, pricing, policy copy) to compare what's claimed vs. what users report.
“Seed” means a curated public-excerpt baseline ships so the tool is never empty; “Live” means the connector is actively pulling fresh public signal on each run.
How often it refreshes
A scheduled job re-scrapes every source and persists the results. Cadence is tuned to how fast public signal actually moves — and to respect each source's rate limits and any per-call cost. Scraping every few seconds would get the tool rate-limited and waste spend for zero new signal.
Cost-control by design: a connector that just failed isn't retried in a loop, one source failing never aborts the batch, and everything degrades to the seed baseline rather than showing an empty screen.
How an issue gets to the top
1. Cluster. Individual complaints are grouped into repeated problems by surface and issue type — so four people hitting the same login wall become one ranked issue, not four lines of noise.
2. Rank by fire score. Issues are ordered by severity, weighted by recency (a complaint from today outranks an old one) and by corroboration — the same problem showing up on Reddit and Trustpilot and the App Store counts for more than volume from one place.
3. Freshness vs. the latest release. Each issue is checked against the current shipped version (today: Cluely v1.2.6, Bounty v2.1.7). If every complaint predates the latest build, it's flagged Possibly fixed — retest; a complaint dated after the build stays Recent. Critical issues are never auto-marked fixed.
4. Resolution status. Each cluster gets an honest, date-derived state — Open, Likely resolved – retest, or Re-opened when a complaint recurs after a release that should have fixed it. All computed from public dates; none of it asserts internal verification.
The honesty rules
- • Every signal keeps its real public URL and capture date attached.
- • Language is always “public signal suggests,” never “confirmed.”
- • A general release is never assumed to resolve a critical.
- • Live signals the matcher can't place are shown, not hidden.
What “confidence” means
The percentage on a cluster is an evidence-strength estimate — how strongly the public signal supports the issue being real and worth triage. It is computed from how many distinct public sources corroborate it, how much signal there is, and how recent it is, and it recomputes as live signals attach. It is explicitly not a claim about internal severity or a model probability.
Built as a working artifact, not a pitch. Data as of the latest scrape — public signal only, not internally verified.