The starting problem
A conventional repair website is useful at the exact moment something breaks. That creates a weak relationship: the customer searches, repairs the device and may have no reason to return until the next failure.
The platform direction was to make Fix My Gadget useful across the device lifecycle while keeping the public repair pages understandable for search and first-time visitors.
The architecture
Repair Hub
Structured intake captures the device, model, fault, urgency, data priority, incident history and photos. A private ticket lets the customer follow progress and respond to a quote without relying on repeated WhatsApp messages.
My Devices
Customer accounts connect saved devices to repair and invoice history, warranty documents, booking information and future health checks. The device record becomes more valuable over time.
Device Doctor
Device Doctor creates utility before a repair is needed. Repair-vs-replace, battery health, upgrade guidance and device-health checks can be saved to the customer profile and handed directly into the Repair Hub.
Business Fleet
Business clients can organise multiple assets and staff under a company workspace. That creates a natural bridge between workshop repairs and longer-term business support.
AI Repair Desk
The AI layer is designed to answer questions from permitted repair-ticket data rather than acting as a disconnected generic chatbot. A local fallback still answers status and account questions when an online AI provider is not configured.
Technical decisions
The first platform versions were deliberately designed to run on ordinary PHP hosting with protected JSON storage. That reduced deployment friction while the customer workflow was being proven. External services such as payments, messaging and AI were built as configurable adapters rather than hard-coded secrets.
Security controls include protected storage paths, CSRF checks for state-changing account/admin actions, strict sessions, rate limits, private document delivery and separation between public and private ticket data.
SEO and product design together
The public repair site remains a search and education system, while private app functionality lives behind clear customer routes. The goal is not to turn every SEO page into an app screen or every app screen into an indexable landing page.
What this case study does not claim
It would be easy to attach an impressive traffic-growth percentage or conversion-lift number to this page. We are not doing that without a verified measurement period and a clean baseline. This case study documents the architecture and working functionality today. Measured acquisition and conversion outcomes can be added later from Analytics and Search Console evidence.