To prove your app's user numbers are real, say exactly what you counted (visitors, sign-ups or active users), over which dates, and from which tool, then keep evidence a stranger could check: an analytics screenshot or shared dashboard, an anonymized user list, and notes from real users. A small number with a clear definition and evidence is more convincing than a big number nobody can verify.
How do I prove my app's user numbers are real?
You built something with AI, people started using it, and now you want to write it on a resume or mention it in an interview. Then you notice a problem: anyone can type "500 users." Recruiters and admissions readers know that too, so a number without evidence is close to worthless, and a big number without evidence can hurt you.
The fix isn't a bigger number. It's a number that can survive one follow-up question.
What do the sources agree on?
There is no official standard for "proving" side-project numbers. Most search results on this are forum threads and resume-tool blogs. But a few solid sources, from very different places, point the same way.
A count means nothing until you say what it counts. Google's own definitions of Analytics metrics separate total users (anyone who triggered any event), active users (people who actually engaged) and new users (first visit or first open). It even notes that new users can exceed active users, because not every new visitor engages. So "500 users" could mean 500 people who opened a page for two seconds, or 500 who used the product. Those are very different claims.
The flattering numbers are usually the weakest ones. In his essay on vanity metrics vs. actionable metrics, Eric Ries uses total website hits as the classic example of a number that feels good and tells you nothing about what to do next. His alternatives are things like cohorts (what happened to the people who signed up in a given week) and per-customer numbers. He also argues that "metrics are people, too": you should be able to trace a number back to real individuals and talk to them. For a student, that's the whole test. If you can name the kind of person behind your number and what they did, the number is real.
Tools filter some fake traffic, but not all of it. Google Analytics automatically excludes known bots and spiders, using a list maintained by the Interactive Advertising Bureau. The same page says you can't turn this off or see how much was removed. A filter that works from a list can only catch what's on the list, so raw page views are never a clean count of humans.
Faking popularity is where the law draws a line. The FTC's 2024 final rule on fake reviews bans buying or selling fake indicators of social media influence, such as bot followers or views, when the buyer knew or should have known they were fake and used them to misrepresent influence for a commercial purpose. A class project may never meet that test. The principle still applies: bought or invented numbers are fake, whatever the setting.
Evidence can be made public. Some analytics tools let you show your numbers rather than describe them. PostHog's documentation, for example, says you can create a link to share a dashboard publicly or embed it on a website.
Where do they go quiet?
None of these sources is about resumes, interviews or students. None tells you what to do when the honest number is 12, or how to separate friends from strangers. Ries writes for startups making decisions, not for students proving something to a reader. That gap is what the rest of this post fills.
The evidence pack: what to keep for each claim
Keep a small folder for each project. Before any number goes on a resume or into an interview answer, it should have a row here.
| Claim | Evidence to keep | What it proves |
|---|---|---|
| "X people used it" | Analytics screenshot showing the metric name and date range | The count exists and what it counts |
| "X signed up" | Export of sign-up dates, with emails and names removed | Sign-ups happened over time, not in one burst |
| "X came back" | A cohort or retention view, or a simple table of repeat visits by week | People found it useful enough to return |
| "Real users, not friends" | A note of how each group found you (a subreddit post, a campus flyer, a Discord server) | Where the users came from |
| "Users liked it" | Short paraphrased notes from conversations, with permission if quoted | There are people behind the number |
| "It's live" | A public link that still works | The product exists |
Three habits make the pack trustworthy:
- Filter yourself out. Your own testing visits, and those of a teammate, aren't users. Remove them or note them.
- Keep the date range on every screenshot. A number without dates can't be checked against anything.
- Count strangers separately. Friends who tried it are fine to mention. Just don't let them be the whole number.
How do you write it on a resume and defend it in an interview?
Write the number with its definition built in:
- Weak: "Built an AI study app with 500+ users."
- Strong: "Built and launched an AI study tool; 140 sign-ups and 35 weekly active users in October 2026 (analytics), mostly from two nursing-student communities."
Then prepare for the follow-up. An interviewer who is curious about a number will usually ask some version of four questions. Have one-sentence answers ready:
- What exactly did you count? "Active users in Google Analytics, meaning people who engaged, not just loaded the page."
- Over what period? "October 1 to 31."
- Where did they come from? "A post in a nursing subreddit and a flyer in the library."
- What did you learn from them? "Most quit at the upload step, so I cut it."
The fourth answer is the one people remember. It shows that the number belongs to real people you paid attention to, which is exactly Ries's point.
If the honest number is small, say so plainly and move to what you learned. A small, defined number with a good story is ordinary for an early product, and it is far safer than a large one that falls apart under a single question.
How STARC handles user numbers
STARC is a small nonprofit, and its one-person company cohort is built around this problem. Each weekly build log reports numbers, and logs need evidence for them. Peer pairs test each other's products. To graduate as Shipped, a student needs at least 10 real users who aren't classmates, friends or family, backed by screenshots, analytics or an anonymized list. Faked data ends participation, and a student with fewer users can still finish as Completed, with a case study that explains why.
The first cohort hasn't run yet, so there are no results to show. The rules are on the How it works page, and common questions are in the FAQ.
The short version
Say what you counted, over which dates and from which tool. Keep a screenshot, an anonymized export and a note of where users came from. Count strangers separately from friends. A number you can defend in one sentence beats a bigger one you can't.
Related questions
Is a small number like 23 users worth putting on a resume?
Yes, if it's real and defined. "23 weekly active users, September 2026, from my analytics" invites a good interview question. A vague "hundreds of users" invites suspicion, especially for a web app, where nobody can check the number from outside.
Do my friends count as users?
They count as people who tried it, but say so. Readers discount numbers they suspect are mostly classmates. Report strangers separately if you can: "40 sign-ups, about 30 of them people I don't know."
Should I worry about bots inflating my numbers?
A little. Google Analytics automatically excludes known bots from a list maintained by the Interactive Advertising Bureau, but you can't see how many it removed, and anything not on the list can still get through. Sign-ups and repeat visits are harder for bots to fake than page views.
Can I share my analytics publicly?
Some tools allow it. PostHog, for example, lets you create a public link to a dashboard or embed it on a website. Check that nothing on it identifies a user before you share it.
Want to build your own product?
The OPC cohort: 12 students, 8 weeks, one real product with real users.
Last updated: 2026-10-18. Written by the STARC team. Rules quoted here come from our transparency page; if they change, this post is updated.
More questions
How do I post a build log online that's honest and still gets read?
How a student can build in public on X, LinkedIn or Reddit without inflating numbers: what to post, how to show evidence, and what to disclose.
My AI-built website is slow: what can a student actually fix?
Why a website you built with AI loads slowly, how to tell whether it's slow for everyone or only some visitors, and the fixes worth doing first.
Mobile app or web app: which should a student build first with AI?
For students building a first product with AI: why a web app is usually the better first build, when a mobile app is worth it, and the store rules to know.