> Source: https://upvera.tech/guides/show-traction-without-numbers/
> Show evidence that a system you don't control produced, not figures you type. Give revenue as a band read through a read-only connection, show a dated release history in which commits, builds and store versions confirm each other, and prove that you own every source you point to.

[Guides](/guides/)How-to

Guide · · For founders · Proof Engine

# How to show startup traction without revealing your numbers

Short answer

Show evidence that a system you don't control produced, not figures you type. Give revenue as a band read through a read-only connection, show a dated release history in which commits, builds and store versions confirm each other, and prove that you own every source you point to.

## What people are really asking

Someone deciding whether to take your startup seriously wants to know two things: is it real, and is it moving? An exact figure answers neither well. They can't check it, it is stale next month, and once it is public you can't take it back.

Evidence answers both questions. Good evidence has three properties: a system you don't control produced it, it carries a date, and you can show the source is yours. Everything below follows from that.

## Step 1: prove you own the sources

A link to a repository or an app listing proves nothing until you show it is yours. The common methods:

-   **A DNS TXT record** on your domain. Only someone who controls the domain's DNS can publish it. Google Search Console verifies sites the same way.
-   **A file at a well-known path**, such as `https://yourstartup.com/.well-known/<name>.txt`. The `/.well-known/` prefix is a standard location defined in RFC 8615.
-   **An app installed on your GitHub organization**, which only an owner of the repositories can approve.

Anyone can read a TXT record:

```bash
dig +short TXT yourstartup.com
```

Ownership is the step most people skip, and it is the one that turns "here is a link" into "here is my work". The [DNS TXT guide](/guides/dns-txt-verification/) covers the details.

## Step 2: replace revenue with a band

A band says how big without saying exactly how big. Two rules keep it honest:

1.  **Fix the band edges before you look at your number**, and publish them. Edges chosen after the fact can always be drawn just below your figure.
2.  **Let a read-only connection read the figure, not you.** Stripe restricted API keys, RevenueCat's OAuth connection and limited App Store Connect roles all let a third party read billing data without the power to change it. Whoever checks reads the figure and reports only the band.

An example set of edges (not Upvera's):

| Band | Revenue over the last 28 days |
| --- | --- |
| 1 | Some revenue, under $1,000 |
| 2 | $1,000 to $10,000 |
| 3 | $10,000 to $50,000 |
| 4 | Over $50,000 |

Use a rolling window rather than one calendar month, so a single large invoice doesn't define you.

## Step 3: show a shipping chain, not a promise

The strongest progress evidence is a chain in which each step confirms the one before it:

```text
2026-10-02  commit 4e1a9c2 "Add CSV export"        your repository
2026-10-03  build 1.8.0 (42) made from 4e1a9c2     your CI
2026-10-06  version 1.8.0 live, "Export to CSV"    App Store
```

Tag releases in git, publish them as GitHub Releases, and write store release notes that match. Keep a public changelog with a date on every entry. Six months of weekly releases that line up across three systems says more than a user count, and it reveals nothing about revenue.

## Step 4: let age, uptime and team speak

-   **Age.** Your domain's registration date is public through RDAP. The App Store shows a version history with dates, and Google Play shows when an app was last updated. "Since 2024" stops being a claim.
-   **Uptime.** If you run a public status page, its incident history shows that the product runs, and how you behave when it doesn't.
-   **Team.** "Five engineers" is a claim. Five people with commits in your organization is evidence. Signed commits carry a "Verified" badge on GitHub.

## Step 5: timestamp what you publish

If you send a monthly update, timestamp it, for example with the OpenTimestamps client:

```bash
ots stamp update-2026-10.md
ots verify update-2026-10.md.ots
```

Later, anyone can confirm the file existed on that date and has not been edited since. A timestamp proves when, not that the content is true, so pair it with the evidence above.

## What not to do

-   **Screenshots of dashboards.** Easy to edit, undated and impossible to trace to a source.
-   **Self-reported numbers** in decks or profiles. A figure exact to the unit with no source looks weaker, not stronger.
-   **Vanity metrics.** Signups, page views, waitlists, cumulative charts that can only go up, and package downloads presented as users. npm itself says its counts include build servers, mirrors and robots.
-   **Full-access keys** handed over to "prove" something. Read-only, always.
-   **Backdated history.** Git lets anyone set any commit date. GitHub's activity view shows when pushes really happened, and careful readers look.

## Questions

### Is a band enough for angels or venture firms?

It is enough to start the conversation. Later, in diligence, you may give exact figures privately under an agreement. The band is what you show in public.

### What if there is no revenue yet?

Lead with the shipping chain, the age of your sources and a verified team. A store ratings count and design partners named with their permission add to it.

### How wide should the bands be?

Wide enough to keep the exact figure private, narrow enough that moving up a band means something. Bands whose upper edge is a few times the lower edge are a reasonable start.

### Does a release history tell competitors too much?

It tells them your pace, not your numbers. If a feature is sensitive, ship it first and write the release note afterwards; the release date stays true either way.

## How Upvera does it

On an Upvera startup page, traction comes only from the startup's own sources. 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 ownership is verified: by a DNS TXT record `upvera-verification=<code>` at `_upvera.<domain>` or on the domain itself, by a file at `/.well-known/upvera-verification.txt`, or by a GitHub App installed by the repository's owner. Revenue is read through RevenueCat or App Store Connect with read-only access 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. 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](/proof/).

## Sources

-   [Stripe, API keys and restricted keys](https://docs.stripe.com/keys)
-   [RevenueCat, API keys and OAuth for third-party clients](https://www.revenuecat.com/docs/projects/authentication)
-   [App Store Connect, role permissions](https://developer.apple.com/help/app-store-connect/reference/account-management/role-permissions)
-   [Google Search Console, verify your site ownership](https://support.google.com/webmasters/answer/9008080)
-   [RFC 8615, well-known URIs](https://www.rfc-editor.org/rfc/rfc8615.html)
-   [ICANN registration data lookup (RDAP)](https://lookup.icann.org)
-   [GitHub, about releases](https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases)
-   [GitHub, the activity view](https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/using-the-activity-view-to-see-changes-to-a-repository)
-   [GitHub, commit signature verification](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification)
-   [Keep a Changelog](https://keepachangelog.com/en/1.1.0/)
-   [npm, how download counts work](https://blog.npmjs.org/post/92574016600/numeric-precision-matters-how-npm-download-counts-work.html)
-   [OpenTimestamps client](https://github.com/opentimestamps/opentimestamps-client)

## Related

[UTR-26-01**Proof Engine**Work read at the source. Never typed in.System reportRead](/proof/)[Tool**Check a domain's TXT records and verify you own it**Look up any domain's TXT records from your browser, see which verification tokens are live, and fix the mistakes that make verification fail.FoundersUse it](/guides/dns-txt-verification/)[Guide**How to check a startup's claims before you believe them**A checklist with public tools for domain age, site history, store listings, code, packages, team and revenue, plus red flags.Anyone checkingRead](/guides/check-startup-claims/)[Guide**How to verify an OpenTimestamps proof**Check an .ots proof with the official client, read pending and success results, and know what a timestamp proves and what it does not.Anyone checkingRead](/guides/verify-opentimestamps/)