Building a budget-first PC parts calculator: allocation, not selection

Haixin GUI — Mon, 26 Oct 2026 03:07:29 +0000

Every PC part picker I tried assumed I already knew what I wanted. You open it, and it asks: which CPU? Which motherboard? Which GPU?

But if you have a fixed budget — say $900 — that is backwards. You do not want to research eight components. You want to know what $900 actually buys, and where the money should go.

So I built Partwise, a budget-first PC build calculator. This post is about the two decisions that shaped it, and one mistake worth stealing.

1. Model allocation, not selection

A traditional picker is a selection tool: you choose parts, it tells you if they fit. That works when the user already knows the target.

A budget-first tool inverts it. The input is a total budget plus a workload (gaming, creating, work). The output is a parts list where each component gets a weight, and the weights are what the user actually cares about.

The interesting code is not "is this GPU compatible" — it is "if the user raises the GPU priority, which other components give way, and by how much".

const weights = {
  gaming:   { gpu: 0.42, cpu: 0.20, ram: 0.08, storage: 0.08, psu: 0.07, case: 0.07, board: 0.08 },
  creating: { gpu: 0.32, cpu: 0.28, ram: 0.14, storage: 0.12, psu: 0.06, case: 0.04, board: 0.04 },
};

The ratios are opinionated and I expect people to disagree. That is fine — the argument is now about allocation, not about which part to pick first.

2. Keep the catalog finite and say so

The calculator uses a finite reference catalog with real prices. It will not invent a GPU to absorb the last $40 of a budget.

That constraint felt like a weakness at first. It turned out to be the most trustworthy part of the product: a leftover balance is normal, and telling users "you do not have to spend everything" is more useful than padding a list.

3. The mistake: I shipped an interactive component too early

The compatibility checker started as a small interactive widget: four dropdowns, instant pass/fail. It crashed on every interaction. Not sometimes — every time, with the same hydration error:

NotFoundError: Failed to execute 'insertBefore' on 'Node'

Server-rendered markup and the first client frame disagreed, React tried to patch a node that was not where it expected, and the page fell over. I tried three fixes: an error boundary, rendering after mount, and a client-only route. Each changed the symptom (white screen, then a missing component, then "checker failed to load") without removing the cause.

What finally worked was deleting the component. The page is now four static reference tables — sockets, DDR4/DDR5, GPU clearance, PSU wattage — rendered on the server, with zero client state.

It is less impressive in a demo. It is strictly better for the person who just wants to know whether a Ryzen 5 7600 fits a B650 board.

What I would do differently

Build the static version first, then ask whether interactivity earns its complexity.
Treat hydration as a product risk, not a build warning.
Write the copy for the empty state before building the feature. If the empty state is confusing, the feature is probably wrong.

The calculator is free and needs no signup: pcpartscalc.com. If the allocation ratios look wrong to you, I would genuinely like to hear which ones and why — that is the part I am least sure about.

DEV Community: Haixin GUI

Building a budget-first PC parts calculator: allocation, not selection

1. Model allocation, not selection

2. Keep the catalog finite and say so

3. The mistake: I shipped an interactive component too early

What I would do differently