I Built ReTrace to Help Generator Technicians Remember Every Repair

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

I built ReTrace, a voice-first repair-history assistant for independent generator repair technicians.

In Nigeria, many households and businesses rely on generators when public electricity is unavailable. When a generator develops another problem, technicians may have to rely on memory, old notebooks, WhatsApp messages, or scattered notes to remember what was repaired previously. This can lead to repeated troubleshooting and replacing parts without having the full repair history available.

ReTrace gives technicians a place to keep that history.

A technician can create a customer and generator profile, record a voice note after a repair, and let AI turn it into a structured repair record. The technician reviews and corrects the draft before confirming it. Later, they can search previous repairs or open a generator's timeline to see what was documented.

ReTrace is not a diagnostic tool. It helps technicians retrieve their own records instead of pretending to know what is wrong with a generator.

Who would pay for it? My initial target is independent generator repair technicians who handle repeat customers and multiple generators. A possible business model is a free entry-level plan and a paid plan for technicians who need more repair history and workflow features. That pricing model is still a hypothesis; I have not validated willingness to pay yet.

Demo

Live app: https://retrace-three.vercel.app/

Demo video: https://youtu.be/W0GFRnCktkc

Code

GitHub repository: https://github.com/sniperchief/ReTrace

ReTrace is built around open-weight AI models, with the inference service separated from the web application.

How I Built It

I built ReTrace with Next.js, TypeScript, Tailwind CSS, MongoDB integration, and Better Auth for authentication.

The AI workflow uses two open-weight models:

• Whisper Small transcribes a technician's voice note into text.
• Gemma 4 E2B extracts the transcript into structured repair fields, such as the reported problem, diagnosis, work performed, and parts replaced.

The application creates a draft rather than automatically treating the model's output as fact. The technician must review and confirm the record before it becomes part of the repair history. This matters because a repair record needs to reflect what the technician actually said and did, not what a model guesses.

I put the models in a separate Python inference service using llama.cpp for Gemma inference. The frontend is deployed, and I tested the real models locally on my laptop.

On that machine, processing a 30–60 second voice note took approximately 1.5–3 minutes from upload to a filled-in form. That is useful proof that the workflow can run locally, but it is not yet fast enough to assume every technician will enjoy using it.

I also tested seven computer-generated recordings using US English voices. Those tests helped me check the workflow, but they do not establish how accurately the models handle Nigerian English, Pidgin, local names, or noisy repair workshops.

The web application and local inference tests pass. However, I have not yet verified the full AI workflow on the planned hosted inference service or tested the MongoDB Atlas integration end to end.

Why Does Open Innovation Matter?

For ReTrace, open innovation is not just about making the code public. It affects how I can build and potentially sustain the product.

1. I can experiment without paying a commercial API for every voice note.

ReTrace needs transcription and structured extraction. If every repair record required calls to paid AI APIs, usage costs would grow with the number of repairs processed. Running open-weight models locally let me build and test the complete AI workflow without paying per-request model API fees.

That does not make production hosting free. Inference still requires computing resources, and I have not yet measured the cost of running the service reliably for real users. But I can investigate the economics before committing to a commercial API bill.

2. I can control how the models are used.

A repair history is a record of work performed, not a place for an AI model to fill gaps with plausible-sounding details. During testing, Gemma twice invented a date and once produced a ₦0 cost. My validation caught these cases, and the workflow requires technician review before a record is confirmed.

Having control over the inference pipeline lets me build and improve those safeguards around the specific task ReTrace performs. The safeguards are application-level controls; using an open model alone does not guarantee accurate output.

3. I can choose and change models as the product develops.

The needs of a generator technician are more specific than general transcription or text extraction. Nigerian English, Pidgin, workshop noise, local part names, and technical vocabulary may all affect the results.

I have not fine-tuned either model yet, and I cannot claim that my current setup outperforms a closed API. What open-weight models give me is the ability to experiment with different models, prompts, validation rules, and eventually domain-specific adaptation without making the entire product dependent on one provider's API.

4. Privacy needs to be designed, not promised.

Repair histories can contain customer details and information about a technician's business. ReTrace separates technicians' records, and uploaded audio is processed rather than permanently stored by the application.

However, audio is sent to the inference service for processing. I am not claiming that the entire deployed system runs locally on the technician's device or that open weights automatically make the system private. The advantage is greater control over where inference runs and how data is handled as the product develops.

Where did open models work better than a closed API?

At this stage, the clearest advantage is control and the ability to develop without per-request commercial model charges. I have not run a fair, side-by-side evaluation against a closed API, so I cannot honestly claim better transcription accuracy or extraction quality.

For a solo builder with no budget for paid compute, open-weight models made it possible to build and test the core AI workflow. The next step is to verify hosted inference, test with real technicians, measure accuracy on real repair notes, and determine whether the operating costs support a sustainable business.

My First User

I focused on how ReTrace could help an independent generator repair technician keep records without having to write everything down manually.

The feedback highlighted the potential value of recording repairs by voice, reviewing the generated details, and retrieving a generator’s repair history when a customer returns.

“The voice note feature is useful because sometimes you finish a repair and don't have time to write everything down. Being able to explain what the problem was, what you changed, and save it as a record would make things easier.

One thing I would recommend is making it faster to find a customer's previous repairs. I would also want to be sure the system gets the parts and repair details right, because those are important when the same generator comes back.”

The feedback points to two priorities for ReTrace: faster repair-history retrieval and accurate AI-generated records. The technician should always be able to review and correct the details before saving them.

My next step is to validate these points with a real technician, especially whether ReTrace fits into their daily workflow and provides enough value for them to use it regularly.

Prize Categories

• Open-Source AI Challenge: ReTrace uses open-weight models at the core of its voice-to-repair-record workflow.

I chose this approach because the AI is central to the product, not an unrelated integration added for a challenge. Whisper and Gemma turn a technician's spoken repair notes into searchable records, while the application keeps the technician in control of what gets saved.