No-code filter and parameter layer for embedded analytics

A product team ships an embedded analytics view to their customers using QuickSight or Quick BI. Within a week, customers are complaining that the filters don't behave the way they expect, global parameters require the kind of configuration that only someone who has read three documentation pages can do correctly, and the UI doesn't match the parent product's design language. The product team goes back to the analytics vendor's settings, gets lost, and either hacks together a workaround or deprioritizes the feedback.

This gap persists because the analytics vendors are building general-purpose tools optimized for internal BI teams — people who will spend time learning the product. When those same tools get embedded into a SaaS product, the end users are customers who expect the UX of the parent product, not the UX of an analytics platform. The vendor has no incentive to fix this: their buyer is the product team, not the end customer, and the product team already paid.

The specific complaints — 'global filters require workarounds,' 'the UI is very unintuitive,' 'integration is complex and has many unwanted features that distract attention' — describe exactly what happens when a general-purpose tool gets embedded in a product-specific context. The unwanted features aren't unwanted to a BI analyst; they're unwanted to a customer who just wants to filter their own data.

A product team rebuilding this from scratch would spend weeks on something that should be configuration. The need recurs every time they add a new report type, expand to a new customer segment, or rebrand — each event requires re-touching the filter and interaction layer.

What to build

Build a configuration layer that sits between a QuickSight or Quick BI embed and the end-user browser, letting product teams define which filters appear, how they're labeled, what parameters are exposed, and what the component looks like — via a visual editor, with no changes needed to the underlying dataset or report.

Where to start

Win first with SaaS companies that have already shipped an embed and have active customer complaints about the filter UX — they have pain they can articulate and a working embed you can plug into without starting from scratch.

The hard part

The hardest early problem is that QuickSight's embedded SDK has specific constraints around session-based authentication and URL signing, which means the configuration layer has to sit in a place that may require the customer to change how they handle auth — a friction point that can kill a sale before the demo ends.

How it makes money

Monthly fee per embedded application (not per end user), which scales naturally as customers ship analytics to more of their own customers and add report types.