Case study · Company work, anonymised
Making data quality usable by people who don't write SQL
Rule builders, execution history and drill-down dashboards for an enterprise data quality product used by large US banks, healthcare and insurance organisations.
- Users
- large US organisations in banking, healthcare and insuranceData teams at
- Owned
- four modulesFrontend for : Glossary, Data Quality, Profiling, Monitoring
- Surfaces
- Vue.jsfor the internal product, React for the public cloud SaaS interface
- Data viz
- Drill-down dashboards(line, pie, bar and stacked bar), including a D3.js Issue Management dashboard shown in a customer-facing demo
- AI
- AI-generated rulesFrontend for , including a chat-based rule-creation interface
- Foundation
- an estimated 25%A reusable React/Vue component library that cut new-feature delivery time by
The problem
In regulated industries like banking, healthcare and insurance, bad data is expensive: a wrong value can reach a report, a claim or an audit. Data quality is enforced by rules, and rules are usually SQL. The people who own data quality (stewards, analysts, business owners) often don't write SQL.
The engine was powerful. My job was letting those people create, run, understand and trust rules without reading a query.
What I built
1. Rule building for four kinds of rules Users build rules themselves, and the product supports two families:
- Suggested rules, scoped to a data domain or to a single column
- Custom rules, written as SQL or as business rules
Each kind needs a different form, preview and validation, but they have to feel like one tool. I turned the SQL rule-engine and policy-management logic into interfaces non-technical users could use, including custom SQL rule creation. 2. Interfaces for AI-generated rules The product can also generate rules with AI. I built the frontend for it:
- screens where users review AI-generated rules
- a chat-based interface where users describe a rule in plain language and get one back
The generation logic itself is backend work I didn't build. My part was making AI output something a data steward can read, question and decide to accept.
3. Rule execution history A view of what ran, when, and what it found, so people could trust a rule's result and see it change over time.
4. Boundary-rule and caching configuration Flows for settings that are easy to get wrong and expensive when you do.
5. Dashboards with drill-down The Data Quality dashboard combines line, pie, bar and stacked bar charts. Each one drills down from the summary into the records behind it. The Issue Management dashboard (D3.js) shows issue distribution, data-quality dimensions, severity and resolution metrics; it was presented in a customer-facing product demo.
Interactive · coming next
Build a rule without SQL
"Build a rule without SQL":
- Pick a column and a check, e.g.
emailmust match a pattern, severity High. - Watch the generated SQL appear live beside it.
- Run it against a small synthetic table; failing rows are highlighted.
- Drill from a stacked bar into those rows.
Every name and dataset is invented, and nothing mirrors the real product's UI.
Two frameworks, one product
The internal product is Vue.js and the public cloud SaaS interface is React, so the same features had to exist in both. That constraint is where the reusable React/Vue component library came from. It became the product's UI foundation, cutting new-feature delivery time by an estimated 25%.
It's also the thread into case study 1. The charts moved from hand-built D3 to our own headless UI platform: one framework-free core serving both React and Vue.
What I’d do differently
Measure, don't estimate. The component library cut new-feature delivery time by an estimated 25%. That's a team estimate, and I can't prove it. Next time I'd record a baseline before building shared infrastructure (time from design hand-off to release for a few comparable features), then measure the same thing afterwards. An estimate persuades the people who were there; a measurement persuades everyone else.