Work / U03

DePedal

Campus bike-sharing for DLSU-D. Riders use the barcode on their school ID, and every ride is tracked and billed to the right person.

Role
All of the software
Team
Capstone, three people
When
2026
Stack
Flutter · React · Supabase · Edge Functions

How it works

Motion mock-up with demo data, rebuilt from the DePedal launch teaser. The docks, bike and rider are made up; the campus is real. Map data © OpenStreetMap contributors.
  1. 01Scan your school ID. The barcode on a DLSU-D ID is the ride pass, so every ride is tied to a verified rider.
  2. 02The dock lets one bike go. The scan is checked, and the dock's lock releases one bike.
  3. 03Ride anywhere on campus. GPS tracks the ride inside the campus boundary, and the console draws the route live.
  4. 04Every ride is on record. Return it at a dock: the ride closes, and the rider app and the console both keep it, route included.

01Problem

De La Salle University – Dasmariñas has a large campus, and getting between buildings mostly means walking in the heat. The campus jeepneys have unpredictable waits and a midday break, and parking is short.

02My role

I built all of the software: the Flutter rider app, the React admin console and the Supabase backend (database, Row Level Security and Edge Functions).

  • Marc Jacob C. LentejasThe ESP32 firmware
  • Dylan Paulo F. NicolThe dock lock: an actuator that locks the wheel at the docking station

03Approach

  1. Your school ID is your ride pass.A rider scans the barcode on their DLSU-D ID once to activate, and can relink it if the card is lost or replaced.
  2. Accountability, enforced by the server.A verified ID at the start and at the return, rides charged every 15 minutes, a campus boundary with a penalty, and an append-only ledger for every peso.
  3. Hardware gets its own credentials.Device keys live in a separate credential store. When a bike reports its position, the server works out which ride it belongs to from the authenticated bike, instead of trusting a ride ID in the request. Unknown bikes and wrong keys get the exact same refusal, so hardware IDs can't be enumerated.
  4. Fail closed.A missing campus boundary used to count as “inside”. Now it fails closed, and the boundary validator rejects shapes that would have put every rider outside.
  5. No ID oracle.The “already registered to another account” reply could have been scripted to find out which IDs are ride passes. Linking an ID is now rate limited per account.
  6. A console the staff can act on.A live map with each open ride's route, ride history with filters, exports and print views, an alert rail, and a force lock or unlock for the dock.

04Result

The rider app, the admin console and the backend work end to end with my teammates' hardware: barcode rider identification, GPS tracking with ride routes, and ride records.