How FuzzPage scores a project
FuzzPage runs 19 checks across six dimensions and ranks every finding by how much it impacts your project. Here's exactly what each check looks at and why.
Severity
- Block Fix before you share any public link. A reviewer or first user will bounce or distrust the project.
- Fix before launch Not catastrophic, but it visibly weakens the launch. Resolve it if you can.
- Polish A refinement that sharpens an already-solid launch.
- Info / skipped Not applicable to your project's shape — skipped checks don't count against your score.
How it runs
Thirteen deterministic checks run first — regex over your README, HTTP probes, GitHub API reads, and a look at your robots.txt, llms.txt, and sitemap — in about a second, at no LLM cost. Six checks that genuinely require judgment (one-liner clarity, headline consistency, alternatives substance, the README opener, alternatives discovery, and competitive review) are evaluated by Claude Haiku 4.5 with cached prompts, at a fraction of a cent each. Checks that don't apply to your project — for example, README checks for a closed-source web app — are skipped rather than failed, so your score reflects only what's relevant.
Every finding ships with a specific suggested fix. The goal is never a grade; it's the shortest path to a launch that doesn't trip over an unforced error.
Identity & credibility
Is there a real, accountable maker behind this — not a throwaway account or an empty repo dump?
Looks at: GitHub account age (30-day floor, under 14 days is a hard fail) and recent push activity.
Why it matters: A brand-new throwaway account is the spam-farm signature. Account age + activity is the cheapest honest legitimacy signal. Borderline cases (14–30 days, or stale repos) drop to Fix-before-launch and can be cleared via appeal with a secondary identity.
Looks at: Repository age and content size as a proxy for substance (created today with under 5 KB fails; under 10 KB warns).
Why it matters: An empty repo initialized today is not a launch. Reviewers are rightly skeptical of placeholder repos.
Looks at: Presence of a LICENSE file (open-source); or a declared pricing model, stored maker metadata, or an unambiguous 'free' claim in the page's own headline copy (closed-source).
Why it matters: Code with no license is legally unusable — most teams won't touch it. A product with no stated pricing creates trust friction up front.
Positioning & messaging
Can a stranger tell what this is, who it's for, and why it's different — in the first few seconds?
Looks at: Your GitHub About, landing H1, og:description and meta description — judged for whether the one-liner is specific and reader-friendly.
Why it matters: A vague one-liner loses the reader before they reach the demo. When it's weak, the check returns a concrete suggested rewrite.
Looks at: Whether your About field, headline, first paragraph, and social tags tell the same story.
Why it matters: Drift between surfaces is confusing; an outright contradiction breaks trust and escalates this to Fix-before-launch.
Looks at: The 1–3 alternatives you name and whether each differentiator is substantive rather than vague.
Why it matters: Naming alternatives forces honest positioning and builds a discovery graph for readers. (Requires the submission form field.)
Looks at: The first ~1000 characters after the title — classified as value-led, lore-led, or mechanical-led.
Why it matters: Readers decide in the opening paragraph. Backstory, dependency lists, and badge walls belong below the value proposition.
Looks at: The real, well-known alternatives a visitor would compare you to, and whether your own copy makes the difference clear.
Why it matters: Most makers never say who they're up against. Naming the obvious comparables — with a sharp angle against each — is often the fastest positioning win. Advisory only; it never blocks certification.
Looks at: When you provide competitor URLs, it fetches their live homepages and compares how clearly each side states what it is, who it's for, and why to choose it.
Why it matters: Your strongest positioning is relative. Seeing where a real competitor's page is sharper than yours — pricing shown, target user named, a crisper one-liner — points at the exact copy to fix. Advisory only; it never blocks certification.
Try-it path
How fast can an interested reader actually try the thing?
Looks at: README length (500-character floor) and heading structure.
Why it matters: The README is the first thing every visitor reads. A thin or unstructured README means people bounce before understanding the project.
Looks at: Position of the first install command, demo link, or Install / Getting Started section heading — a command or demo should be within the first ~300 characters; a section heading within the first ~20 lines (judged by line, not character, so badges and a hero image don't count against it). Covers desktop apps that ship a download rather than a one-line command.
Why it matters: A buried install command is an unseen install command. Convention: intro paragraph, then install, then quickstart — above the table of contents.
Looks at: A real screenshot, GIF, or video near the top (README first quarter, or the landing page) — excluding badges and stock/placeholder images.
Why it matters: People grok a visual demo in two seconds and a prose description in thirty. A demo GIF is the highest-ROI thing most projects can add.
Visual & social assets
Will the project look like a real product when it's shared or crawled?
Looks at: The og:image meta tag on the landing page, plus the twitter:card size.
Why it matters: Without og:image, every shared link previews blank on Twitter, Slack, Discord, and Mastodon — a silent tax on every share.
Looks at: Whether the page is JS-rendered (an SPA) — and if so, whether at least the head (og tags + headline) is prerendered so link previews still work.
Why it matters: Preview crawlers and many search engines don't run your JavaScript. A bare SPA shell kills link previews and SEO; with a prerendered head this softens to a body-content/SEO polish item.
Post-launch readiness
On launch day, does everything load — and can people reach you afterward?
Looks at: That the landing page returns 2xx, and HTTP probes of the top navigation links.
Why it matters: Broken navigation on launch day reads as "I rushed this." The page loading at all is the most basic readiness bar.
Looks at: GitHub Issues, a profile or landing-page email, a mailto: link, or a /contact page.
Why it matters: When a reviewer or first user hits a bug, they need a way to reach you. No contact path means no follow-up — and no second chance.
Looks at: A Roadmap, Changelog, or "what's next" section in the README or on the page.
Why it matters: Visitors evaluating something new look for signals it will be maintained. A roadmap shows momentum; a changelog shows history — either reduces dead-on-arrival anxiety.
Discoverability
Can search engines and AI assistants find, index, and correctly describe this project?
Looks at: The page's <title>, meta description, canonical link, viewport tag, a crawlable robots.txt, a sitemap.xml, and image alt coverage.
Why it matters: These are the head tags and crawl directives search engines read to index your page and build its result snippet. Gaps quietly cost you traffic. Polish, not a blocker — it never affects certification.
Looks at: An /llms.txt file, JSON-LD structured data, and whether robots.txt sets an explicit AI-crawler policy.
Why it matters: AI answer engines and coding agents increasingly summarize tools to people who never open your page. A machine-readable description makes them likelier to describe you correctly. Neutral on allowing vs. blocking AI crawlers — only that you've decided.
Beyond the checks: where to take this
Every report ends with a forward-looking distribution map — the specific communities and channels where your project's likely audience already gathers (relevant subreddits, Hacker News, established forums, Discord/Slack communities, curated directories), each with a non-spammy angle for how to show up. It's generated by Claude Haiku 4.5 from the same project profile the audit reads, and it's advisory only: it never affects your score or certification. Treat it as suggestions to verify, not gospel — confirm each community still fits and read its self-promotion rules before posting.
Appeals & questions
The identity check (#1) has a built-in appeal path: if your GitHub account is new but you're a real maker, link a secondary identity — a package-registry profile, an app-store developer account, or a previously shipped product — and we'll verify it. For appeals or questions about a finding, email appeals [at] fuzzpage [dot] com.