Main Screen
Floor screen
Reporting screen
Manual reporting screen
Report a hazard
My reports
Facilities Dashboard
Main screen
Menu option

Inspiration

A few weeks into the semester, one of us walked into the CDS building and found a spill on the floor near the stairs. We called Facilities like you’re supposed to. The phone rang and rang, then we waited on hold. We stood there a long time while students stepped around the puddle, and a few nearly slipped on their way to class.

Nobody was at fault. Facilities covers a huge campus with a small team, and a phone line takes one call at a time. But we kept wondering why one person had to stand there holding a phone while everyone else walked into the problem. We would have gladly filled out a 30-second form, and the people behind us deserved to know about the hazard before they got to it.

It happens a lot. The front doors of CDS break all the time: the automatic door won’t open, a door sticks, an entrance gets closed off. A student in a wheelchair or on crutches can’t avoid it as much, and today the only way to find out is to show up and discover it yourself.

Then there was a quieter problem. Nobody knows whether someone else has already reported something. You walk past a broken door or a spill and assume someone called. Everyone assumes the same thing, so sometimes nobody calls, and sometimes ten people call about one problem while another goes unreported. And even when someone does report, they never find out what happened next. Was it seen? Is anyone coming? Is it fixed? There was no shared place to check what’s known, and no way to watch a problem move from reported to resolved.

The people hit hardest are the ones who can least afford surprises. For a student on crutches, a wet floor is a fall risk. For a student in a wheelchair, an out-of-service elevator, a blocked ramp, or a broken front door can mean missing class, and they usually learn about it at the door. Campus hazards are an accessibility problem as much as a maintenance one, and the information that would help people route around them already exists in the heads of whoever saw it first.

So we built AccessiBU, a crowdsourced, real-time hazard map for Boston University. Someone who spots a problem reports it in seconds. Anyone can open the app and see what’s already been reported, on a 3D campus map and an exact 2D floor plan, before heading out. Facilities gets a located, prioritized report instead of a phone call they have to decode, and students get to see what’s open, what’s being handled, and what’s been fixed.

What it does

Check the Map: View active campus hazards on a 3D map or detailed floor plans (Basement–17th floor) with a live position dot to check routes beforehand.

Report an Issue: Snap a photo, add a brief description, and pin the exact floor plan location. Alternatively, file a manual report by selecting the floor, hazard type, and severity.

AI Triage & Contextual Risk: An AI vision model automatically classifies photo reports and scores severity. Hazards located near high-risk zones (e.g., stairwells, elevators, exits) automatically receive higher severity rankings.

Manage & Resolve: Facilities staff use a dedicated dashboard to track, resolve, reopen, or moderate reported hazards.

Built for Accessibility: Designed with screen-reader labels, high contrast, and large touch targets.

How we built it

Frontend: Expo and React Native. One codebase runs on iOS, Android, and the web. We used Expo Router for navigation, expo-camera for live photo capture, and expo-location for the user’s position.

3D map: Mapbox GL. It’s a tilted, 3D-building view of campus centered on CDS. The hazard count floats over the building and disappears when you zoom out, so it never marks the wrong spot from a distance.

Floor plans: We took the architect’s floor plans for the Data Sciences Center, exported and cropped every floor from the Basement to the 17th, and georeferenced them using the building’s real latitude and longitude corners. Floor 2 got a full digitized room map, so a pin resolves to an actual room name and a real-world coordinate.

Backend: FastAPI and Supabase. FastAPI handles authentication, hazards, reports, and the Facilities routes. Supabase provides Postgres, Auth (restricted to @bu.edu addresses), and photo storage. Every report lives in one shared database, which is what gives everyone the same live picture of campus. Alembic manages the schema.

AI: GPT-4o vision. The backend sends the photo, the reporter’s description, and structured spatial context: the floor, the pin position, the nearest staircase or elevator, and the distance to it. The model returns a type and a base severity, and our location rules adjust it. The model never has to understand a floor plan, because the app does the geometry and hands over the answer.

Deployment: OnRender hosting

Challenges we ran into

We ran into configuration errors, but over came them. Also we ran into location recognition issues we want to work on at a later time.

Accomplishments that we're proud of

The best data is already on the ground. Facilities can't be everywhere, but students are. Making it easy to share what you see turns a slow, one-to-one phone call into instant, one-to-many awareness. "Someone probably reported it" is the real problem. When there's no shared record, everyone assumes someone else handled it. A visible, shared map replaces that assumption with an answer. Accessibility is about information, not just ramps. A working elevator or automatic door only helps if you know which one works. Giving people advance notice changes their whole route. Keep the AI honest. We kept the vision model narrow (look at the image) and handled location rules separately in plain code. The severity is explainable ("raised because it's beside the north stair"), and Facilities stays in control: they confirm manual reports and resolve everything on site. Much of building software is debugging the environment. Certificates, CPU architectures, caches, and missing config files cost us as much time as features did. Every one of them taught us to read the actual error instead of guessing.

What we learned

We learned that development takes a long time and building out APIs and processes take planning and thinking in order to create a good and functional product.

What's next for AccessiBU

Let someone add to an existing report instead of filing a duplicate, so Facilities can see how many people are affected and whether a hazard is still there. Extend room-level maps beyond Floor 2 to the rest of CDS, then to other BU buildings. Accessible routing: suggest a barrier-free path that avoids active hazards, broken elevators, and blocked or broken entrances. Radius alerts for hazards near you, especially for students who opt in for mobility needs. Let Facilities confirm or adjust severity on site, and notify the reporter when their hazard is resolved.