Fixora

The problem

A repair shop runs on four different people wanting four different views of the same job. Customers want status. Technicians want a queue. Branch managers want load. Admins want everything. Building four apps is not an option on an assignment deadline.

How it was built

1. 01

   Modelled one data layer with role-scoped views so each of the four roles sees the same repair job through its own lens.

2. 02

   Used GPS branch matching to route a request to the nearest branch instead of asking the customer to pick one.

3. 03

   Built live repair-status tracking on Firebase so the customer view updates without a refresh.

4. 04

   Accepted photo uploads with repair requests, so a cracked screen is described by a picture rather than a paragraph.

5. 05

   Worked from design tokens with on-device testing and a structured git history — a production-style workflow inside a two-day window.

What shipped

• Four working roles in one shipped Android app, delivered on a two-day timeline.
• Three-star repository — one of the most-starred on the profile.
• Structured commit history and on-device verification rather than emulator-only testing.

In one paragraph

Fixora is a native Android application written in Kotlin with Jetpack Compose that connects four roles — customers, technicians, branch managers and administrators — in one device repair and service management platform. It matches customers to branches by GPS, tracks repair status live, and accepts photo uploads with repair requests. It is backed by Firebase, Supabase and SQLite, and was delivered within a two-day assignment timeline.