Starting with a familiar frustration
Many technical problems are difficult to describe but easy to point at. A user may say a computer is broken when the real issue is a loose cable, a blocked fan, or a repeating light pattern. My experience in technical support made that communication gap feel very real. I built Fixr to test a simple idea: what if a troubleshooting assistant could see what the user sees and guide them through the next safe step?
Designing the interaction
Fixr accepts text, images, and live camera input. The interface had to do more than send media to a model. It needed to help the user frame the component, capture useful context, and answer follow-up questions. I organized the response around observations, likely causes, confidence, and numbered checks. That structure makes uncertainty visible. If the system cannot confirm a damaged component from an image, it should say so and suggest a non-destructive check instead of presenting a guess as a diagnosis.
Safety before cleverness
Hardware guidance can create real risk. A confident but incorrect instruction can damage equipment or expose someone to power, heat, or sharp components. I added boundaries around actions that require opening a device, handling a battery, or working near mains power. The assistant prioritizes low-risk checks such as reseating an external cable, checking ventilation, reading an error code, or powering down safely. Escalation is part of the product, not a failure state.
What the build changed for me
Fixr taught me that multimodal AI is mostly a context-design problem. The model needs the right view, the right history, and a response format built for decisions. It also reinforced something I learned at the help desk: people do not want a lecture when their device is failing. They want one clear step, a way to report what happened, and confidence that the next step will not make things worse.