How to Verify a Startup's Revenue (and Prove Your Own)

Revenue claims are everywhere: in launch posts, bios, course ads, marketplace listings for small businesses. Some are real, some are rounded generously, and some are a browser's dev tools and ten seconds of editing. This guide covers how to judge a claim you see, and how to make your own claim easy to trust without handing anyone your login.

Why screenshots prove little

A screenshot of a Stripe dashboard shows that someone had an image. It can be edited in a browser before it is captured, cropped to hide refunds, or picked from the one great week. It is out of date the moment it is posted. None of that means a given screenshot is fake. It means a screenshot alone cannot settle the question.

Signals that a claim holds up

When you read a revenue claim, look for:

• Consistency over time. A founder who has posted monthly numbers for a year, flat months included, is much more credible than one big number.
• A defined metric. "$8k MRR" is a claim you can reason about. "$8k" alone could be one month, one launch or all-time. See MRR vs revenue.
• Plausible math. Price times customers should land near the claim. A $9 product at $50k MRR needs over 5,500 paying customers; does the rest of the story fit that? The MRR calculator helps.
• A source you can check. A figure read straight from the payment provider, shown by a third party, is the strongest public signal.
• Selling something about the number. Treat revenue claims in course or coaching ads with more care. The incentive runs one way.

Levels of proof

From weakest to strongest:

1. A typed number in a bio or post.
2. A screenshot of a dashboard.
3. A screen recording of logging in and navigating, which is harder to fake but still a moment in time.
4. A read-only connection shown by a third party: a tool that reads the figure from Stripe, Paddle, Lemon Squeezy and so on with a limited key, and displays it publicly. It updates itself, and the person cannot edit the number.
5. Direct access for due diligence: when buying a business, a buyer typically gets read access to the payment provider and bank statements, often through a broker or marketplace process, alongside an accountant's review.

Levels 4 and 5 are different tools for different jobs. Public verification is for trust at a glance. Due diligence is for money changing hands, and a public figure never replaces it.

How read-only verification works

Payment providers let you create API keys with limited permissions. A Stripe restricted key can be given Read access to Subscriptions and Charges only, so it cannot create charges, issue refunds or move money. Paddle and RevenueCat keys can be limited the same way; Shopify apps can be limited to the read_orders scope.

A verification tool uses that key to calculate a figure the same way for everyone, and shows it with a mark saying where it came from. The key holder never types the number, which is the point. We define the idea in what is verified revenue.

Two honest caveats. First, verification proves the figure in the connected account, not that every dollar is organic; a founder could, in theory, pay themselves. Consistency over time is still the best defense. Second, some providers' keys cannot be limited to reading (Lemon Squeezy and Gumroad among them), so a trustworthy tool says that plainly and only ever reads.

Making your own revenue verifiable

1. Create a read-only key with your provider: Stripe, Paddle, Lemon Squeezy, Gumroad, RevenueCat or Shopify.
2. Connect it to a tool that shows the figure publicly with its source.
3. Link that page wherever you mention revenue: your bio, your monthly updates, your launch posts.
4. Keep it connected through the flat months.

On makerhandle that takes a couple of minutes per project, and the figure shows with a check mark on your page, its own project page and the leaderboard. See verified revenue for every provider, or the step by step guide to showing verified MRR for Stripe. It is free, and the key is encrypted at rest and never shown again.