How to show startup traction without revealing your numbers

#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:

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 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:

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.
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:

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:

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.