The Client

Voices That Count is a company built around data. Their dashboard is the nerve center of how they read and act on that data, and they needed a way to talk to it directly, in plain language, without leaving the page.

The Brief

The ask was a Chrome extension that lives inside their dashboard and lets users ask questions about their data in plain language. On the surface it sounds straightforward. Under the hood it is anything but.

The Challenge

The core problem was scale. The dashboard holds a lot of data, and sending all of it to an AI with every query would be slow, expensive, and wasteful. Getting this right meant being clever about what actually gets sent and when.

How It Works

The first thing the extension does is capture the CSV data directly from the network tab, something I figured out independently by digging into how the dashboard loads its data. That CSV is then parsed using Papaparse to extract the headers and all possible values, which form the basis of what the AI can filter on.

(For this I had to switch the lists that included a lot of real numbers into "REAL" to let the AI know that on these we will do numeric comparisons, and those that included a '1' are a true or false)

From there, the extension runs a two-stage AI pipeline. The first call takes the user's natural language query alongside the headers and possible values, and figures out exactly which filters apply.

Those filters are applied to the original CSV. The second call then takes that filtered, minimal dataset and produces a meaningful, readable response back to the user.

This means the system works on any dashboard structure without any manual configuration. The filtering model figures out the shape of the data on its own. No hard coding, no assumptions about layout.

A Railway-hosted Express backend handles all the AI calls, keeping the extension itself light and the logic centralized, maintainable, and secure.

The Admin Layer

On top of the backend I also built an admin dashboard that gives the Voices That Count team visibility into how the application is actually being used. Which client sites are consuming the most tokens, what the running costs look like, and the ability to create and manage accounts for their clients. The application is closed source, so keeping that operational layer in-house was important.

The Detail That Matters

A lot of the real work here is invisible. Token count optimization sits at the heart of the whole architecture, bringing queries on datasets of over 4000 rows from a theoretical 2 million token ceiling down to an average of under 8000.

The user types a question and gets an answer. Everything else, the network interception, the filtering, the backend, the cost optimization, happens out of sight.

What Is Next

A second version of the extension is in development that will capture information directly from the webpage itself, not just the underlying CSV. This opens the door to manual filtering scenarios and lets users ask questions about whatever is currently visible on the page, not just the raw data behind it.

What It Represents

This was a project where most of the interesting decisions happened before a single line of code was written. The architecture is the product. Getting the pipeline right, finding the CSV in the network tab, keeping token counts low without sacrificing quality, building the admin layer on top of it all. These were not obvious choices. They were the right ones.