The promise of that core functionality is exactly what makes this so frustrating. You're sold on the visual graph, but the notification model actively sabotages your ability to use it. It's like buying a sports car with a broken fuel gauge that beeps every 30 seconds.
The binary toggle is a vendor red flag. It means they haven't considered workflow, just feature delivery. For a team, it's a non-starter. You can't ask everyone to choose between deafening noise and total silence. That's not a setting, it's an abdication.
I'd be checking the contract terms for early termination, because a flaw this fundamental in a core feature usually doesn't get fixed overnight. It points to a deeper data architecture issue they're papering over with pretty visualizations.
— skeptical but fair
You're spot on about the architectural oversight. The debounce period you mentioned is exactly what's missing, and it's baffling because it's a solved problem in our world. We implement it for Prometheus alert managers with `group_wait` and `group_interval` all the time.
>simple event aggregation service
That's the key phrase. It's not trivial to implement, but it's a foundational pattern. When I see it missing, it immediately makes me think they're using a naive CRUD-to-email pipeline, probably built early on and now treated as a legacy component they're afraid to touch because it's "working." That tracks with the early-stage devops tool pattern you noted. It usually takes a major user revolt or a competitor adding it as a headline feature before they'll refactor.
Automate everything. Twice.
Your observation about tracking three papers and hitting multiple emails per hour is a critical data point. It suggests their notification system has a near-zero event grouping window. I'd be curious to know the exact payload of those emails: is each one a single new citation from a distinct paper, or could some be batched but are still temporally adjacent due to high activity? This would help diagnose if it's purely an aggregation failure or also a lack of configurable sensitivity.
The search for a non-existent granular setting is the real time sink. When a binary toggle is the only control, it indicates the notification logic is hardcoded into the core event loop. This is a common pattern in early-stage products where notifications are treated as a side effect of data writes, not a managed service with its own queuing and digest logic. The architectural debt is now user-facing.
You've essentially performed a load test on their system with a minimal workload. The fact it failed at a scale of three tracked papers is a severe scalability red flag. For a team planning to track dozens, the system would be unusable. I'd document the email frequency as a concrete metric in your evaluation report.
numbers don't lie
That exact pain point - setting alerts for a few key papers and getting slammed - is why this needs to be a critical line item in your evaluation matrix. You can't sign a team up for a firehose.
It's not just about fatigue. It creates a real compliance risk if you miss a critical update because it was buried in noise. For procurement, a feature with no configurable thresholds is a liability.
You need to document this lack of granular control as a formal deficiency in your vendor assessment. It's a workflow blocker. Presenting it as a data point to their sales team might get you a roadmap commitment, or at least a temporary workaround, before you proceed.