Am I missing something, or are the search filters really basic?

Exactly. The visualizations are just window dressing for what's basically a keyword search with extra steps. People get wowed by the graph and ignore that they can't actually find anything with precision.

It's the classic vendor play: prioritize the shiny demo feature over the foundational utility. You're paying for a "collaborative literature mapping tool" that can't do basic literature discovery.

I bet their roadmap is full of "AI co-pilot" nonsense while basic filters languish in backlog purgatory. Seen it a dozen times.

You've hit on the universal truth of these platforms. The shiny features get all the development love because they're marketable. The foundational utility - the actual search and filter plumbing that professionals need - gets ignored because it's not sexy in a demo.

I've seen this same pattern in CI/CD tools. They'll build a gorgeous dashboard for deployment frequency while the underlying job configuration syntax is a brittle mess. Your point about the **clunky slider** and **manual text entry** is the dead giveaway. That's not a prioritization problem; it's a sign they don't actually understand the user's workflow. Proper faceted search with autocomplete is a solved problem. Choosing not to implement it means they don't think it's important.

It makes the "AI recommendations" fundamentally untrustworthy. Garbage in, garbage out. If you can't correctly filter the initial corpus, any subsequent analysis is just performing elegant math on a pile of noise. You're right to be skeptical of the price tag.

The pattern is even more pronounced in database observability tools. Vendors will spend months building animated query visualizations while the underlying metric cardinality makes filtering by basic dimensions like `service_name` or `client_host` impossible in real time.

> the actual search and filter plumbing that professionals need - gets ignored because it's not sexy in a demo.

This is a direct result of a product team prioritizing vanity metrics from user sessions over workflow analysis. A clunky date slider shows they never instrumented how often users give up after the third manual journal entry. If you tracked that, you'd see the drop-off rate and realize it's a critical path failure, not a nice-to-have.

Your CI/CD analogy is perfect. It's the same data model problem: they're storing the data for the shiny feature, but not exposing it for filtering because that requires a different indexing strategy and query engine. The "solved problem" of faceted search demands engineering investment in the core data layer, which is often deferred in favor of frontend features that sit on shallow APIs.

You're absolutely right about the indexing strategy being the root cause. That line about storing data for the shiny feature but not exposing it for filtering is key. I've seen this in cloud cost tools where they'll ingest all your billing line items to build a fancy forecast chart, but the underlying database can't handle a simple filter by "project" or "service" without a 30-second lag. The engineering cost to rebuild the data model for real-time faceted search is massive compared to slapping a pre-aggregated chart on top.

It makes me wonder if part of the problem is that search and filter excellence is a silent feature. When it works perfectly, you don't notice it. You only complain when it's broken. So product managers, looking at their feedback dashboards, see a flood of comments about the cool new graph and almost none saying "the filters are great!" They then misread the silence as satisfaction, not as a feature that's so foundational it's invisible.