Web Applications · Operations
FixHub Repair Shop Management
One platform for the full phone-repair lifecycle: intake, technicians, parts, warranty, payments and reporting.
- Status
- Prototype
- Year
- 2026
- Role
- Designer and developer
- Client
- Shared with permission
01
Overview
A role-based management app that follows each repair from Received to Collected and ties it to customers, parts stock, warranty cover, payments and finance. The current build is a front end running on an in-memory demo data layer.
- React
- TypeScript
- Recharts
- jsPDF
- i18next
02
The challenge
Repair shops often run on paper job cards, WhatsApp threads and disconnected tools, so jobs, parts, warranties and payments are hard to track together.
03
System requirements
- Repair job queue with a workflow timeline: Received, Diagnosed, Parts Pending, In Progress, Ready, Collected
- Print-ready receipt and job card with a warranty certificate
- Parts catalogue with reorder levels and low-stock states
- Customer profiles with segments and repair history
- Warranty tracking plus returns and refunds
- Loyalty programme with Bronze, Silver, Gold and Platinum tiers
- Device authenticity certificates with an IMEI checker
- Analytics, expenses against budget, and eight report types
- Five staff roles that control which modules each person can open, with an audit log
04
Solution architecture
Content needed: architecture, drawn only from documented components
05
Implementation
Repair ticket board with status counts, filters and job cards showing device, issue, technician, ETA and cost. Demo data. 
Parts inventory table with stock levels, product codes, unit cost and selling price, with low-stock items highlighted. Demo data. 
Warranty tracker with active, expiring and expired warranties, and a returns and refunds tab. Demo data.
06
Technical decisions
- Role-based access so each staff member sees only the modules their job needs
- An in-memory mock data layer so the whole product can be demonstrated without a backend
07
Results and validation
Content needed: measured results with period and method. Never estimated.
Evidence
- Public repository with a module-by-module README
08
Lessons learned
Content needed: what you would do differently
Content checklist (remove once filled)
- Whether it is live in a shop, and for which client (permission to name them)
- Whether the deployed version uses Supabase. The README describes a front end with mock data, so keep the status as Prototype until confirmed
- Any results, only with a period and method
09