onfix-the mechanic finder and appointment system

User-homepage

Inspiration

Finding a reliable mechanic during a roadside breakdown is stressful and unpredictable — drivers often don't know who's nearby, who's trustworthy, or how long help will take to arrive. As my Final Year Project, I wanted to solve this real-world problem by building an on-demand mechanic dispatch platform that works the way ride-hailing apps do, but for vehicle repairs — instant, location-aware, and reliable.

What it does

ONFIX connects drivers with nearby verified mechanics in real time. When a driver needs help, the app broadcasts the request to nearby mechanics, and the first one to accept gets the job — similar to how emergency dispatch systems work. Key features include:

Emergency mechanic dispatch with nearby-mechanic broadcasting and first-accept allocation
Real-time bidirectional GPS tracking so drivers can see the mechanic's live location
KYC verification using AWS Rekognition (face similarity) and Google Cloud Vision (CNIC text extraction) to ensure mechanic trust and safety
Appointment booking for non-emergency, scheduled repairs
Secure payments via Swich PayIN, with HMAC-SHA256 checksum verification
Mechanic performance dashboard with subscription tiers and trust badges (Bronze/Silver/Platinum)

How I built it

The system is built on a Flutter frontend and a Spring Boot backend, with PostgreSQL for persistent data and Redis for fast geospatial and presence lookups. Real-time communication runs over WebSocket/STOMP, deployed on Google Cloud Run with Docker.

A core piece of the architecture is the mechanic presence system — a four-file WebSocket setup (websocket_service.dart, WebSocketConfig.java, WebSocketSessionRegistry.java, WebSocketPresenceEventListener.java) that tracks which mechanics are online and available in real time, using Redis GeoSearch to filter nearby, available mechanics efficiently.

For routing and distance calculations, I integrated the Google Directions API and, after running into cost issues, migrated part of the routing logic to OpenRouteService (ORS) as a more sustainable alternative. Authentication uses JWT with Google OAuth, and the admin dashboard (built with Chart.js) gives operators visibility into mechanic activity and earnings.

Challenges I ran into

The biggest challenge was a Google Cloud billing incident — a debug simulation timer was sending fake GPS updates every 5 seconds, and a departure_time=now parameter was triggering the expensive Distance Matrix Advanced SKU. This combination generated thousands of unnecessary API calls in a single day. I resolved it by working with Google Maps Platform support, getting a credit approved, and — more importantly — redesigning the architecture so the Distance Matrix API is called once at dispatch for a batch lookup, the Directions API is called once when a mechanic accepts a job, and live tracking afterward relies on WebSocket updates with client-side Haversine/polyline-snap math instead of repeated API calls.

I also debugged a JSONException in the batch road-distance logic caused by missing API status checks, fixed mechanic availability filtering issues in Redis, and reworked the Flutter mechanic dashboard so mechanics are only marked offline on a true detached app state — not when the app is simply paused or hidden in the background.

Accomplishments that I'm proud of

Building a real-time, geospatially-aware dispatch system from scratch as a solo FYP — one that handles live location tracking, presence detection, KYC verification, and payments — while also learning to debug and recover from a real production-style incident (the billing spike) rather than just working in a clean, artificial dev environment.

What I learned

How to design real-time systems using WebSockets and Redis geospatial queries at a level beyond typical coursework
The importance of understanding third-party API pricing models deeply before wiring them into production logic
How to debug distributed, asynchronous systems where the bug isn't in the code you're looking at, but in a timing or configuration issue elsewhere
How to move from "it works on my machine" to a properly cloud-deployed, containerized system (Docker + Google Cloud Run)

What's next for ONFIX

Expanding the subscription and performance-tier system for mechanics, refining the KYC pipeline, and preparing the platform for a pilot rollout in Karachi to validate the model with real drivers and mechanics.