Build alerts on a data feed without teaching people to ignore them

You have access to a feed — market data, prices, some live stream of numbers — and an obvious idea sitting on top of it: tell people when something crosses a line. Alert me when this drops below that. It demos in an afternoon. Poll the feed, compare the value, send an email. The thought arrives on cue: people would pay for this.

They might. But the comparison you just wrote is the easy twenty percent, and the part that decides whether anyone keeps the alert switched on is the part the demo never shows.

The reframe: the product is the judgment, not the check

An alerting service lives or dies on a single number you don't see in a demo: the rate at which users mute it. The comparison — is the value past the threshold — is trivial and identical for everyone. What's hard is deciding whether a given crossing is worth telling someone about. That's a judgment problem wearing a technical costume. Get it wrong and the product fails in the cruelest way: not with an error, but with a user who quietly stops reading the alerts and then cancels.

The capability chain

End to end, here's what actually has to happen:

Poll the feed → evaluate the rule against the new value → decide whether this is worth sending → deliver it → record that you did. Five steps. Exactly one of them is the feed. The other four are scheduling, judgment, delivery, and memory — and the third one, the judgment, is where the whole product lives.

What it rides on

Named as the modules a real version needs:

• A background job — a scheduled runner that polls and evaluates on a cadence, the same kind of batch work that already runs under CompanyGraph.
• Delivery with a history — email or SMS that arrives reliably and keeps a record of what was sent, so "did my alert fire?" has an answer.
• Billing — it's a subscription product; the alert is the feature, the subscription is the business.
• A log and an admin — so an operator can see why an alert fired, or why one didn't, without guessing.

All of that already exists in a foundation. The one genuinely new capability is the feed, and feeds are well-trodden ground. So this is a week of wiring rather than a quarter — if the boring parts are already there.

What you own, and what you don't

The feed is rented. You don't own market data and shouldn't try to. What's yours: the rules each user set, the full delivery history, and — the load-bearing one — the state that prevents noise.

That state is larger than it first looks. For every watch a user has set, you are tracking whether you've already told them about this crossing, when you last did, whether the value has genuinely crossed and stayed or is only jittering back and forth across the line, and whether this user has quietly turned the volume down on a particular kind of alert. None of that lives in the feed — the feed knows the number, not your user's relationship to it. It is the part a provider structurally cannot hand you, because it is about your users rather than their data, and it is exactly the part that decides whether someone keeps the service or mutes it.

The hard part

Alert fatigue, and it's the real one. A noisy alerter gets muted, and a muted alerter gets cancelled. The failure is rarely a missed alert; it's the ten that didn't matter, which trained the user to stop looking, so the eleventh — the one that did matter — arrived in a channel they'd already abandoned. The fixes are unglamorous and they're the product: hysteresis, so an alert doesn't re-fire until the value has truly reset rather than hovering on the line; severity, so not everything shouts; digests, so low-urgency changes arrive as a summary instead of a stream. Underneath all of it sits the ordinary operational cost: feed pricing and rate limits scale with how many users watch how many things.

Why this one is grounded

The restraint this product needs — deciding when a change is worth a notification, not just a number that moved — is a problem Smallbox has already had to solve in production. CompanyGraph is a market-data product spanning roughly a hundred thousand stocks, and its core discipline is exactly this one: a measurement is placed on a 0–100 scale, and only crossing a deliberate threshold — 70 — counts as real. The line is drawn on purpose, so that "this is true" means something and isn't re-asserted every time a number twitches. That is the same judgment an alert needs, made before any notification is sent — fire on a meaningful change, not on motion. It isn't borrowed from theory; it runs at scale on CompanyGraph.

The verdict

A real SaaS, and an on-brand one. But the moat is the firing judgment, not the feed integration. Anyone can compare a number to a line in an afternoon — that's exactly why it can't be the differentiator. The product is the restraint that keeps the alert wanted: knowing what's worth a notification, and having the memory to not say it twice. Build that, and the feed is just a part you plug in.

Which is also why it's cheap to find out about, if the boring parts already exist. The honest question was never "can I detect a threshold crossing" — you can, today. It's "can I tune the firing judgment to a real audience before the feed bill and the mute rate decide it for me." When the scheduling, delivery, billing, and logging are already in place, only the feed and the firing judgment are new — so a pointed version can reach real users fast, not because the work is trivial, but because nearly all of it is already built. Your attention goes to the one part that was always going to be hard.

---

This rides on the foundation — the scheduled jobs, billing, delivery, and logging that turn a feed comparison into something a stranger pays for monthly. If you have a pointed version of an idea like this, that's exactly what one workflow is meant to prove.