AccessRelay

When an event schedule changes, AccessRelay flags affected accessibility arrangements, gathers fresh confirmations, and gives each participant a private, current plan.

Comment

Inspiration

A session can move with a single calendar edit. Its captioner, audio setup, and participant agreement may no longer fit the new plan, even while old confirmations look complete.

I built AccessRelay around one rule: a confirmation belongs to the details someone actually reviewed. When those details change, the affected work needs a fresh response.

What it does

AccessRelay is an event access desk for organizers, participants, providers, and staff. It connects an accessibility arrangement to the session, people, room, materials, and confirmations it depends on.

The working demo follows a fictional conference session moving from 10:00 AM in Room A to 11:00 AM in Room B:

  1. The organizer records an announced change. Participants see that the details are under review while the last published plan remains visible.
  2. Publishing the update reopens the affected checks. An unchanged session keeps its existing confirmations.
  3. Providers review the current assignment and can confirm or decline. The organizer records replacement coverage, using entered availability and service requirements to identify candidates.
  4. Staff and providers respond to their own work, including room setup and the current material versions.
  5. Each participant independently reviews their private plan and records their own agreement.

The organizer sees the remaining work and who owns the next action. The participant sees the arrangement relevant to them, its current responses, and who to contact.

Assignment, confirmation, participant agreement, and actual delivery remain separate records. Recording a replacement does not automatically cancel an external booking, and a confirmed plan does not prove that a service was delivered.

How I built it

The application uses Next.js, React, and TypeScript, with Supabase authentication, PostgreSQL, and Drizzle ORM, deployed on Vercel.

The core is a deterministic revision model. A response checks the current task revision, lock version, and relevant facts on the server. An old browser tab cannot silently approve a newer arrangement.

Each accepted command runs in a database transaction. The state change, history, command receipt, and notification intent commit together. Idempotency keys make retries safe when a response is lost. Authenticated event membership and role permissions control access to private views and mutations.

The organizer's operations sheet brings recovery actions beside the running order. Participants get a private itinerary. Both use clear status language, readable typography, and visible next actions.

Challenges I ran into

Reopening the right work. Resetting everything would create unnecessary follow-up; preserving everything would hide broken assumptions. I modeled which facts each confirmation depends on so changes can invalidate affected evidence selectively.

Shared work without shared consent. Two participants can share captioning coverage while keeping separate private arrangements and individual agreement. A provider's response must never substitute for either participant's decision.

Accomplishments I'm proud of

I completed the change-and-recovery workflow against a real database, including declines, replacement coverage, fresh confirmations, and persistent participant plans.

Recorded passing checks include 230 unit, configuration, and transport tests, 50 database integration tests, and 16 synthetic checks on the deployed preview. The integration suite includes a race between agenda publication and an old provider confirmation. Automated accessibility checks also covered 66 required screen and dialog states; independent screen-reader and participant testing remain next steps.

All people and event arrangements shown in the film and gallery are fictional demonstration data.

What I learned

“Done” is only useful when it is clear what was checked, by whom, and against which version.

I also learned that uncertainty needs a visible place in the interface. A pending review, a declined assignment, and a participant's disagreement each call for a different next action. Keeping these states distinct helps each person see what still needs attention.

What's next for AccessRelay

The next milestone is one independently observed, redacted event replay with an organizer and a participant. I want to compare total setup, follow-up, and correction effort against their current process and learn whether the recovery queue helps them act without coaching.

The initial buyer hypothesis is a campus event office or conference production team. I would test $79 per event, with participants and task owners free and provider services arranged and paid separately. At an assumed coordinator cost of $30 per hour, that price needs roughly 2.6 hours of net saved coordination work to justify it. This is a validation target, not a measured saving or existing revenue.

Before a live operational pilot, priorities include independent accessibility review, verified email delivery, retention controls, and backup/restore rehearsal. For larger events, the next engineering step is measuring concurrent load and normalizing growing records beyond the current event-level aggregate.

Try it

Watch the five-minute demonstration, then open the deployed prototype.

Google sign-in with a verified Gmail account opens an empty event desk where users can add an agenda, people, and availability. The fictional conference in the film is a local fixture. Hosted email delivery remains disabled.

Built With

Share this project:

Updates

Submission history