Skip to content
howmuchuserswtf
Sign in

How we verify

A public number has to be able to explain itself

This isn't a promise of trust — it's the exact list of mechanisms running in this product today, with what each one stops and what it doesn't. None of this accuses anyone in public: it lowers an internal trust score, and below a threshold that startup drops out of the rankings without its profile ever hiding its real numbers.

Every project has a real owner

Creating a HowMuchUsers account goes through Google — no anonymous signup, no throwaway email. This does NOT prove a project's numbers are real: the mechanisms below do that. It proves there's an identifiable person behind every account, and nobody competes in the rankings hidden behind an empty form.

Google accountidentifiable owner

Only the owner can create users

Two keys, two permissions. The public one lives in anyone's browser — with it, nobody can create or delete a user. Only the secret key, which never leaves your server, can do that. So if a number gets inflated, it can only be the project's own owner — never a third party.

Public key→ user.created →rejected
Secret key→ user.created →accepted

Every person counts once

The same user sent twice, ten times, or a thousand times still counts once. It's not a business rule you can route around: it's a unique index in the database — resending the same signup doesn't duplicate anything, even if the integration is broken and keeps retrying.

usr_42counted
usr_42already counted
usr_42already counted

Dates that don't add up get dropped

A signup dated in the future, or sent as if it happened more than ten years ago, gets rejected on the spot — it's the simplest way to fabricate a growth curve that never happened, and it never even gets saved.

in the futurerejected
11 years agorejected

A burst gets flagged

More than 200 new signups in 10 minutes for the same project isn't rejected — a real startup can have a real spike — but it does get flagged. No integration this size needs that pace from real people.

flagged

Cohorts that never come back, too

A thousand users created and never seen again — no session, no activation, ever — get compared against the project's own history, never against a fixed number. If that same startup DOES have real users who come back in other cohorts, one that never does stands out.

real cohort
suspect cohort

Three days, ten users minimum

Nobody enters a ranking the same day they sign up. It takes at least three days of sending real data and ten users that aren't from a declared import — the minimum time that makes fabricating something expensive and slow instead of free and instant.

123 días

Trust goes down; it never accuses in public

Every suspicious signal costs points off an internal score, never in view of anyone. Below the threshold, that startup drops out of the rankings — but its profile keeps showing its real numbers. Nobody gets called a cheater automatically: someone on our side reviews the evidence before anything is final.

88
−12 · velocity
Some numbers need a second look before this project can compete.

Verification is earned, not granted

Four levels, and each one describes exactly one checkable fact — none of them says "these users are real people", because we can't check that, and saying it would be faking verification.

Not connectedAPI connectedHistory importedContinuous data

What this doesn't solve, said plainly

A startup running its own server can fabricate believable, sustained signups over weeks, carefully. There's no purely automatic check against that — only external verification, which doesn't exist for this product yet. What these mechanisms do achieve is making inflating a number expensive and slow, never free or instant.

Platawtf1KFrambuesa97