Community rules

Roast the build. Never the builder.

Funny is welcome. Specific is better. Humiliation, personal attacks, dogpiles, and fake assurance are not the vibe.

Own the launch

Only submit a project you own or control.

A maker must explicitly authorize the public listing and community testing. A future live version should verify control through an account plus a token on the project’s domain before publication.

  • No drive-by listings of somebody else’s work.
  • No impersonation, leaked previews, or private staging links.
  • Owners must be able to unpublish their whole project immediately.

Test safely

Try only the mission the maker offered.

The first community version is for public, low-stakes flows. Testing must not require payment, shared credentials, sensitive information, private files, consequential form submission, or bypassing authorization.

  • Do not fuzz, exploit, scrape, overwhelm, or probe unrelated paths.
  • Do not purchase anything or enter real financial details.
  • Do not use another person’s information or upload content you cannot share.
  • High-stakes healthcare, employment, lending, housing, insurance, admissions, benefits, and law-enforcement apps are not eligible.

Be useful, not mean

A roast should leave the maker with a next move.

Playful language is fine when the maker opts in. The observation still needs to come from actually trying the app.

Good roast

“The checkout button has the confidence of a primary action and the visibility of a witness-protection participant.”

Names the control, the problem, and a fixable outcome.

Bad roast

“Whoever built this has no idea what they’re doing.”

Targets the builder, proves nothing, and is not welcome.

  • No slurs, threats, personal attacks, allegations, identity speculation, or doxxing.
  • No public downvotes, worst-project boards, humiliation mechanics, or quote-dunking.
  • Disclose conflicts and test the app yourself before reporting an outcome.

Disclose privately

Never publish exploitable details.

If you see exposed personal information, account access, credentials, destructive behavior, or another potential vulnerability, stop testing. Do not reproduce it, retain the data, or post steps in public feedback.

Future live requirement

Route the report privately to the verified owner and moderators with strict access, retention, and disclosure controls. The static prototype does not accept reports of any kind.

Understand the boards

Rank attention and follow-through, not worthiness.

  • Trending counts eligible Good Vibes reactions in the current seven-day window.
  • Most Roasted counts unique visible, non-owner test reports.
  • Biggest Glow-Up counts tester-confirmed fixes on the current project version.
  • Owners cannot directly inflate rank, and reported or suspicious activity is excluded.

None of these rankings establish security, safety, quality, trust, accessibility, compliance, or launch readiness. There is no universal Bad Vibes score.

Moderation and removal

Consent can be withdrawn.

A real community launch needs manual review, report and block controls, rate limits, an appeal path, and an immediate owner unpublish control before accepting public content.

  • Owners may respond, request clarification, or report abuse. They may not silently erase criticism while keeping the listing ranked.
  • Moderators may hide unsafe, abusive, duplicated, or fabricated reports and remove their activity from ranking.
  • Project removal should hide the listing and public feedback together; retention requires a separate explicit policy.