When $1.38 cheaper is worse: scoring features into price comparisons

Pure price ranking has a dirty secret: at the top of the board, it's often noise. In our own object storage comparison, two plans land within $1.38 of each other on a five-terabyte monthly bill of roughly $556 — a 0.2% difference that no invoice forecast on earth will predict accurately. Yet a strict "sort by cost" ranking must declare one the winner, and buyers reasonably read that as "this one is better." This article is about how we fixed that, and what it reveals about price comparison in general.

The case that forced the question

At our 5 TB storage + 5 TB EU egress scenario, AWS S3 Standard computes to $556.59/month and IBM Cloud to $555.21/month. IBM is cheaper — by 0.25%. But the two services are not equivalent products: our catalog captures ten UI-visible capability dimensions (versioning policies, object locks, lifecycle automation, and so on), and AWS S3 Standard scores 10 of 10 while IBM Cloud scores 9. So which should rank first? A site that sorts by price alone shows you IBM as #1 and you'd never learn what you were giving up for $1.38.

Band the prices, then let features argue

Our fix treats totals within roughly two dollars as a near-tie: we round every plan's computed total into $2 bands, and inside a band the plan with the richer feature score ranks first; exact cents only decide when features tie too, and the vendor slug breaks any remaining deadlock. On the S3-versus-IBM case, both totals fall in the same ~$2 band, the richer feature set wins, and S3 Standard ranks first despite being nominally more expensive. Outside the band, price rules exactly as before — nobody gets to hide a $50 difference behind a nice dashboard.

What counts as a feature?

Only what we actually captured and show in the tool's UI — versioning support, retention and lock modes, lifecycle rules, storage classes, and similar visible capabilities. Each counts one point per dimension where the vendor offers the capability; absent optional fields score zero rather than being guessed. The scoring is deliberately dumb: it doesn't weight dimensions or editorialize about which features matter. Its only job is to say, honestly and mechanically, "within this price band, this product does more of the things we can verify." The full rule lives in code (`src/lib/near-tie.ts` in our tools repo) with tests pinning both directions: richer-wins-inside-band, and cheaper-wins-outside-it.

The general lesson

• "Cheapest" is only well-defined when products are identical; the closer the prices, the more the decision is actually about features — exactly where naive sort hides the most information.
• Any comparison ranking needs an explicit tie-break policy. If a site doesn't publish one, its top-of-board ordering is partly arbitrary.
• Determinism matters as much as correctness: the same data should always produce the same board, regardless of row order.
• Feature scores must come from captured, displayable facts — not affiliate weighting or editorial preference. Ours are countable from the catalog.

You can watch the mechanism work live: our storage comparison marks near-ties and lets you see both the banded ranking and the raw totals. If you disagree with a two-dollar band, the numbers to argue with are published right there — which is the whole point.