← Harun Memiş

Deal Radar

Price tracking and forum deal alerts, with summaries you can trust

Deal Radar watches the prices of products I care about and the deal forum where good prices surface first. When something is worth acting on it sends one Telegram message: the product, the price, and two or three sentences on what the people in the thread actually think of it.

It is self-hosted and runs on a Raspberry Pi 5 at home. I built it because the deals that matter are short-lived: a store reprices just after midnight, a forum thread fills with replies within minutes, and the stock is gone within the hour.

What it does

• Tracks a product across several stores at once and keeps a full price history, including every individual check.
• Alerts when a price reaches the target I set, and after that only on a new low, so a product sitting under its target does not repeat itself.
• Follows a deal forum and spots threads that are taking off, by reply velocity and bursts rather than by keywords.
• When a hot thread links a product that is already tracked, checks that price immediately instead of waiting for the next cycle.
• Summarises the thread in the notification, so the decision can be made from the lock screen.

Edifier M60 desktop speakers, black, 6,668 TL on Amazon. The thread is positive: normally around 12,000 TL and shared earlier at 9,000 and 7,000, and several members bought it. One member reports the price went back up to about 7,800 TL shortly after; Amazon is the seller, so returns are not expected to be a problem.

An example summary, translated from Turkish. The notifications themselves are in Turkish.

How it works

-- 01

Scraping that escalates only when it has to

Every store is scraped with plain HTTP and Cheerio first. Playwright is started only for stores that need JavaScript, or when the cheap pass cannot confirm a promotion. Per-store behaviour lives in one config file: structured-data parsers where the store publishes them, CSS selectors where it does not.

-- 02

A forum signal built on velocity

Each scan records how fast a thread is collecting replies. A thread notifies when its velocity or a sudden burst crosses a threshold. For brand-new threads that are unusually fast, a small LLM check reads the first comments and can veto the alert when the community is openly dismissing the deal, which is how this forum usually says “too expensive”.

-- 03

Summaries written only when they are needed

A summary is generated at the moment a notification fires, never per scan, and is cached on the deal. That keeps the volume at about a dozen summaries a day and the model bill at a couple of dollars a month. The model sees the opening post and the latest comments, and has to report the community’s verdict, not its own.

-- 04

Built to be left alone

A TypeScript monorepo: a worker with a scheduler, a retrying job queue and a circuit breaker for the forum, a Next.js dashboard, and PostgreSQL through Drizzle. Everything ships as Docker containers, deploys go through a GitHub Actions runner on the Pi, and a deploy is refused for any commit that has not passed CI.

Measuring the summaries

A summary that leaves out a detail is a small failure. A summary that says the community likes a deal when it does not is a notification that costs money. So the model behind the summaries is chosen by a benchmark, not by reputation.

• 30 real forum threads, frozen and labelled by hand: the product, the verdicts that count as right, the points a good summary must carry, and the misreadings each thread invites.
• Every model writes each summary three times with the production prompt.
• The summaries are shuffled into a blind sheet and graded one by one against the source.
• The headline number is the share of misleading summaries: a wrong verdict, a wrong product, a trap fallen into, or a claim the thread does not support.

90 summaries per model. The gap between the production model and Opus 5.5 is inside the benchmark’s noise; the gaps to Sonnet and Haiku are not.

Where Claude fits

• Development. The project is built and maintained with Claude Code, from the scraper engine to the deploy pipeline.
• Evaluation. Claude grades the blind benchmark sheet. An API judge was tried first and checked against a hand grading of 450 summaries: it ranked the models the same way but flagged about twice as many summaries as misleading, so the grading moved to Claude working through the sheet in a session.
• The summarizer, not yet. Production currently runs an OpenAI model through OpenRouter, because that is what the benchmark picked. Opus 5.5 matches it on quality and carries more of the must-have points, but as measured it is about five times the cost and three times the latency, and it overruns the output budget the worker allows.

The open question is whether Opus keeps that quality inside the production latency and token budget. That is the next benchmark run, and it is the one that decides whether the summarizer moves to Claude.