$ loading
Loading…
$ loading
/docs/scoring
Three categories, each 0-100, published before you submit, identical for every entry. Your per-category numbers 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.
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.
| 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 0-100 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:
Reach support with a short written reason - every evaluation is logged and auditable end to end.