Building a Real-Time PC Compatibility Engine for 10,000+ Components

PC BuildIT — Thu, 10 Sep 2026 15:28:36 +0000

Building a PC builder tool sounds simple until you actually try it. The hard part isn't the UI — it's the compatibility graph.

We run PC BuildIT, an Indonesian PC building platform with ~11,000 components in the database. Here's what we learned building the compatibility engine.

The compatibility rules are not independent

A naive implementation checks each rule in isolation: does the CPU socket match the motherboard socket? Does the RAM type match the motherboard's supported memory? Is the PSU wattage above the estimated draw?

The problem is that these interact. A CPU change can force a motherboard change, which forces a RAM type change, which changes the power draw, which changes the PSU requirement. Treating them as independent checks gives you false positives — a build that passes every individual check but is internally inconsistent.

We model it as a constraint propagation problem: each component carries typed attributes (socket, memory type, form factor, TDP, dimensions), and adding a part propagates constraints to every other slot. The simulator recomputes the whole build on every change.

Wattage estimation is the messiest part

TDP is not power draw. Manufacturers report TDP inconsistently, and transient spikes on modern GPUs can exceed sustained draw by 2x. We estimate with a safety margin rather than pretending precision we don't have — under-promising on PSU headroom is much better than a user building a machine that shuts down under load.

Data quality beats data quantity

We started with a scraped dataset that had ~15% bad rows: wrong sockets, mismatched memory generations, duplicate entries with different capitalization. Every bad row produced a user-visible wrong answer. Spending a week cleaning 11,000 rows was worth more than any feature we shipped that month.

The SEO angle nobody talks about

If your pages render client-side, a crawler sees an empty shell. We had 10,854 component pages with no server-rendered content — invisible to search. Moving the data fetching to server components was a two-day refactor that changed the entire discovery picture.

The lesson: for a data-driven site, SSR isn't a performance optimization, it's the difference between existing and not existing.

What's next

We're working on live price aggregation across Indonesian marketplaces, and a "can I run it" checker that compares your specs against a game's requirements — you can try that here.

If you're building anything with a large product catalogue, feel free to ask about the constraint model — happy to share what we learned.