How to check a startup's claims before you believe them

#One question for every claim

For each claim, ask: who wrote this record, and could the startup change it? A domain registry, an app store, a web archive or a package registry keeps records the startup can't quietly edit. The startup's own site, deck and screenshots are claims. You don't have to distrust the founders, only know which statements rest on evidence.

#The checklist

1. Domain age and setup

Look up the domain through RDAP at lookup.icann.org: registration date, registrar, last change. If the startup says it has run since 2019 and the domain was registered last spring, ask. There may be a good answer, such as a rename.

DNS tells a story too. From a terminal, or with dns.google in a browser:

dig +short MX example.com
dig +short TXT example.com

Mail records show whether the company runs email on its own domain; TXT records often name the services it has verified. A certificate transparency search, such as crt.sh, lists dated TLS certificates for the domain and its subdomains; the earliest shows roughly when HTTPS was first set up.

2. Website history

The Wayback Machine keeps dated copies of public pages at https://web.archive.org/web/*/example.com. Compare what the site promised a year ago with what it says now. Customer logos, team pages and product claims that appear and then vanish are worth a question.

3. App store listings

App Store pages show a version history with dates; Google Play shows the date of the last update. A team that "ships every week" should have a release history that looks like it. The ratings count is a rough signal of real use: an app said to have a million users and forty ratings needs an explanation. Archived copies of the listing show how that count changed over time.

4. Code and releases

If the code is public, look past the star count to commits, contributors, release tags and answered issues. Stars can be faked: a study of GitHub found millions of suspected fake stars, surging in 2024. Git also lets anyone set any commit date, but GitHub's activity view shows when pushes really happened, so two years of history pushed in one afternoon stands out.

5. Package downloads

For an npm package, the public API gives daily counts:

curl https://api.npmjs.org/downloads/range/last-month/<package>

npm says these counts include build servers, mirrors and robots. Read downloads as a trend, never as a user count.

6. Team

Match claims to visible work: commits, talks, papers, earlier products. In many countries the company registry lists directors and the incorporation date, for example Companies House in the UK. Job titles on social profiles are self-reported.

7. Press and customers

Coverage is not product: a press release is written by the company and often republished word for word. A customer logo is a claim until the customer confirms it. Try the product yourself.

8. Revenue and users

Don't accept a screenshot. Ask for one of these instead:

a read-only view of the billing or analytics tool, opened live while you watch,
a read-only key or connection that a third party uses to report a band,
exact figures in writing, under an agreement, once you are far enough along.

9. Timestamps

A document timestamped with a public service such as OpenTimestamps provably existed on that date. That doesn't make its content true, but it rules out a story written after the fact.

#Claim, check, evidence

Claim	How to check	What counts as evidence
"Founded in 2019"	RDAP record, earliest Wayback capture, company registry	Dates from those records that match the story
"Live on iOS and Android"	The store listings	Listings with dated releases
"We ship every week"	Release tags, store version history, changelog	Dated releases that line up across systems
"10,000 users"	Live read-only view of the analytics tool	A figure read from the tool, not a screenshot
"$50k a month in revenue"	Read-only billing access, or a band from a tool that read it	A band or figure the checker read at the source
"Team of 12 engineers"	Contributors, registry filings, past work	Named people with visible work
"Used by Company X"	Ask Company X	Confirmation from X, not a logo on a slide

#Red flags

Every number arrives as a screenshot, and read-only access is refused.
Figures exact to the unit, with no source.
A domain or listing much younger than the story, with no explanation.
A long commit history pushed in a single day.
A listing last updated a year ago, from a team that "ships weekly".
Downloads or signups presented as users, or only cumulative charts.
Pressure to decide before you have time to check.

#Questions

Is a young domain always a red flag?

No. Renames and domain moves are common. Ask for the old domain and check its history as well.

How do I ask about revenue without sounding hostile?

Ask for the method, not the figure: "Could you show me a band from your billing tool, or a read-only view for ten minutes?"

What if the startup has no public code?

Most don't. Use the domain, the website history, the store listings, the product itself and its customers.

Can a hash or a timestamp prove a claim?

It proves that a document existed at a moment and hasn't changed since. Whether its content is true still needs the checks above.

#How Upvera does it

An Upvera startup page works like this checklist. Sources are read where they live: GitHub, the App Store, Google Play, Vercel, Netlify, npm, PyPI, crates.io, Packagist, Docker Hub, Hugging Face, and analytics and revenue tools. A source counts only after its owner proves it, through a DNS TXT record, a file at /.well-known/upvera-verification.txt or a GitHub App, and it stops counting once its ownership can no longer be confirmed.

Revenue is read with read-only access to RevenueCat or App Store Connect and shown only as a band. A release seals when the commit, its build and the App Store version confirm each other. There is no field for self-reported traction. Each startup page shows which sources are linked and which are verified; a source that isn't connected is not mentioned at all, so if you expected one, ask the founder. Domain verification, revenue bands and the release chain run on Upvera's servers today and reach the app with its next release. The method is in the Upvera Proof Engine report.