Nyuz

What it is

Nyuz collects articles from feeds, works out which ones are covering the same real-world event, matches those events against what you actually follow, and sends you a briefing. You stop searching for information and start receiving it.

It is in development and not accepting customers.

The part that mattered to get right

The obvious design is per-user. Collect feeds, filter them for each subscriber, send each subscriber their own copy.

That does not survive contact with a few thousand people. The same story gets fetched, parsed, summarised and stored again for every single reader who might want it, and the expensive work is duplicated N times for one result.

Nyuz is built around shared events instead. Articles are collected once and consolidated into an event — one real thing that happened, however many outlets covered it. Readers are then matched against those shared events. The expensive work happens once and is reused by everyone who cares about that event.

per-user design                    Nyuz

feed ──▶ parse ──▶ filter ──▶ ✉     feed ──▶ parse ──┐
feed ──▶ parse ──▶ filter ──▶ ✉     feed ──▶ parse ──┼─▶ EVENT ──▶ match ──▶ ✉
feed ──▶ parse ──▶ filter ──▶ ✉     feed ──▶ parse ──┘     (once)   (per reader)
   × N readers                         one pipeline

The clustering is the expensive part, and it is the part that benefits most from being done exactly once.

Code-first, on purpose

The instinct with an AI product is to reach for a model wherever the logic gets awkward. Nyuz deliberately does not, for most of the pipeline.

Clustering, topic handling, matching, exclusions, ranking and filtering are implemented as explicit application and database logic. Not because models cannot do these things, but because:

• the same input should always produce the same output
• you can explain to a reader why a story was or was not in their briefing
• the cost per reader is a query, not an inference
• when it breaks, it breaks in a way you can read

Models are used where they earn their place — controlled long-form generation of the briefing text itself — behind a provider abstraction so the underlying model can change without rewriting the system.

What is built

• Ingestion — RSS and Atom, with URL canonicalisation so the same article arriving from three feeds is stored once.
• Clustering — groups multiple articles that cover one event.
• Matching — interests, explicit exclusions, source preferences and ranking signals.
• Delivery — email, browser push and Telegram, on a schedule, with quiet-day suppression so nobody gets an empty briefing.

The unglamorous part

The pipeline is measured. Source failure rates, enrichment and backoff behaviour, how many events match how many readers, cost ceilings, and what the recovery path is when any of it goes wrong.

Background jobs that fail silently are how a system becomes unexplainable six months later. Nyuz keeps the accounting close to the thing it is accounting for.

Stack

TypeScript, React 19, TanStack Start and Router, Vite and Nitro, Cloudflare Workers with scheduled processing, Postgres through Supabase, Supabase Auth, Tailwind and Radix. Tested with Vitest and Playwright.

Small team of one, which is why the boring parts are very carefully instrumented.