The repository sells activity, not source code
buy-github-stars is a storefront disguised as a project page. The root README promotes packages of stars, forks, followers, and watches from accounts the seller describes as aged. It links repeatedly to an external ordering site and says progress updates arrive through Telegram. There is no application, command, API definition, or service implementation in the repository for a developer to inspect.
The pitch is about making purchased activity resemble discovery. It promises gradual pacing, mixed interaction types, and accounts with public history. Those details do not turn paid engagement into genuine adoption. A star usually tells a visitor that someone chose to save or endorse a repository. Here, payment is the reason the interaction appears, while the presentation is designed to conceal that reason.
GitHub policy prohibits the product being advertised
GitHub's current Acceptable Use Policies name inauthentic interactions, rank abuse such as automated starring or following, and secondary markets created to spread inauthentic activity. The seller argues that its accounts have history and that delivery looks natural. GitHub's rule is about the authenticity and market for the activity, not merely whether an account was created yesterday or whether every click happened in one hour.
This is not a close call about aggressive marketing. The README sells exact quantities of platform interactions and describes pacing intended to resemble an audience. A maintainer using the service would be purchasing a false public signal. GitHub's Community Guidelines also say moderation can include reduced visibility, hidden accounts, suspended organizations, or removed content. No delivery guarantee can override platform enforcement.
What happened when we ran it
Our sandbox did not run commit 2235f03 because the repository has no supported ecosystem and no Dockerfile. There is no install time, build status, test count, package footprint, or dependency audit to report. The lab finding is the absence of a runnable project, not a failed application setup.
The repository metadata reports no programming language. Its tagged v1.0.0 release calls itself an initial documentation release and lists a service overview, delivery method, assets, and community files. That is consistent with what the page provides. We did not place an order, contact the seller, transfer money, or test any GitHub accounts. The supplied lab block contains no evidence about fulfillment or retention.
The promises cannot be checked from the repository
The README says stars come from real aged accounts with years of public commit history, arrive over 12 to 24 hours, and will be replaced if they drop within 24 hours. It offers packages starting at 1,000 actions and says larger orders can reach 40,000 stars. None of those claims comes with a disclosed sample, independent audit, delivery log, or method a buyer can reproduce.
Even the guarantee contains a conflict. One section says the stars stay and promises replacement, while another admits no provider can promise permanence because GitHub controls its systems. Replacement is not retention, and a second inauthentic interaction does not repair the authenticity problem created by the first. The repository gives a buyer no contract text, dispute process, account provenance record, or evidence that replacements avoid the same enforcement risk.
Purchased counts damage the metric you are trying to improve
Stars are useful only while readers believe they reflect voluntary interest. Buying 700 stars inside a 1,000-action package may raise the displayed number, but it makes that number less informative. A developer comparing libraries, a company evaluating adoption, or a contributor deciding where to spend time cannot distinguish the paid portion from actual interest by reading the counter.
The README also claims stars influence search placement and trending eligibility. That is precisely why paid activity is a rank-abuse concern. A temporary visibility gain would come at the cost of an audience signal that no longer means what visitors assume. If the mismatch becomes visible through account patterns, issue discussion, or platform action, the reputational cost belongs to the repository owner, not the seller's marketing page.
One release and 206 stars do not establish service health
The repository was created on September 17, 2026, published v1.0.0 that day, and was last pushed on September 19. GitHub showed 206 stars and 0 open issues and pull requests when checked. Those figures describe a young documentation repository with no public support queue. They do not reveal order volume, customer outcomes, account removals, refunds, or policy actions.
The README's MIT license applies to its published material. It is not a certification of the linked business and offers no warranty that the sales claims are true. There is also no code history through which maintainers can judge engineering practice. A buyer is left with the seller's own assurances about a service built to manufacture third-party trust signals.
Real project growth leaves evidence people can inspect
A healthier route is slower and far less mysterious: explain the problem clearly, publish a usable quick start, respond to bug reports, mark beginner-friendly work, and credit non-code contributions. GitHub's Open Source Guides cover those community mechanics, while All Contributors makes real participation visible. Neither can promise 700 new stars on a schedule. That is the point.
Use this repository as abuse-research material if that is your job. For a maintainer deciding how to grow a project, the answer is simpler. There are 0 tests because there is no product here to evaluate, and the thing being sold conflicts with the platform policy governing the metric. Walk away.