This is my submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.
Have you ever been shopping for PC components and suddenly realized you don't remember whether a particular GPU will work with your current power supply?
Maybe you're browsing a computer store, looking through secondhand hardware at a local marketplace, or considering a deal from someone selling a used graphics card. You find something interesting, check the price, and then start opening browser tabs to look up its specifications.
What's the power requirement? Does it fit my motherboard? Is my PSU sufficient? Will this upgrade blow through my budget?
You could memorize every specification of your PC, I suppose. You could also memorize the entire periodic table while you're at it. Neither sounds particularly practical.
That was the problem I wanted to explore with RigCheck, a privacy-focused PC component compatibility assistant that combines local AI vision with deterministic compatibility checks.
The idea behind it is simple: I want to be able to check a component using my phone, wherever I happen to be, while keeping the actual AI inference and my saved PC configuration on my own computer.
And yes, that means I ended up building a web application that uses my home PC as its AI backend. Because apparently building a simple lookup tool would have been too easy.
What I built
RigCheck lets users upload or capture a photo of a PC component label, extract the specifications visible in that image, and compare the available information against a saved PC configuration.
The application currently includes:
- A mobile-friendly component scanner that supports camera capture and image uploads.
- Local vision inference using Google's Gemma 3 4B through Ollama.
- Optional technical reference search through SerpAPI when additional specifications are needed.
- A deterministic compatibility engine for supported checks, including PSU wattage, CPU socket, form factor, and budget.
- A configurable PC profile stored locally on the host computer.
- Three clear overall verdicts: Compatible, Incompatible, and Needs verification.
The last one is particularly important. Hardware compatibility is not something I want an AI model to confidently guess about.
If RigCheck cannot establish a required specification, it should identify the missing information and leave the relevant check as unknown. A missing specification is not evidence of compatibility.
Demo and source code
Live demo: RigCheck on Render
The frontend is hosted on Render, while analysis requires the local backend and active tunnel to be running. If the temporary backend URL is unavailable, the live analysis workflow may not work.
Source code: edgiaxel/RigCheck on GitHub
The repository contains the frontend, backend, setup instructions, and implementation details needed to explore the project.
For the submission, I have included screenshots of the interface and analysis workflow. They demonstrate the implemented UI and reported results, although they are not a substitute for a video showing the complete interaction.
Why does this fit the Touch Grass theme?
I didn't want to build another application whose entire purpose was to tell people to go outside.
Instead, I wanted to explore what useful software could look like when someone is actually out in the world trying to solve a problem.
Imagine browsing a physical computer store or inspecting a used component from a local seller. You have your phone, the component is right in front of you, and you want to know whether it's worth considering before making a purchase.
Your current PC configuration is at home. The component's specifications might be printed on its box, scattered across manufacturer documentation, or missing from the seller's listing.
RigCheck is an attempt to bridge that gap.
The phone becomes the interface for collecting information and viewing results. My home computer does the heavier AI work. Rather than making the user manually transcribe a list of specifications into a desktop tool, the application starts with an image and builds a structured analysis from it.
I haven't tested this in a physical computer store yet, so I won't pretend the entire real-world shopping workflow has been validated. What I have built is a working prototype of that workflow, including mobile access, image analysis, and compatibility reporting.
That distinction matters. The idea is grounded in a real-world scenario, while the prototype is the first step toward making it practical.
The interesting part: keeping the AI local
One of my main design decisions was to run the vision model on my own PC instead of sending component images to a hosted AI API.
RigCheck uses Gemma 3, specifically the 4B model, through Ollama.
The model receives the uploaded image and extracts information such as the component category, brand, model, and visible technical specifications. The backend validates the structured output before passing the extracted information to the compatibility engine.
I chose this approach for two reasons.
First, I wanted to experiment with a genuinely useful application of an open-weight vision model rather than simply wrapping a hosted chatbot API.
Second, privacy matters here. A component photo might seem harmless, but I don't think users should automatically have to send their images and hardware-related information to a third-party AI service just to get help with a purchase.
With the current architecture, the image is processed in memory and passed to the local Ollama service for inference. The application does not intentionally persist uploaded images to disk, and the vision inference happens on my own machine.
There is a practical trade-off, of course: the host computer needs to be running, and remote access requires a network connection. Local inference does not magically eliminate every external dependency.
Making uncertainty explicit
Vision models can misread labels, miss small text, or fail to identify a particular product variant. Even when the model extracts the product name correctly, that doesn't mean it knows every relevant electrical or physical specification.
For example, a GPU's product family alone isn't enough to establish every detail about a particular manufacturer's variant.
RigCheck therefore separates AI-assisted extraction from compatibility evaluation.
The model extracts information. The backend validates the response and evaluates the compatibility rules it actually supports. Missing information remains unresolved rather than being silently filled with a plausible-looking number.
This is why the application distinguishes between:
- Pass: the available evidence satisfies the implemented check.
- Fail: the available evidence establishes that the check is not satisfied.
- Unknown: the information is insufficient to reach a reliable conclusion.
These are individual check statuses. The overall result is presented separately as Compatible, Incompatible, or Needs verification.
It's a relatively small design decision, but I consider it one of the most important parts of the project. An assistant that admits what it cannot establish is more useful than one that invents certainty.
How the system works
RigCheck is built around a separation of responsibilities: the vision model extracts information, the backend manages the data and evaluates rules, and the frontend makes the results accessible.
1. Image input and local vision inference
The user captures or uploads a component image from the browser.
The React frontend sends it to the FastAPI backend, which validates the upload and passes the image to the local Gemma 3 4B model through Ollama.
The model returns structured information about the component. Pydantic models validate the response, while unresolved fields are preserved explicitly.
2. Optional technical reference search
Sometimes the product label does not contain enough information to evaluate a particular requirement.
RigCheck can optionally use SerpAPI to search for additional technical references based on the identified component and relevant search terms.
This is an important privacy boundary: the search service may receive the component identifier and technical query, but the uploaded image and complete saved PC profile are not intentionally sent to SerpAPI.
Search results also need to be treated carefully. A search snippet is not automatically authoritative evidence, and a result for a similar product is not necessarily a result for the exact model being inspected.
3. Deterministic compatibility evaluation
Once the relevant information is available, the backend evaluates supported compatibility rules.
Examples include:
- PSU wattage: comparing available component power requirements with the configured power supply capacity.
- CPU socket: checking whether the identified CPU socket matches the saved motherboard socket.
- Form factor: evaluating supported motherboard and enclosure constraints when the required information is available.
- Budget: comparing the user-entered component price in Indonesian rupiah (IDR) with the configured budget.
These checks are deliberately separate from the vision model. The model does not get to invent a compatibility verdict simply because its extracted specifications look convincing.
This is an initial compatibility engine, not a universal guarantee that every PC component will work together. Physical GPU clearance, exact product variants, connector requirements, and other constraints still require appropriate rules and reliable source data before they can be checked confidently.
The architecture
One interesting part of this project was figuring out how to make local inference accessible from a phone without moving the model to a cloud server.
The application uses a hybrid architecture:
[Phone Browser]
|
v
[Render Static Frontend]
|
v
[Cloudflare Quick Tunnel]
|
v
[FastAPI Backend on My PC]
|
+--------------------------+
| |
v v
[Local Ollama + Gemma 3 4B] [Local PC Profile]
|
v
[Structured Extraction]
|
v
[Compatibility Rule Engine]
|
v
[Analysis Returned to Phone]
The React frontend is built with TypeScript and Vite. FastAPI handles the API endpoints, request validation, authentication, profile storage, model communication, and compatibility evaluation.
Ollama runs locally on my PC, with Gemma 3 4B handling vision inference. The saved PC profile is stored locally rather than in a hosted database.
For remote access, I used Cloudflare Tunnel to connect the browser to the local application without configuring router port forwarding or exposing Ollama's port directly.
I also experimented with deploying the frontend as a Render Static Site. This separates hosting the interface from running the actual AI workload: the frontend can be served by Render while the backend and model remain on my computer.
That arrangement has a limitation worth mentioning: the backend must still be reachable, and the computer running the model must be online for analysis to work. The temporary Cloudflare Quick Tunnel URL can also change when the tunnel restarts.
The goal wasn't to pretend that local infrastructure has no operational requirements. It was to make the division between the hosted interface and local AI processing work in practice.
The technology stack
| Component | Technology |
|---|---|
| Vision model | Google Gemma 3 4B |
| Local inference | Ollama |
| Backend API | Python, FastAPI, Pydantic |
| Frontend | React, TypeScript, Vite |
| Technical reference search | SerpAPI |
| Remote access | Cloudflare Tunnel |
| Frontend hosting | Render Static Site |
| Testing | pytest, frontend linting, production build checks |
I also implemented authentication and session handling for the protected API, upload validation, security headers, and checks intended to prevent private configuration files from being exposed.
The backend and frontend were tested separately, and I ran the local image-analysis workflow to verify that the model could extract a component's specifications and pass the result through the compatibility engine.
Those tests establish that the implemented workflow operates under the tested conditions. They don't establish universal compatibility accuracy or prove that every real-world product label can be recognized correctly.
Building it with an AI coding agent
I built RigCheck with the help of Gemini coding agent I use inside Antigravity IDE.
I approached the work in phases rather than asking an agent to generate the entire application in one enormous prompt.
First came the backend: API endpoints, local profile storage, image validation, structured model output, and compatibility rules.
Then came the frontend. I experimented with Google Stitch to explore the interface design before implementing the responsive React application.
After that, I worked on remote access, authentication, and the integration between the hosted frontend and the local backend.
This phased approach helped me inspect each milestone, run tests, and review what the agent actually implemented before moving on. It also made it easier to catch the difference between a feature that looked good in a mockup and a feature the backend could genuinely support.
AI-assisted coding made the implementation faster, but it didn't remove the need to make architectural decisions, inspect the generated code, validate the API contracts, or test the resulting application.
What I learned
The biggest lesson from RigCheck was that getting a vision model to recognize a component is only one part of building a useful AI application.
The harder problem is connecting that extraction to a trustworthy workflow.
A model can recognize a GPU name, but that alone doesn't establish power compatibility. A search engine can return a specification, but that doesn't guarantee it belongs to the exact product variant. A frontend can display a green badge, but that doesn't make the underlying conclusion correct.
I had to think about how the model, backend, search service, profile storage, and interface should work together, including what happens when information is missing.
I also learned that keeping AI inference local changes the deployment story. The frontend can be hosted independently, but the actual inference workload still needs access to the machine running Ollama. Cloudflare Tunnel made remote access possible without turning the project into a conventional cloud-hosted AI application.
There is still plenty to improve. More compatibility rules need to be implemented and tested, reference verification needs to remain conservative, and the real-world shopping workflow needs to be evaluated outside my own development setup.
But the core idea is now a working prototype rather than just a diagram.
Final thoughts
I started RigCheck because I wanted to build something that connected AI to a practical activity outside my usual desktop workflow.
What began as a PC hardware compatibility idea grew into an experiment involving local vision inference, structured extraction, deterministic rule evaluation, responsive web development, and remote access to a computer running an AI model.
It isn't a universal hardware compatibility checker, and it doesn't eliminate every dependency on the internet. It is an attempt to make a specific task easier while keeping the most sensitive parts of the workflow under the user's control.
For me, that's what makes this project interesting: the AI is not the product by itself. It's one component in a tool designed to help someone make a better decision in the real world.
And if RigCheck can eventually save someone from buying a component that doesn't work with their existing build, then it will have done something more useful than simply becoming another AI demo.
Thanks for reading, and happy Hacktoberfest!
Top comments (0)