FixAI

Landing Page
Login Page
Main Menu
Profile
Repair Submission
Priomary Diagnosis
Generated guide
Generated Manual based on online sources
PDF Manual Page 1
PDF Manual Page 2
All Repairs
Socials
Leaderboard
Messages
Skill Tree

Inspiration

It began with a fan. One of us had a small appliance fail at home, the kind of thing that is plainly not destroyed, only broken in some small and specific way, and the choice narrowed to three poor options: pay a technician more than the item was worth, work through a dozen contradictory videos for the wrong model, or give up and buy a replacement.

That last option is the one most people take, and not because the item cannot be fixed. They take it because the distance between broken and fixed is full of friction: not knowing what has actually failed, not knowing whether it is safe to open, not knowing whether the effort is even worth it. This is the same problem that runs through every kind of support. The help exists, somewhere, but it is scattered, the language is technical, the nearest guide concerns a different appliance, and nothing tells a worried person whether the job is safe to attempt. Under stress, and without spare money for a callout or a new unit, the rational move becomes to throw away something that was never truly broken. Multiply that single hesitation across a planet that discards more every year, and an enormous share of what we call waste is not waste at all. It is simply unsupported.

We wanted to close that gap directly: point a phone at the broken thing and receive an actual diagnosis and a safe way forward, not a page of search results.

What it does

FixAI is a mobile first web application that turns a photograph of a broken household item into plain language, a checklist, and a clear next action. The flow is deliberately direct. A user photographs the item, and a model identifies what it is, what is most likely wrong, how confident it is, the cost to repair against the cost to replace, and how dangerous the repair would be. That last judgement governs everything that follows.

Purely mechanical items, the safe ones, return a full repair manual at once. Items that involve power or water keep their steps locked behind a safety checklist, and, where the user chooses, behind a photograph that the model itself checks to confirm the item is genuinely unplugged or isolated before anything unlocks. Items that involve live wiring, gas, or structure are refused outright, with no steps under any circumstances; in their place the application explains why and offers a single tap to a real local professional.

Once a repair is underway, a guided mode walks the user through it one step at a time, reads each step aloud, runs the wait timers a job requires, and holds its place offline so a dropped connection in the middle of a repair loses nothing. When the work is done, the model compares an after photograph against the original, and only a verified repair earns progress. That progress feeds a skill tree across five repair categories, a set of self paced courses, weekly challenges, friend leaderboards, and a community dashboard that totals the money saved and the electronic waste prevented across every user.

This is the part a search cannot reach. A search returns documents that match a query; it cannot look at the object in someone's hands, classify how dangerous the job is, refuse the ones that are unsafe, or confirm afterward that the repair actually worked. Perception, refusal, and verification are exactly what a stressed and uncertain person needs, and exactly what a list of links cannot supply.

How we built it

The client is built on React 18, Vite 5, and TypeScript, with Tailwind driving a centralised 60/30/10 colour system that adapts its layout for right to left languages. i18next carries the interface across fifteen languages, and a service worker turns the whole application into an installable, offline capable progressive web app. The backend is Supabase: Postgres with Row Level Security on every table, so a user can only ever read their own data; edge functions written in Deno and TypeScript that run every model call on the server, so an API key never reaches the client; and Realtime for live messaging. Google Gemini 2.5 Flash performs all five runtime calls, diagnosis, manual generation, verification, the safe state check, and web grounded search of external guides, in structured JSON mode, and each is generated directly in the user's chosen language rather than translated after the fact.

Safety is enforced twice. Classification happens inside the model prompt, but it is checked again on the server, where a safeguard strips every step from a dangerous result no matter what the model returns. The application therefore cannot be talked into giving unsafe instructions even if the model misbehaves.

Challenges we ran into

The hardest design problem was not coaxing the model into identifying a fault; it was deciding what the system must never be permitted to do. We were unwilling to let a single model judgement be the only thing standing between a user and a live wire, so we built redundancy into the safety system itself: the model classifies, the server revalidates and enforces, and for the middle tier the model has to confirm visually that the item is safe before any step unlocks.

Caching was the next problem. Manuals are cached by item, fault, and language to keep model costs down, which meant making certain that a cache entry in one language could never quietly serve another, and that the same fault repaired twice could not be farmed for full progress.

Licensing forced a smaller compromise. The brand fonts we first chose could not be embedded legally from a web service, so we found and verified close, openly licensed substitutes, Manrope and Archivo, without giving up the visual identity we had designed around.

Budget shaped the rest. Gemini credits are billed by usage, and as a student team we had to keep every model call necessary rather than decorative, which is why all thirty five self paced courses are written ahead of time as zero cost content rather than generated at runtime.

Accomplishments that we are proud of

We are proud that the three tier safety system is enforced on the server rather than merely requested in a prompt, which means FixAI can refuse a dangerous repair even when the underlying model gets it wrong. We built a complete loop, from diagnosis to guided repair to verification, with progress awarded only for a fix the model has confirmed. We made the accessibility real: fifteen languages with right to left support, and model output authored natively in the user's language rather than retrofitted onto it. We built the guided mode to work offline, for the single moment a user's hands are full and the application cannot afford to fail them. And we built the gamification, the skill tree, the fading scaffold, the courses and challenges, on real verified repairs rather than vanity metrics.

What we learned

We learned what it takes to build responsibly with AI under real constraints, not in the abstract but in code: what is actually required to make a refusal enforceable rather than merely requested, how to design a safety critical experience around a model's confidence score, and how much of responsible AI comes down to deciding concretely what the system is never allowed to do and then proving it on the server. We also learned a great deal of full stack engineering, the design of Postgres secured with Row Level Security, the architecture of edge functions, and what happens to a plan when the API budget tightens halfway through a hackathon.

What is next for the team

Next, we intend to restore full Gemini billing so every feature runs on demand without rate limits, to move the repair cost and environmental impact estimates from static assumptions to live, region aware sources, to add push notifications for messages, friend requests, and weekly challenges, and to introduce background synchronisation so that repairs verified offline upload themselves the moment a signal returns. Beyond that we plan to open the platform to community contributed repair guides with moderation, to layer human reviewed translations on top of the fifteen languages already shipped, and to harden the system with full continuous integration, automated tests, and shared rate limiting as the user base grows.