How We Actually Check These Apps

We get asked, reasonably, how we can review 115 apps we've never played. This page lays out exactly what we do, in order, and just as importantly, what we don't do, so you can weigh our reviews against that.

Step one: a domain lookup before we ever open the app

Before looking at a single screenshot, we run the app's domain through an RDAP (the current standard that replaced plain WHOIS) lookup. That gives us the registrar, the creation date, and the expiry date, from which we calculate the domain's age in days as of our check date. Across our September 2026 pass on 115 domains, ages ranged from six days to well over a decade, with a median of 82 days: a spread wide enough that domain age alone tells you a lot before you've read a word of marketing copy.

Step two: a Google Play search, every single time

We search Google Play for the exact app name on our check date. On 26 September 2026, none of the 115 apps in this round were listed. We repeat this step for every app rather than assuming, because listing status can change and because it's the fastest way to confirm an app is relying entirely on direct APK distribution.

Step three: the phone-view visit

We visit the operator's own website using a mobile-device user agent, the same way a real visitor on a phone would land on it, and we look at (without submitting) the homepage and, where reachable, the registration screen. This tells us what bonus figures, sections (slots, Aviator-style crash games, colour-prediction, sports odds), and required fields are shown to a visitor.

Twelve of the 115 sites in this round either errored out or actively blocked our visit: some behind a Cloudflare bot check, some geoblocking outright. When that happens, we say so plainly rather than guessing at what the page might contain.

Step four: grouping apps by shared template

Many of these sites are not custom-built one at a time; they're stamped out from the same underlying page template, sometimes by the same operator running multiple brand names. We group apps into platform families when the registration flow, layout, and page structure clearly match. In this round that produced five named families:

Family	Apps in it
Slot template	20
Normal path	14
Referral code	7
Invite roulette	4
Agency center	4

The remaining 66 apps in our set didn't match a shared template we could confidently group, at least on the surface; each of those looks like an independent build. We also flag when two different app names resolve to the exact same underlying domain, which happened once in this round.

What we deliberately do not do

• We do not create an account. Nothing we publish comes from inside a logged-in dashboard.
• We do not deposit money. We have no first-hand data on whether any specific app actually pays out.
• We do not use or generate an invitation/referral code. See our invitation code guide for why that matters.
• We do not download or run the APK file itself. Our review is based on the public website, not the installed app's behaviour.

How long one review takes, and why that limits scope

Each of the four steps above takes a few minutes per app once the process is set up, but running all four consistently across 115 separate domains, on the same day, so the ages and Play Store results are comparable to each other, is most of the actual work behind this site. That's also why our reviews are dated: a domain age, a Play listing status, and a homepage's content are all things that can change the following week, and we'd rather label a review with its check date than imply it's permanently current.

How we decide what counts as a "signal"

When we note something like an invitation code box, a bonus figure, or an 18+ tickbox on a review, it's because that exact text or field was visible on the page we visited, not something we inferred from the app's category or name. If a fact isn't directly visible in what we captured, we leave it out rather than assume it based on similar apps.

What we do when a site blocks every visit

Some sites returned the same block on repeat attempts, whether a Cloudflare bot check or a geoblock message. When that happens consistently, we say so directly in the review rather than padding it with generic description, and we treat "this site blocked our check" as a data point in its own right, not a gap to write around.

Why we publish the check date on every page

A domain's age, its Play Store status, and its homepage content are all things that move over time, sometimes within weeks. Labelling every review with the date we actually looked is how we keep that honest: a review from this round reflects 26 September 2026, and if we revisit an app later, any updated figures will carry their own new date rather than silently overwriting the old ones.

What that means for how much weight to put on a review

Our reviews describe what a domain's paper trail and a public-facing homepage show on one specific date. They are not, and can't be, a verdict on whether a given app will pay a given user on a given day. Use our checklist alongside a review, not instead of your own judgement.