How we check

Browser render check

An HTTP 200 says the server answered. It says nothing about whether the page rendered. A blank page that loads instantly looks identical to a working one from the network layer.

The render check loads each listing in a real Chromium browser, waits 6 seconds for client-side rendering to finish, and reads the resulting DOM. It records whether the page had meaningful text or interactive elements, and logs any JavaScript errors thrown during load.

• What it confirms

  The page loaded and rendered in a real browser, on the date shown. That is the claim and nothing more.

• What it does not tell you

  Quality, speed, security, or whether the app's features work. A page can render fast and still have a button that does nothing.

• Route discovery

  We collect links from the landing page and follow up to 4 of them. If the navigation is behind a menu or loads lazily, we may only check 1 page — we say so explicitly and never imply coverage we did not achieve.

• Platform-embedded apps

  Some apps run inside an iframe on a platform page (itch.io games, browser extension stores). We cannot read inside the iframe, so we record this as a coverage limit rather than a failure.

What we refuse to show you

• Popularity rankings

  We have no traffic data we would trust. Trending among what, exactly?

• Usefulness scores

  A 0–100 score built on a handful of saves is fabricated precision.

• Guessed build attribution

  An app only says it was built with a given AI tool if its creator said so. A wrong attribution destroys the trust we are selling.

• Unconfirmed facts dressed as confirmed

  Pricing and signup requirements we inferred are labelled as detected, everywhere they appear.