Hardware Radar

Purpose

Recertified and enterprise storage is sold across a couple of dozen unrelated marketplaces, and the same drive appears on each of them under a different name. A model number is abbreviated one way by a manufacturer’s own store, another way by a reseller, and a third way by a listing title written to be searchable. Comparing prices means first deciding which listings are about the same object.

Hardware Radar exists to make that comparison possible for a homelab or small-business buyer. The visible product would be a deal alert; the actual work is the identity problem underneath it.

Operating model

Collection is a pipeline with named stages — fetch, classify, persist — kept separate so a change to how a source is read cannot alter what is stored. Prices arrive in more than one currency, so conversion is its own module rather than an adjustment applied wherever a number is used.

Identity resolution is the substantial part, and it is deliberately not a string comparison. A resolver works from a vocabulary and a manufacturer-part-number model, through a documented ladder of increasingly specific evidence, so a match is reached by a stated route rather than by a threshold nobody can inspect. A listing that cannot be resolved stays unresolved.

Observations are stored as time-series snapshots rather than as a current value per drive, so price history is a consequence of the storage model instead of a feature added to it.

The collector watches itself. A heartbeat records that a run happened and a dead-man check distinguishes “no new listings” from “the poller stopped” — two states that look identical in the data and mean opposite things.

Practices

Observe. The system reads marketplaces without modifying them, and it observes its own collection as well: the heartbeat and dead-man modules exist because a monitor that silently stops is worse than no monitor, since it reports calm.

Model. The identity ladder and the vocabulary are the model. They encode what makes two listings the same drive, in a form that can be argued with, rather than leaving it implicit in a matching function.

Verify. The repository runs its own gate — formatting, linting, strict type checking, tests with coverage, and a dependency audit — and its architecture decisions are recorded as ADRs, so a decision can be checked against its stated reasoning later.

Architecture

Django with server-rendered templates, PostgreSQL with TimescaleDB for the snapshot hypertable, and Scrapy for collection under an HTTP-first, structured-data-first, browser-last policy — reach for a browser only when nothing cheaper will do.

The decisions are recorded rather than remembered. The repository carries a master specification, a set of ADRs, an open- and resolved-questions log, and a research corpus behind the choices. That documentation is the part most likely to be useful to a reader who is not going to run the software.

Evidence

The repository is public under MIT. The acquisition pipeline, the currency handling, the persistence layer, the reference-data loader, and the identity resolver are all in it and can be read.

Scoring and alerting are not built. They are specified — there is an ADR for a composite deal score and research behind a low-noise alerting layer — but the code is not there, so the product this system is eventually for does not exist yet. It is a prototype, listed here for the collection and identity work that does exist, not for the deal alerts that do not.