Building a Better PC Builder for PCMR

Building a PC should feel exciting

Building your own gaming PC is one of those projects that is both more accessible and more intimidating than it first appears.

The individual decisions are understandable. Pick a processor. Pick a graphics card. Add memory, storage, a power supply, and a case. But once those decisions interact, the number of ways to get something subtly wrong grows quickly. A part can look like a good deal and still be the wrong choice for the rest of the build. A specification can be technically compatible while making the finished computer unnecessarily difficult to assemble or upgrade.

That is the problem we have been working on at PCMR: making a better PC builder for people who want to choose their own components without needing to become hardware experts first.

PCMR started as a Swedish price comparison site for PC hardware. The first version of the builder could help you select parts, but it still assumed that you already understood how a computer goes together. The new direction is more ambitious: the new-build flow should help someone go from an empty page to a sensible, purchasable build, while still giving experienced builders complete control.

The real product is confidence

A list of components is not enough. A useful PC builder needs to answer the questions that appear between the product pages:

• Will these parts work together?
• Am I paying a reasonable price?
• Is this build balanced for what I want to do with it?
• What am I forgetting?
• If I change one part, what else needs to change?

Those questions are connected. Choosing a different processor can affect the motherboard. The motherboard can affect memory support and the case. The graphics card affects the power supply, available space, and, often, the total budget. The interface needs to make those relationships visible without turning the experience into a spreadsheet.

The goal is not to hide the complexity. It is to put the complexity in the right place: in the product's rules and data, rather than in the user's head.

Compatibility is the foundation

Compatibility checking is easy to describe and difficult to get right. The builder now treats it as a first-class part of the experience rather than a final form validation step.

It is tempting to think of it as a collection of warnings: this socket does not match that socket, this component needs more space, or this power supply is too small. But a useful builder has to do more than reject obviously invalid combinations. It has to help people understand why a choice matters and what alternatives they have.

That changes the design of the whole experience. A warning should not be a dead end. It should point towards a decision:

This part does not fit this build because of X. Here are the changes that would make it work.

That is a much better interaction than allowing someone to complete a build and discover the problem only when the boxes arrive. It also means the API has to understand more than product categories. It needs to reason about sockets, memory, form factors, clearances, power, and the relationships between the selected parts.

The result is a set of verdicts attached to the build and its slots. A part can be compatible, incompatible, or still need more information. That last state matters: pretending that incomplete data is a clean "yes" is worse than explaining what is unknown and giving the user a way to resolve it.

Price is part of the decision

Component selection is not just a technical exercise. Most builds have a budget, and prices move.

Showing a component without showing its cost makes the choice incomplete. Comparing prices without considering compatibility is just as misleading. PCMR's builder brings those concerns together so that the build can be evaluated as a whole: the parts, the total cost, and whether the result makes sense.

This also makes trade-offs easier to see. A slightly more expensive component may remove the need for another upgrade. A cheaper part may leave room in the budget for a better graphics card. There is rarely one universally correct build; there are only better and worse choices for a particular goal.

Guiding without taking over

There is a balance to strike in any configuration tool.

If the builder gives users no guidance, beginners are left alone with a catalogue of unfamiliar specifications. If it makes every decision for them, experienced users lose control and beginners never learn why the recommendations are sensible.

We want PCMR to sit in the useful middle. The user should be able to make the decisions, while the builder supplies the context. That has led to several entry points instead of one monolithic workflow:

• compatibility checks when a choice affects the rest of the build
• a guided builder for people who want to start with a budget or a goal
• a traditional slot-by-slot builder for people who already have a plan
• "Passar med" suggestions from product pages
• candidate lists that can be filtered by brand, store, name, and price
• prices that make budget trade-offs visible
• a clear view of what has already been selected
• feedback that helps explain the consequences of changing a part

That makes the tool useful for someone building their first PC, without making it frustrating for someone who already knows exactly which components they want. You can start from a product in the component catalogue, add it to a build, and let the builder narrow the next choices; or start from an empty build and choose every slot yourself.

A better builder is an information problem

The visible interface is only one part of the work. Behind it is a large, changing set of product data and relationships.

Parts have specifications, prices, dimensions, power requirements, and compatibility constraints. Those facts need to be represented consistently enough that the builder can reason about them, while still being understandable when they reach the user. The quality of the experience depends on both sides: good data and good decisions about how to present it.

This is where the work spans both PCMR and Hembiosystem. The PCMR product catalogue and compatibility work provide the product side of the system: the API can return compatible candidates, verdicts, prices, power information, and related products. Hembiosystem uses those PCMR products in its HTPC section, another example of presenting technical products through a more useful buying context. PCMR turns the same information into a builder that people can actually use. Keeping that boundary explicit lets the frontend stay focused on decisions while the backend owns the rules and product data.

It also gives us a place to improve the underlying data. Product specifications are not always perfect, so one of the planned parts of the workflow is letting visitors report an incorrect specification. A compatibility system is only trustworthy if there is a path for correcting the facts it relies on.

Builds are meant to be used

A build is not finished when the last slot is filled. People want to come back to it, ask someone else for advice, and buy the parts when the timing is right.

The new builder supports saving and editing builds, copying an existing build to make a variation, and sharing a build with a link. The saved-builds view keeps those builds available in the browser, while shared builds show the selected parts together with their compatibility verdicts, total, and power information. Prices are deliberately not treated as permanent: build pages need to reflect current prices rather than presenting an outdated snapshot as fact.

We are also working through the practical shopping question. The cheapest individual price can be spread across several stores, while buying everything from one store can be worth paying a little more for. The useful comparison is not just "what is the cheapest part?" but "what will this complete basket cost, and where can I buy it?"

This is a familiar software engineering pattern. The difficult part is not rendering a list of products. The difficult part is building a model that can support trustworthy decisions and an interface that communicates those decisions clearly.

What we are learning

Working on PCMR has reinforced a few lessons that apply well beyond hardware:

The happy path is not the product. The interesting work starts when someone changes a part, has a tight budget, or makes a choice that affects three other components.

Rules are part of the user experience. A compatibility rule is not merely backend logic. It becomes a message, a suggestion, and sometimes the difference between confidence and hesitation.

Progressive disclosure beats a wall of information. People need enough detail to make the next decision, not every specification at once.

Good tools make expertise transferable. The best outcome is not only that someone finishes a build. It is that they understand the important trade-offs well enough to make the next choice themselves.

Measurement has to follow the journey. We are tracking the builder as a funnel: starting a build, filling slots, opening a picker, checking a verdict, saving, sharing, and clicking through to a store. That tells us which parts of the experience help people move forward instead of leaving us to judge the interface by intuition.

Making the first step easier

PCMR is built around a simple idea: choosing your own PC should be rewarding, not a test of how many hardware compatibility tables you have memorised.

We are continuing to improve the builder around that idea—making it easier to choose parts, compare prices, save a build, and catch problems before they become expensive surprises. There is still plenty to do, especially around starter builds and better explanations, but the direction is clear: the builder should reduce uncertainty without taking the building experience away from the person using it.

If you are planning a gaming PC, try the PCMR builder and see what you can build.