Inspiration
Accessibility barriers on school campuses — broken ramps, blocked pathways, doors that don't work for wheelchair users — usually go unreported. There's no easy channel for a student to flag them, and writing a formal complaint to facilities is enough friction that most people just don't. I wanted to remove that friction entirely.
What it does
Students file a short report: location, barrier type, description. An AI model assesses severity (Low/Medium/High) and drafts a professional summary suitable for a facilities report. Reports land on a shared board, sortable by severity, visible to anyone with the link. Each report has a "Copy as email" button that generates a ready-to-send message to school administration — so noticing a problem and actually reporting it take the same five minutes.
How we built it
Vanilla HTML/CSS/JS frontend, no framework, no build step. Two Vercel serverless functions: one calls an OpenRouter free-tier model to triage severity and write the summary, the other reads/writes reports to Vercel KV so the board is genuinely shared instead of stuck in one browser's local storage. Deployed via GitHub push to Vercel.
Challenges we ran into
The first working prototype used a browser-based storage API and called an AI endpoint directly from the client — fine for testing the idea fast, but neither would survive real deployment: no server-side auth, no shared state across visitors. I had to rebuild the persistence and AI-call layers from scratch as real serverless functions before this could go live. I also had a submit button that looked broken — turned out a native HTML form was silently swallowing the submit event in a way that gave no error, which I only caught by switching to a manual click handler instead of relying on form submission.
Accomplishments that we're proud of
Went from a rough client-side prototype to a fully deployed app with real shared storage and AI-backed triage in under two days, solo.
What we learned
That a working demo and a deployable product aren't the same thing — client-only tricks that make a prototype fast to test (in-browser storage, calling an AI endpoint directly) don't hold up once real users need to see the same shared data. Also learned to design a fallback for when the AI model doesn't return clean JSON, so one bad model response doesn't break the whole submit flow.
What's next for CampusAccess
Basic rate-limiting or lightweight moderation on the shared board, since anyone with the link can currently post. A status field (open/in progress/resolved) so reports don't just pile up unaddressed. Possibly a map view once there are enough reports to make one useful.
Log in or sign up for Devpost to join the conversation.