BF scratch

Build your PC, but with your friend next to you, not a blind one that you need to teach and explain the context, but is right next to you, seeing the same thing.

Comment

About the Project

Inspiration

The idea for BF scratch came from my own attempt to build a desktop PC for the first time.

Right after finishing my military service, I wanted to know what the hype around the AI's were by myself. So I thought to start with a PC. I started comparing parts, watching YouTube, asking AI, and asking friends. The problem was that the recomendations were all so very different. Youtube videos focused on the general mass, naming phrases like frames per dollar for best optimal choices without fully understanding my needs on focusing on AI and development. Ai understood my context but gave outdated prices and has no idea what parts goes along with which. As someone who did not already understand PC hardware, especially when I was about to spend a significant amount of money, i just couldn't take the risk from anyone who doesn't understand mine or the market situation properly.

In the end, I gave up on building a desktop and bought a laptop instead, paying an extra for the premium that I may not have needed if I had access to the proper tools.

The issue was not that there weren't enough informatoin, it was the opposite. There were too many information, but nothing that I really needed. I needed to know the price, how the putting the parts actually seems like, where the cable goes, if the ram is compatiable with the CPU, do I have enough power supply before I buy this expensive hardware.

When I learned about WebMCP, that old idea suddenly made sense.

The biggest issue with AI assistants, when I tried to build a PC myself, I felt like getting advises from who is blind to the real world: whenever something changes, I have to explain the new situation again, paste a model name, or send another screenshot. I wanted the AI to feel less like a manager I had to report to and get confirmations from and more like a smart friend standing next to me, looking at the same PC and helping me build it.

That became 'BF scratch', build from scratch, a name implying that this is going to be your friend to help you build, not a manager that you need to work for.

What it does

BF scratch is designed to tackle the exact problem that I described: the stress of not seeing the same page.

The user can select, install, move, and replace PC components directly in an interactive 3D workspace. They can inspect compatibility, physical clearance, power requirements, cooling configuration, and component connections.

At the same time, a WebMCP-enabled AI can access the same underlying build state.

The AI does not guess the dimension of the GPU, or whether a power connector exists. It reads structured validation results, understands the user's intent, explains the problem, and helps choose or apply an appropriate solution. It is now, somethign that can give advice directly, looking at the same thing as the user.

That is the highlight: both sides are working on the same build.

A user can change a component manually, AI can see what changed, let the AI repair the configuration, and immediately see the changes in the same 3D workspace. No guessing from the AI and no prompts for the user.

How we built it

BS scratch is built with React, TypeScript, Vite, Zustand, Three.js, and React Three Fiber/Drei

We deliberately separated the project into several layers:

  • an authoritative build state
  • shared domain commands for human and AI actions
  • deterministic compatibility and readiness validation
  • atomic simulation and mutation logic
  • undo/history
  • the React Three Fiber scene
  • the WebMCP tool layer

All live changes pass through the same command layer, regardless of whether they originate from the GUI or an AI agent. The agent can also simulate a set of changes before applying them to the live build.

The current WebMCP interface exposes 16 tools, including build-state inspection, catalog and mount discovery, validation, component installation and movement, cable connection and disconnection, fan direction changes, simulation, case selection, auto-fill, and undo.

This allowed us to treat WebMCP not as a chatbot feature, but as another structured interface into the same application.

Challenges we faced

We learned that building as a team/ and working on a time-constrained task is vastly different compared to self-ran projects.

In my personal projects, I usually prefer to validate each layer carefully before moving on to the next part of the MVP. I actually make my AI agent go on it's self-validating loop until it reaches me to test it. sometime-to prevent hellucinations, I get a second agent to validate. This loop and seoncd validation, while it was able to get a better-bug free version, it was time costly as well; which was not a big issue in self-ran project. My teammate however, preferred to build visible functionality quickly and debug it afterward; which better suited not only in a team envorinment as I am not the only one working at the same given time-period, but also in a time-constrainted task as this hackathon. I think this difference came from our educational background of me being an economics student, and him being used of the debugging and time-constrained workflows due to his computer science background.

That difference created some friction at first, I did not understand my friend's inital result as almost none of the functions were delivered, farcry from our MVP.

We eventually found a compromise: we would not lower the quality bar of the MVP itself, but we would continuously produce visible, working milestones and refine them afterward. A mix of both of our workflows. We also had to define explicit contracts between components and responsibilities instead of relying on assumptions that would have remained in my head during a solo project.

What we learned

The biggest technical lesson was understanding what WebMCP can change about the relationship between an AI and a web application.

Before this project, I mostly thought about AI assistance as a wish made to the monkey's paw: providing a prompt to just wish for the goal to be completed, the AI reasons about it, and the user hope for the optimual result that they may have to trust it, especially on a pricy enviornment that you cannot retireve, like buying PC parts.

WebMCP made us think differently, the AI can participate directly in the workspace.

I also learned a lot about the difference between building alone and building with another person. Team development required clearer contracts, more explicit ownership, and compromise about how quickly to move versus how deeply to validate.

What I am most proud of

The moment I was most proud of was finally 'seeing' our screen. It was able to discover a problem, repair the build, and have the result immediately appear in my screen.

What made that moment especially meaningful was that I had not personally implemented or verified that part.

My teammate had.

When I saw their part of the system connect correctly with the architecture we had designed together, I felt a kind of satisfaction that was different from finishing an MVP alone.

It was no longer just the feeling of, “I" made this work.

It was the feeling of, “We" made this work.

at that moment, did I feel like the name BF scratch was worthy for what it delivered.

Built With

Share this project:

Updates

Submission history