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.
Top comments (1)
I really like the shift from choosing individual parts to allocating a budget around the user's actual needs. The finite catalog and willingness to leave money unspent make the tool feel more trustworthy, and removing a fragile interactive component in favor of simple static tables is a great reminder that reliability matters more than flashy demos.