Methodology
Every part of the score is arithmetic you can check by hand. A rule either fires or it does not, each rule has a fixed point value, and the same code always produces the same score. There is no model, no sampling, and no judgment call anywhere in the scoring path.
Severity to points
Each of the 115 rules has a fixed severity, and each severity maps to a fixed deduction. A rule deducts its points once per scan, no matter how many places it matches, so one noisy rule cannot wipe out a category on its own.
| Severity | Points deducted | Examples |
|---|---|---|
| critical | 25 | A hardcoded API key, SQL built by string concatenation |
| high | 15 | eval() on input, no tests anywhere, committed node_modules |
| medium | 8 | An empty catch block, no .gitignore, images missing alt text |
| low | 4 | console.log left in source, no rate limiting dependency |
| info | 2 | No favicon, mixed tabs and spaces, missing .editorconfig |
Category weights
Each category starts at 100 and loses points for every rule that fires in it, floored at zero. The overall score is the weighted average of the six category scores. Security is weighted highest because a leaked API key matters more to whether you should ship than a missing changelog does.
| Category | Weight | Rules |
|---|---|---|
| Security | 30% | 25 |
| Code Quality & Syntax | 20% | 25 |
| Architecture & Best Practices | 15% | 20 |
| Testing & CI | 10% | 10 |
| Documentation, UX & Accessibility | 15% | 20 |
| Dependencies & Hygiene | 10% | 15 |
Verdict bands
The overall score maps to one of five verdicts.
- 90 to 100Ship it. This vibes.
- 75 to 89.9Mostly vibes. A few things to clean up.
- 55 to 74.9Shaky vibes. Real issues before this should see users.
- 35 to 54.9Bad vibes. Significant rework needed.
- 0 to 34.9No vibes. Do not deploy this as-is.
What a rule looks like
A rule is a fixed check with an id, a severity, and a description that is exactly what you see in your report. For example, SEC-001 looks for string patterns matching known secret formats, and CQ-009 flags empty catch blocks that silently swallow errors. There is no hidden logic beyond what each rule page documents.
Known limitations
Being upfront about these is part of the deal.
Heuristic, not a compiler
Most checks are pattern matching over source text, not a full parser (the Python rules that use AST parsing are the exception). False positives and false negatives exist, the same as any linter. The rules are tuned to be useful, not to be a formal verifier.
JS/TS and Python get the most coverage
Most security and UX rules target JavaScript, TypeScript, HTML and CSS, since that is the dominant vibe-coded stack. Python gets thinner coverage. Other languages mostly hit the language-agnostic checks: docs, CI, dependency hygiene, project structure.
It scores what is checkable, not quality
A 95 means the code passed 115 structural checks. It does not mean the product is good, the UX makes sense, or the idea has a market. That is a different and much harder question this tool deliberately does not attempt to answer.
Findings are capped per rule in reports
Each rule surfaces at most a handful of example locations (usually 5) to keep reports readable. The full occurrence count is still recorded, and a rule only ever deducts its points once no matter how many times it matches.
One honest note on paying
The free view and the paid view are the same report. Paying reveals every finding, location, and fix prompt. It never re-runs anything and never changes a number. See pricing for what each tier includes.