AccessKRK

The design fits the brief tightly: 11 combinable profiles, per-profile verdicts with reasons, and 'brak danych' instead of a false 'accessible'. The median reflects that no running demo or UI screenshot exists and the WCAG 2.2 AA claims rest on README text alone, which supports A's caution over B's 8.5 for interface features that were never shown.

12,544 lines in a clean layered architecture with real routing depth and 30 commits from 4 authors, all during the event. The score sits at 7 because nothing in the pack shows the app running, and the measured test count is 0 even though two members report a 23-file xUnit suite in the tree.

Provenance is enforced at the type level with source, checked-on date, and demo flag; stale Overpass data older than 2 days is rejected and user reports stay pending until verified. B's 9 understates the limits, since only OSM and GTFS are wired in, reliability is binary, and conflicting sources are resolved by silent precedence; C's 7 understates the rigor that is demonstrably there.

Ingestion is genuinely separate from presentation: a Tools importer writes per-city static JSON behind a CityImports registry, so adding a city is a config change, and Docker hosting with CI smoke tests and rollback supports operations. The remaining couplings are Polish-only labels, Krakow-specific overrides, and a partner API still 'in preparation'.

Monetizable seeds exist — paid business accounts with QR certificates, an official city dashboard, a partner API — but nothing is priced: no PLN figures, no hosting costs, no who-pays narrative, and the deck that would carry it is missing. The median of 3 rejects B's 1, which ignores the described model, and C's 5, which is generous given the task explicitly requires numbers.