How We Built DAGsight: No-Code Causal Discovery for Analysts

Every analyst has lived this moment: a dashboard lights up, two lines move together, and someone in the room declares that one caused the other. Sometimes they're right. Often they're not — and the company spends the next quarter optimizing a number that was never in the driver's seat.

That gap between correlation and causation is the problem we set out to close when we built DAGsight — a hosted, no-code causal discovery and inference tool. The pitch is deliberately blunt: upload a CSV, get a causal graph. This is the story of why we built it and the decisions that shaped it. It's also a look at how we at OxelLab turn a hard, research-grade problem into something an analyst can use before their coffee gets cold.

The Problem: Correlation Is Cheap, Causation Is Expensive

Modern analytics stacks are extraordinarily good at surfacing correlations. Pivot tables, BI dashboards, and notebooks will happily show you a thousand variables that move with your revenue. What none of them tell you is which of those variables you could actually change to move the needle — and which are just along for the ride.

The rigorous answer to that question is causal discovery: algorithms that learn a causal graph — a DAG, or directed acyclic graph — directly from your data, mapping out which variables influence which. The catch is that this lives in academia and in Python libraries that assume you know what a conditional independence test is. For most analysts, it may as well be locked behind glass.

So the real challenge was never the math. It was access. How do you take a technique that normally requires a statistics background and a code editor, and hand it to someone who lives in spreadsheets?

The Idea: CSV In, Causal Graph Out

We anchored the entire product on a single promise — CSV in, causal graph out — and refused to add a step that broke it. No SQL to write, no model to configure, no notebook to babysit. You upload a file of the data you already have, DAGsight learns the graph, and you see which variables the data points to as the real drivers of your outcome — and what you should test next.

Stripping the workflow down to one action sounds simple, but it forced a lot of complexity inward, into the engine, instead of outward, onto the user. Detecting column types, handling messy real-world CSVs, choosing sensible defaults for the discovery algorithm, and rendering a graph that a non-statistician can read — all of that had to happen automatically and quietly. The hard work of a good product is usually the work the user never sees.

The Decision That Defined the Product: Be Honest About Uncertainty

Here's the design choice we're most proud of, and the one that took the most discipline. Causal discovery from observational data has a fundamental limit: sometimes the data simply cannot tell you the direction of a relationship between two variables. Both directions fit equally well.

The tempting thing — the thing that demos better — is to pick a direction anyway and draw a confident arrow. We chose the opposite. When the direction can't be defended, DAGsight leaves that edge undirected. It tells you, plainly, "these two are related, but your data can't say which way."

That honesty turns out to be a feature, not a limitation. An undirected edge is a map marker that says run an experiment here. Instead of handing an analyst false confidence, the graph hands them a short, prioritized list of the exact questions an A/B test could answer. We'd rather ship a tool that admits what it doesn't know than one that looks smarter than it is.

The same humility applies to the graph as a whole. Causal discovery reads structure from the columns you give it, so its conclusions are only as trustworthy as the data behind them — a variable you didn't measure, or an assumption that doesn't hold for your dataset, can both bend the picture. DAGsight surfaces that uncertainty rather than papering over it, and it's exactly why the edges it is willing to draw are worth taking seriously. The graph is a sharp starting hypothesis to test, not a verdict.

The Engineering Behind the Simplicity

Delivering causal discovery as a service means the heavy computation runs on our infrastructure, not in the user's browser — which keeps the experience fast and consistent regardless of the size of the upload or the device on the other end.

Performance on the front end matters just as much. A hosted analytical tool lives or dies on how quickly it feels usable, so the interface is built to render early and keep the heavyweight visualization code off the critical path — the page is interactive well before any of the machinery for a run is needed. These are the same performance principles we apply to client work — we wrote about the broader approach in our guide on improving website loading speed, and the discipline of choosing the right architecture up front in how to pick a tech stack without overthinking it.

Building a hosted analytical product from the ground up — auth, billing, a compute-heavy backend, and a polished UI — is exactly the kind of full-stack work we walked through in building a SaaS platform from scratch. DAGsight is that playbook applied to our own product.

From Graph to Action

A causal graph is interesting; a decision is valuable. DAGsight is built to close that loop. Once you can see which variables sit upstream of your metric, two things become obvious that a correlation dashboard never makes clear:

• What to change: the variables the data identifies as upstream of the outcome, separated from the ones that just move alongside it.
• What to test next: the undirected edges and the highest-leverage nodes, which become your shortlist of A/B tests instead of a guessing game.
• What to ignore: the correlations that look compelling but have no causal path to your goal — the ones quietly wasting roadmap time.

That's the shift we wanted to give analysts: from "these things are related" to "here's where to act, and here's how to confirm it."

Shipping It: A Free Tier, Then Scale

We wanted the barrier to the first causal graph to be effectively zero, so DAGsight is free to start. The pricing mirrors the philosophy of the product — let people prove the value on their own data before they ever reach for a card:

• Free — 10 discovery runs, no credit card.
• Pro — $49/month — 100 discovery runs per month.
• Team — $199/month — 500 runs per month, 3 seats.

What This Project Taught Us

DAGsight reinforced something we carry into every build, whether it's our own product or a client's: the difficulty of a great tool is almost never the algorithm — it's the translation. Taking something genuinely complex and making it feel obvious is the whole job. And sometimes the most valuable thing software can do is tell the truth about what it doesn't know.

It's also a working example of how we think about AI and data products at OxelLab: not as a demo that impresses for thirty seconds, but as a tool someone trusts on a Tuesday afternoon to make a real decision.

Frequently Asked Questions

What is causal discovery?

It's the process of learning a causal graph (a DAG) from your data — figuring out which variables actually influence others, rather than which ones merely move together. It answers "what drives this metric?" instead of "what correlates with it?"

Do I need to know how to code to use DAGsight?

No. DAGsight is a no-code, hosted web app — you upload a CSV and get a causal graph back. There's a free plan with 10 runs and no credit card required, so you can try it on your own data first.

Why does DAGsight sometimes leave edges undirected?

Because honesty beats false confidence. When the data can't defend a direction between two variables, DAGsight leaves that edge undirected — which tells you exactly where an experiment is needed to settle the question.

The Bottom Line

DAGsight is OxelLab's answer to a question every data team eventually asks: not "what correlates with our metric," but "what actually causes it to move?" If you want to see it in action, you can try DAGsight for free — or if you have a product idea that needs this kind of engineering, start a conversation with us. We love building tools that turn hard problems into a single, honest click.