How we built a job tracking dashboard for a bike repair shop in Dubai
A bike repair shop in Dubai was tracking everything from memory. Jobs lived in people's heads, with the occasional note or WhatsApp message to keep things moving. Customers called multiple times a day asking for updates, and staff had to stop what they were doing, walk over, physically check the bike, and call back.
We built a system that replaced all of it. We cover how we deploy these systems on-site in a separate post, but here is what was broken, what we built, and what changed.
What was broken at the bike shop?
The shop handled repairs, servicing, washing, and customization, each following a different path. A simple wash takes 45 minutes, some services take a few hours, others take days. But everything was tracked the same way: someone remembering it.
Staff forgot which jobs were urgent. The owner had no way to see how many jobs were in progress without physically being at the shop. And when a customer picked up their bike and said "that attachment was on my bike when I brought it in," nobody could prove otherwise because nobody had documented the bike's condition at drop-off.
They had tried dedicated shop management software before, but it did not fit how the shop actually works. Too rigid, too many steps, and nobody kept up with it.
What did we build?
- Kanban-style dashboard showing every active job across columns: intake, diagnosis, waiting for approval, in progress, ready for pickup
- Photo capture at intake: staff photograph the bike from multiple angles before touching it
- Customer-facing status page: customers get a link to check their repair status from their phone, no app needed
- Service type classification with 14 service categories matching what the shop actually does
- Staff notes and diagnosis fields so the mechanic's assessment travels with the job instead of living in someone's head
- Job type and service level tracking (standard repair vs. wash vs. full overhaul)
- Shared PIN authentication so staff can log in on any device without individual accounts
How does the system work?
The dashboard runs on the shop computer, and staff use their phones and tablets for photos and other tasks. Every job shows up as a card on a visual board, gets dragged to the next column when work progresses, and opens to show photos, notes, and customer details. One system for everything.
Photos are stored in a dedicated cloud bucket, and customer status pages use signed URLs that expire. No customer data sits on the device itself.
What changed before and after?
Job tracking
Jobs lived in people's heads; details got forgotten, priorities got mixed up, and there was no way to see all active jobs at once without asking each mechanic what they were working on.
Digital Kanban board shows every job across columns; staff see what needs attention in seconds, and the owner can check from any device, anywhere.
Customer status updates
Customers called or messaged asking "is my bike ready?" multiple times a day. Staff had to stop what they were doing, check the bike, figure out where it was in the process, and call back. Some of those interruptions lasted over an hour.
Customers get a link to a live status page. They see exactly where their job is in the pipeline, what was diagnosed, and what is left. No calls needed.
Condition documentation
No photos taken at drop-off, so when a customer said an attachment or accessory was on their bike when they brought it in, there was no proof either way. Disputes were resolved by eating the cost.
Staff photograph every bike at intake, and photos are timestamped and stored with the job. If a customer disputes a scratch or dent, the shop has documented proof of the bike's condition before any work started.
Staff memory and handoffs
Diagnosis and notes lived entirely in the mechanic's head. If one mechanic started a job and another finished it, information was lost in the handoff.
Diagnosis, cost estimate, and notes are attached to the job card, so any staff member can pick up where someone else left off. Nothing depends on one person remembering.
How was the system deployed?
Scoping and planning
Visited the shop and watched the full workflow: how bikes come in, how jobs get assigned, how mechanics communicate, how customers ask for updates. Documented every service type and identified the real bottlenecks.
System build
Built the full dashboard: Kanban board, photo capture, customer status page, staff authentication, job pipeline with all service types. Ran through test scenarios before going on-site. Iterated on the status flow based on how the shop actually works.
On-site deployment and training
Showed up at the shop, installed the system on their devices, and trained each staff member individually. Watched real customers come in and tested the full flow; fixed edge cases on the spot, added service types the team mentioned during training that were not in the original scope. Left when the team was comfortable.
What changed on deployment day?
The plan was a simple Kanban board with statuses. Reality added layers. The shop handles repairs, washing, and servicing on parallel tracks, so a bike can be in for a repair AND a wash simultaneously. That meant the system needed dual-track status handling, not a single linear pipeline.
Staff names needed to be assigned to jobs so the owner could see who was working on what, and service types had to match the exact categories the shop actually uses, not simplified versions.
None of this was in the original spec. All of it came from watching real people use the system on a real shop floor.
What were the results?
The shop went from tracking everything by memory to a fully digital pipeline. Every job is tracked from intake to pickup, every bike is photographed before work starts, and customers check their own status instead of calling. The owner can see every active job from his phone without being at the shop.
Staff adapted faster than expected. The shared PIN system meant no individual accounts to set up, and the Kanban layout mapped directly to how they already thought about jobs: new ones on the left, done ones on the right. Learning curve was a few hours, not days.
The whole system costs under 60 AED per month to run; no per-user fees, no platform subscription, just hosting.
Who does this system work for?
Any service business where items come in, get worked on, and go back to the customer. Bikes, cars, electronics, appliances. If your staff tracks jobs on paper, whiteboards, or in their heads, and your customers keep calling asking for updates, this same architecture applies.
- Car detailing and car wash: job intake with damage photos, service tracking, customer pickup notifications
- Electronics repair: device intake photos, diagnosis notes, parts ordering status, customer status page
- Appliance repair: field service scheduling, job status tracking, before/after documentation
- Tailoring and alteration shops: intake photos, measurement notes, fitting appointments, pickup notifications
- Furniture restoration: condition documentation, approval flows for cost estimates, progress photos
Running your service business from memory?
Free 30-minute assessment. We look at how your shop operates and tell you exactly what a system like this would look like for your business.
Book Free AssessmentRead Next
How I built a digital registration dashboard for a UAE rental business in 6 days
Paper forms to digital registration. 7 minutes down to 75 seconds.
Read more →Custom dashboard vs off-the-shelf: when does each make sense?
When to build, when to buy, and when it does not matter.
Read more →