A server is not a big laptop: why our value table now derives its own tiers

The value table answers one question per cell: what is the cheapest machine I can buy with at least this much memory and at least this much storage? It is the whole-system analogue of a price-per-terabyte storage table, and it is genuinely useful — as long as the tiers make sense for the machines being ranked.

Ours did not, and the reason is worth writing down because it is a mistake that is easy to make and hard to see.

One ladder for every category

The original table used a single memory ladder — 8, 16, 32, 64 GB — and a single storage ladder, for every category. Those are reasonable rungs for laptops, desktops and mini PCs, which is exactly why the problem hid: on the categories anyone looked at, the table worked fine.

On the categories nobody looked at, it fell apart in two opposite directions.

Servers and workstations blew through the top of the ladder. When effectively every machine in a category has at least 64 GB of memory, the "8 GB or more" row, the "16 GB or more" row, the "32 GB or more" row and the "64 GB or more" row all resolve to the same machine — the cheapest one in the category. Four rows, one answer, repeated. The table rendered, the cells were populated, nothing looked broken, and the entire grid conveyed a single number.

Single-board computers fell off the bottom. Most never reach 8 GB, so the lowest row of the grid was already above the whole category and almost every cell was a dash. A page of dashes reads as missing data. It was actually a mis-scaled axis.

Deriving the rungs from the machines

The fix is to stop hardcoding the ladder and read it from each category's own distribution. A rung is now a candidate only if it passes two tests:

• Enough machines meet it. A rung whose row would be built on one or two machines is noise; the winner is whatever single listing happens to be cheapest, and it will thrash from week to week.
• Some machine actually sits in that band — at or above the rung, but below the next one up. This is the test that kills the duplicate-row problem directly. If no machine lives between 8 GB and 16 GB, then the "8 GB or more" row cannot differ from the "16 GB or more" row, and publishing both is publishing the same row twice.

From the surviving candidates we pick four, positioned at percentiles of the real distribution rather than at round numbers, so the rows land where the machines actually are. Any shortfall is filled from the top down, because an aspirational ceiling — the cheapest machine with a very large configuration — is more interesting than a fourth entry-level row.

The rungs themselves still come from a fixed ladder of powers of two spanning the whole catalog, from a single-board computer's 1 GB to a server's 2 TB. Snapping to that ladder keeps the published tiers comparable across categories and stable over time; only the selection is dynamic. A derived tier of "37 GB" would be an unreadable axis and a table nobody could cite twice.

What changed on the page

Each category's grid now separates real alternatives. Servers are ranked on the memory sizes servers ship with; single-board computers are ranked on theirs. Because the rows are now genuinely different machines, a second figure falls out of the same grid for free: the typical price step between adjacent tiers, measured across every storage column. That is the number behind "is more RAM worth it on this class of machine" — and it is category-specific, which is the whole point.

The general lesson

The failure mode here was not a crash or a wrong number. Every cell was correct. The table was internally consistent, populated, and useless — because a constant that was right for the category we designed against was silently wrong for the ones we didn't. Constants that encode an assumption about your data deserve the same suspicion as a hardcoded credential: sooner or later the data moves and the constant doesn't.

See the result on the PC Value Table, or jump to a category to see how different the ladders really are.