AccessBilly

AccessBilly | Navigator made for you, not the default.

Comment

About the project

Inspiration

We built AccessBilly Compass because “fastest” or “shortest” on a map is not the same as reachable for everyone. Big navigation apps are great at generic driving and walking, but they rarely treat stairs, benches, indoor cut-throughs, or wheelchair needs as first-class inputs to a route. People who need those details often learn the hard way: a line on a screen can still be a bad trip.

We were also inspired by community knowledge: what’s true on the ground day to day often isn’t in official data. Our tagline is “Community maps, smarter routes.” We combined preference-aware routing with a layer to look up, rate, or add accessibility-related points so the map can reflect how people actually move through campus and the city.

We entered HooHacks under the Finance track because bad navigation has real economic cost: missed work, extra rides, wasted time. Better routes and better information support inclusion in jobs, school, and services.

What we learned

  • Clear contracts beat clever UI. Defining how RouteRequest becomes JSON (source, destination, preferences) and how a RouteModel parses the response kept the app maintainable when Mapbox, Firebase, and backend details changed.
  • Mapbox + Flutter integration (tokens, styles, annotations, camera) has real platform surface area; testing on iOS Simulator surfaced issues early.
  • Firebase emulators are useful for iterating on a Python HTTP handler before everything is deployed.

How we built it

  • Mobile: Flutter / Dart with a layered structure: domain entities, repositories, Mapbox-backed map and navigation UI (turn-by-turn style flow where implemented).
  • Maps & APIs: Mapbox (mapbox_maps_flutter) for the map; HTTP (dio / http) from Flutter to our backend; geolocator where location is needed; flutter_dotenv for Mapbox keys via env file (not hard-coded).
  • Backend: Firebase Cloud Functions with Python in functions/ (POST endpoint for routing / preferences; can connect to Firestore as data grows). Firebase CLI + emulators for local dev.
  • Design: Wild-west themed assets (wood textures, fonts, cowboy hat flair) with documented third-party credits.

A simple way to think about “shortest path” vs “what we send the router” is geometric distance in the plane versus a preference-weighted idea: classic distance between two points is ( d = \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2} ), but in our setting the meaningful object is more like a route under constraints (avoid stairs, need benches, etc.). We encode those constraints in JSON so the backend can grow toward real accessibility-aware routing without rewriting the whole app.

$$ d = \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2} $$

Challenges we faced

  • APIs and secrets: Mapbox token handling, .env layout, and iOS/Android configuration so the map loads reliably without committing keys.
  • End-to-end routing: Agreeing on JSON between Flutter and Python early; debugging POSTs against emulators vs deployed URLs; occasional networking/CORS surprises.
  • Routing “algorithm” in a weekend: The hard part was encoding preferences and passing them cleanly; full graph search over a custom accessibility network is future work, but the repo is structured so that logic can live server-side.
  • Time: Polished UI + map + navigation flow competed with wiring the full backend loop and drawing every polyline edge case.
Share this project:

Updates