Benchday

Inspiration

A repair event brings together people with different skills, items needing attention and tools that several repairs may share. Reception has to keep track of all three. BenchDay explores one part of that work: deciding which waiting items can start together.

Repair Café's descriptions of volunteer roles informed the setting. Existing services already connect people with repairers; this prototype focuses on the next batch within a single event. It has not been tested at a real repair event.

What it does

An operator enters volunteers, skills, shifts and shared-tool capacity, then checks in repairs with a duration estimate. A safety hold excludes an item until someone reviews it.

The board proposes a batch that respects those constraints. Once the operator confirms it, the volunteers and tools stay reserved until an outcome is recorded. Estimates never release an active bench automatically. The repair log separates repaired items, items needing parts and items that could not be repaired.

The app stores one event on one device, supports JSON backups and blocks simultaneous editing in another tab. After its first complete load, a cached copy can work offline in the same browser.

How it was built

BenchDay uses JavaScript modules, semantic HTML and CSS, with no third-party runtime packages. Web Locks protects the editing tab. Web Crypto checks exported snapshots, and a service worker caches the app.

The dispatcher searches volunteer-to-item assignments. It maximizes simultaneous starts, then prefers older waiting tickets. A fixed search budget bounds the work; if the search stops early, the UI says that optimality is unproven.

A concrete result

In the initial fictional example, a fixed-order greedy baseline starts two repairs. BenchDay starts three by assigning the bicycle to Alex, preserving Rowan's electrical skill for the lamp. This is a reproducible software example, not a claim about real-world waiting times.

All eight automated tests pass, including 300 seeded cases compared with an independent exhaustive oracle. Browser checks cover check-in, dispatch, outcomes, undo, resource protection, import, downloaded snapshots, mobile layout and offline use.

Challenges and next steps

The main implementation challenge was keeping resource reservations correct across edits, elapsed estimates and restored snapshots. Validation at each transition and explicit outcome recording make those boundaries visible.

The next step is supervised testing with an event organizer: check whether the intake fields, timing assumptions and explanations match reception work. Multi-device synchronization is outside the current scope.

AI assistance

OpenAI Codex generated and iteratively revised the code, tests, documentation and submission text. The reported checks were run on the resulting application. The demo uses fictional data, captured app screens and a synthetic narration. No user interviews, field results or earlier completed hackathon application are claimed.