Case study
The AI-Native Semantic Layer
How a one-person data team replaced a 24-hour analyst queue with governed answers in minutes — and earned back the trust it lost in month one.
- 24 hours → under 5 minutes from question to insight
- ~700 queries a week from ~80 people
- Adopted by Sales, CS, RevOps, Ops, and Product
- ~2 analyst hires avoided per business function
Context
I joined Supio as the founding data hire: no analytics function, no data models, no shared definitions. Every operational question — pipeline, renewals, feature adoption — became a request to me, and the queue ran about 24 hours deep.
The deeper problem was pace. Supio shipped new features weekly, and every launch raised questions the existing dashboards had never heard of.
The problem, framed properly
Dashboards assume you know the questions in advance. Ours changed weekly: each launch needed new metrics, and the hand-built dashboard layer accumulated debt faster than one person could retire it.
So the real product problem wasn't “answers are slow.” It was that the system for producing answers couldn't keep pace with the product it was measuring. Fixing the queue meant changing the system, not staffing it.
The options I weighed
Grow an analyst / BI team
PassedLinear cost that doesn't fix the structure: every weekly launch still adds dashboard debt faster than analysts can retire it. Scaling headcount to chase a treadmill.
Buy a text-to-SQL vendor
PassedI evaluated the “chat with your data” category and rejected it. Adopting a vendor meant reworking our entire metric layer around its abstractions — a bet-the-stack commitment to an immature category, at a cost a one-person data team couldn't justify.
Build thin on open source
Chosendbt, DuckDB, YAML metric specs, and an MCP server: every piece portable, nothing proprietary to unwind. If the category standardizes in two years, we swap the serving layer and keep the marts.
Why build won
The deciding argument was market maturity, not technology. In an immature tool category, committing your metric layer to one vendor's abstractions is the most expensive kind of lock-in — you pay for it precisely when you try to leave. Building thin on open standards kept the definitions ours and made the AI serving layer swappable.
The second argument was governance. An AI that answers from certified metric definitions is an analytics product; an AI that guesses over raw tables is a demo. No vendor in the category treated the semantic layer as the load-bearing part. I did.
What I shipped
dbt models the raw sources into business-ready marts. A YAML semantic layer defines every governed metric on top. DuckDB executes the queries, and an MCP server exposes the whole thing to Claude — where anyone in the company can ask a question in plain English.
The layer also changed our own velocity. With definitions living in YAML, adding a metric for this week's feature launch went from an analyst project to minutes of work with AI coding tools. That's what let one person keep pace with a weekly ship cadence.
Adoption — and the month it almost died
Sales and RevOps adopted first, because they had the sharpest version of the pain: they asked the same question every week — “how is the new feature landing?” — about a different feature each time, faster than dashboards could be built. Self-serve answers to that one question were the hook; the rest of the usage followed.
Then came the month that almost killed it. Early on, all three classic failures hit: a wrong number reached a stakeholder, the layer surfaced that two teams had been using different definitions of the same metric, and Claude confidently answered a question the semantic layer didn't actually cover.
The rebuild was the real product work: coverage guardrails, so the AI refuses or flags questions outside the layer's scope instead of guessing; stakeholder-certified definitions, which turned the layer from a competitor into the arbiter; a verification loop spot-checking answers against known numbers; and owning the misses publicly rather than explaining them away.
Trust compounds. Today the layer answers ~700 queries a week from ~80 people across five business functions — sustained daily use, not a launch spike.