$ loading
Loading…
$ loading
/docs/scoring
Three categories, each graded A+ to F, published before you submit, identical for every entry. Your grades and the written reasoning go public at the reveal.
Is everything the brief asked for present, reachable, and actually working - and how does the product behave off the happy path?
Does the solution fit the brief's real problem, how considered is the visual and responsive design, and is it clear to use end to end?
Architecture and correctness, readability, security hygiene, and the attention to detail a rushed build doesn't have.
The three categories combine into one final score. Completing what the brief asked for gates everything: build none of it and no amount of polish saves the score. Beyond that, engineering quality and design taste carry the range.
It is not computed from the category grades. Completeness sets the ceiling first, then quality and taste move you within it, and the scale is intentionally demanding at the top - so a build can post three strong grades and still trail one with a sharper design. The grades explain where the strength and the gaps are; the final score is the overall verdict.
Most of the score is measured directly from your code rather than from an opinion - the same submission always scores essentially the same on a re-run. Scoring reads code only; screenshots and the deployed URL are never scored.
Every entrant gets the same scoring pipeline and the same category summaries. Written strength and weakness notes on your report are a Pro Plan feature - they never affect any score.
| final score | what it means |
|---|---|
| 60s | a complete, conventional build |
| 70s | strong |
| 80s | rare |
| 90+ | excellent engineering and a design worth showing off |
Published: the categories, what each judges, the grade scale, and the score bands above - all before submissions open, frozen for the whole challenge. Internal: the exact marking scheme underneath.
That's deliberate. A published checklist stops describing good work and becomes a script to generate against. What keeps it honest: the scheme is identical for every entry, never changes mid-challenge, and every score ships with written reasoning you can check against your own repo.
If two builds tie on final score - in order, never by chance:
The same order decides the weekly cup, after best-of-three total, best two and best single game.
Reach support with a short written reason - every evaluation is logged and auditable end to end.