The Expressivity Gap
Today, when someone on your team wants to visualize data, they're stuck between two unsatisfying options.
🎛️ Point-and-Click Dashboards
- Quick to build
- No code required
- But: limited expressivity
- But: templated visualizations
- But: can't tell a story
💻 Internal Web Apps
- Fully expressive
- Custom visualizations
- But: requires engineers
- But: code reviews, deploys
- But: ongoing maintenance
Dashboarding tools like Unidash give you speed but constrain what you can build to a predefined set of charts and layouts. Internal web apps give you full creative control but require a real engineering investment—code reviews, deployment infrastructure, ongoing maintenance.
Most data work ends up in dashboards because the alternative is too expensive. But dashboards can't really tell a story. They can show metrics. They can have filters. But they can't guide someone through an insight, explain anomalies in context, or adapt to what the viewer is trying to understand.
A dashboard is a view of data. A data app is an experience with data. The gap between them has historically been too expensive to cross for most use cases.
What Changes with AI
Here's what's different now: you can describe what you want in plain English, and a coding AI will build it for you. Not a template. Not a constrained widget. Actual code that does exactly what you described.
This means the trade-off chart from before gets a new entry point:
AI-built interfaces sit in a remarkable sweet spot: nearly the expressivity of a custom web app, at close to the effort level of a dashboard. You describe what you want, iterate through conversation, and get working code.
If you can describe it to a coding AI, you don't need the constraints of a low-code tool.
What does "more expressive" actually mean?
A dashboard shows you charts. A data app can:
- Tell a narrative: guide the viewer through insights in a specific order
- Animate understanding: show how data transforms through a pipeline
- Respond to exploration: let viewers ask "why" and get contextual explanations
- Combine modalities: mix text, code, visualizations, and interactive elements
- Embed domain knowledge: explain what this means, not just what the numbers are
This is what I mean by "storytelling." Not decoration. Not prettier charts. The ability to explain data rather than just display it.
Three Barriers (and How We're Removing Them)
If AI-built data apps are so great, why isn't everyone building them already? There are three practical barriers:
Our vision is to collapse these barriers. Imagine a world where:
- You open a tool, describe what you want to see, and it builds it
- You hit "publish" and it's live at a URL your team can access
- You reference a table by name and it's automatically connected to the warehouse
We're not there yet, but we're building toward it. In the meantime, tools like Claude Code let us explore what's possible.
The gap between "I wish I could see X" and "here's an interactive visualization of X" is shrinking.
What This Looks Like
Here are a few examples of data apps built with AI that go beyond what a dashboard can do:
Spark Shuffle Visualizer
An animated walkthrough of how data moves during a Spark shuffle, showing mappers, reducers, and the N×M connection problem.
Interactive AnimationZ-Order Clustering Explainer
Toggle between clustering strategies and watch how data locality changes. Shows why Z-order works for multi-column filters.
Interactive ComparisonScaling Laws Primer
Drag a slider to increase compute and watch capabilities emerge. An interactive explanation of why AI keeps surprising us.
Educational NarrativeEach of these would be impossible in a traditional dashboarding tool. They're not showing metrics—they're explaining concepts. That's the difference.
These examples were built using Claude Code, an AI coding assistant. The workflow is conversational: describe what you want, see a result, iterate. For more on the workflow, see the Working with Claude Code primer.
Building a Data App: A Walkthrough
Let's make this concrete. Say you want to understand coffee consumption patterns across the team—when people drink coffee, how much, and whether there are patterns worth optimizing around.
In a dashboard tool, you'd get a bar chart and maybe a time series. Here's what you could build instead:
How you'd build this
Start with a wireframe
You've sketched out what you want in Figma or on paper. Upload it and describe the data connections:
# Your prompt to Claude Code:
"Here is a wireframe from Figma. I want you to build this as a web app. Connect Metric M78432 (daily coffee consumption) to the box labeled 'Total Cups This Week'—aggregate it by summing the last 7 days. For the 'Peak Hour' card, query the same metric but group by hour and return the max."
Reference warehouse tables directly
Point to specific tables and dimensions in the data warehouse:
"For the hourly distribution chart, use the `coffee_events` table in the `office_analytics` schema. Group by `event_hour` and count distinct `event_id`. Filter to `event_type = 'dispense'` only."
Add slices and dimensions
Request specific breakdowns using the warehouse's dimension tables:
"Add a dropdown to filter by building. Join against `dim_office_locations` on `location_id` and use the `building_name` field for the labels. Default to 'All Buildings'."
Iterate on the insights
Push beyond raw metrics to contextual analysis:
"The insight card should correlate coffee spikes with the `calendar_events` table. If consumption on a given hour is >2 standard deviations above the mean, check if there's a meeting with >20 attendees in the prior 30 minutes and surface that in the insight text."
Share it
Once you're happy, the code can be deployed as a standalone web app or shared as an artifact. Here's the finished result →
The Direction
The old dichotomy—low-effort/low-expressivity dashboards versus high-effort/high-expressivity apps—is becoming less rigid.
What's emerging is something more like data conversations: describe what you want to understand, an AI builds an interface to explore it, iterate until the story is clear.
Our role is to make this accessible—to reduce the friction of setup, deployment, and data access.
Data apps as easy to create as documents, but as capable as custom software.