A star can tell you that somebody noticed your project.
It cannot tell you that the project solved their problem.
That distinction sounds obvious when I write it in two sentences. It gets blurry the moment a number starts going up.
On September 4, 2026, GitHub released a new star history API endpoint. It gives developers historical repository star counts with timestamps while withholding individual stargazer identities. GitHub introduced it after restricting stargazer-listing endpoints earlier in the year to protect user privacy.
This is a useful change. Maintainers and tool builders can study when a repository gained attention without turning every person who clicked a star into a lead record.
It also gives beginner builders a perfect reason to learn a harder measurement lesson:
Count the signal you actually received. Do not quietly promote it into the proof you wish you had.
GitHub’s own documentation describes a star as a bookmark and an approximate sign of interest. A star does not trigger notifications. A repository’s traffic data can separately show views, unique visitors, clones, referring sites, and popular pages. Those are different measurements because they answer different questions.
If you are building your first app with AI, you need the same honesty. A like is not a trial. A download is not a completed workflow. One successful session is not retention. A compliment is not a purchase.
None of those signals is useless. Each belongs on a different rung of the product-proof ladder.
The beginner mistake: one exciting number gets every job
AI makes it possible to build a demo, landing page, repository, or TestFlight release quickly. That speed is valuable. It also lets you arrive at the measurement problem before you have language for it.
You share the project. Ten people view it. Three star the repository. A friend says it looks great.
Your brain wants to compress that into one conclusion: “People want this.”
Maybe they do.
But the evidence currently says something narrower:
- some people saw the project;
- some expressed lightweight interest;
- and one person gave you positive feedback.
The next question is not whether you should feel good. Feel good. Shipping deserves a small parade.
The next question is: what stronger claim has not been proved yet?
That question protects you from building six months of features around applause that never became use.
If you need help defining the user, first workflow, and success condition before you build the measurement layer, my AI App Builder Starter Prompts are free. The immediate job is to state what the app must help one person accomplish so every later metric has something concrete to measure.
My seven-rung product-proof ladder
You do not need a giant analytics stack for a first version. You need a small sequence of signals that gets closer to the user outcome at every rung.
1. Discovery: did anyone see it?
Examples include an article impression, repository view, landing-page visit, or social post view.
Discovery proves distribution reached someone. It does not prove interest, understanding, or usefulness.
Record the source and date. GitHub’s traffic view, for example, separates referring sites and popular content from the star count. That helps you distinguish “people found the README through an article” from “the repository is mysteriously famous now.”
Beginner question:
> Where did this visitor come from, and which promise did they see first?
2. Interest: did they choose to remember or inspect it?
A GitHub star belongs here. So do a bookmark, profile click, landing-page scroll, or click into documentation.
GitHub’s new endpoint makes star growth over time easier to inspect without revealing identities. That is the right level of claim: the repository accumulated a privacy-safe count of interest signals during a period.
It does not tell you why each person starred it. They may want to use it later, study the code, support the idea, or save it beside 600 other repositories they plan to revisit during the heat death of the universe.
Beginner question:
> What did the person do that shows more intent than merely seeing the project?
3. Arrival: did they reach the product?
For open-source software, a clone can be a stronger signal than a view. For a web app, it might be opening the product from the landing page. For mobile, it might be installing or launching the beta.
Arrival proves that the person crossed the boundary between hearing about the thing and touching the thing.
It still does not prove the setup worked.
Beginner question:
> Can I verify that the user reached the actual starting point?
4. Trial: did they begin the main workflow?
This is where product-specific evidence starts.
For a name picker, the user might add the first name. For an invoice app, the user might create the first client or line item. For a developer tool, the user might run the first command with a real project.
Do not count opening the app as trying the product if the value requires another action.
Beginner question:
> What is the smallest observable action that means the user genuinely began the promised job?
5. Completion: did they receive the promised result?
This is the rung many beginner apps never define.
The user did not merely press a button. They reached the useful end state: a winner was selected, an invoice was produced, a file was transformed, a bug report was organized, or a deployment became reachable.
Write the event in plain language before you add analytics:
The workflow is complete when [user] can see [specific useful result] after [specific action].If your tracking event cannot be translated back into that sentence, it may be measuring interface motion instead of product value.
Beginner question:
> Which visible result proves that the app completed its promise once?
6. Return or commitment: did the value matter enough to continue?
A return session, saved project, second completed workflow, email signup, paid purchase, or voluntary referral belongs here. Choose the version that honestly fits your product.
Do not treat all commitment signals as interchangeable. A second use proves repeat utility. A purchase proves willingness to pay under one offer. A referral proves the person was willing to attach some social trust to the recommendation.
For a tiny first app, I would rather see three people complete the workflow twice than celebrate 3,000 impressions with no completed result.
Beginner question:
> What behavior would be inconvenient for the user to perform if the first result had no value?
7. Explanation: can the user tell you why?
Numbers show where something happened. A short conversation, support question, cancellation reason, or honest review can explain why.
DORA’s user-centricity research questions emphasize understanding what users want to accomplish and using their feedback to revisit priorities. That is the missing layer when a dashboard gives you a spike but no story.
Ask one specific question:
> What were you trying to finish, and where did the product make that easier or harder?
Do not ask for praise. Ask for the job, the friction, and the result.
A one-page product-proof sheet
Use this before you add another feature:
| Rung | Exact signal | What it proves | What it does not prove | Next test |
|---|---|---|---|---|
| Discovery | unique visit from an article | the distribution path worked | interest | open the product or docs |
| Interest | repository star | lightweight interest or intent to remember | installation or use | visit setup path |
| Arrival | clone, install, or app open | the person reached the product | successful setup | begin main workflow |
| Trial | first meaningful input | the user started the job | useful result | complete workflow |
| Completion | visible promised result | the product delivered once | repeat value | return and repeat |
| Commitment | second use, signup, purchase, or referral | value justified another step | why it mattered | ask one focused question |
| Explanation | concrete user account of job and friction | why the behavior happened | broad market demand | test with the next user |
For every row, write the exact event, timestamp, and source. Then write the strongest conclusion the event supports.
This stops “we got traffic” from becoming “we have product-market fit” somewhere between the analytics tab and your next coffee.
The privacy lesson inside GitHub’s change
GitHub could have solved the star-history problem by restoring a convenient list of identities.
Instead, the new endpoint provides historical counts without exposing individual stargazer data.
That is a useful design pattern for beginner analytics: collect the least identifying evidence that can answer the product question.
If you only need to know whether more people completed the workflow after an onboarding change, you may not need a permanent profile of every click. If you need to contact a user, ask for that relationship clearly instead of treating passive attention as consent.
Less data can mean less debugging power and less ability to segment behavior. That is the tradeoff. You should name it, then decide whether the added detail earns its privacy and maintenance cost.
The limitation: early proof is still small proof
The ladder does not turn five users into a market forecast.
A repository star can come from curiosity. A clone can come from a bot or a person who quits during setup. A second use can come from a friend being polite. A purchase can come from an offer that does not scale.
Early evidence should change what you test next, not give you permission to make giant claims.
Also, not every product needs all seven rungs instrumented on day one. If you have no users, start with discovery, arrival, and one completion event. Add return behavior when repeat use is part of the promise. Add payment evidence only when you are honestly testing a paid offer.
The goal is not maximum tracking.
The goal is minimum confusion.
What you should do next
Take the metric you are most excited about and write one sentence beginning with:
This proves that...Then write a second sentence:
This does not yet prove that...Place the metric on the seven-rung ladder. Design one next test that moves closer to workflow completion, return behavior, or an honest user explanation.
For the immediate guided action, use my AI App Builder Starter Prompts, which are free. They help you define the user, scope, first workflow, and done-when result that your proof ladder should measure.
If you want the organized path from idea to publication, AI App Builder From Zero walks through idea generation, scope, stack choice, prompting, architecture, QA, deployment, App Store, Google Play, and launch.
GitHub’s new API gives maintainers a better way to count stars without collecting the people behind them.
Your job is to give every number the same honesty.
Count attention as attention. Count completion as completion. Let the next test earn the next claim.
You can also find me here:
Medium: https://medium.com/@marcusykim DEV.to: https://dev.to/marcusykim Website: https://marcusykim.com/ X: https://x.com/marcusykim LinkedIn: https://www.linkedin.com/in/marcusykim/
Marcus Kim | AI App Builder 