Build vs Buy for Churn Prediction: Snowflake + dbt vs Dedicated Platforms

You have a Snowflake warehouse, a growing dbt project, and maybe Hex for notebooks and dashboards. Your churn rate is creeping up. The question on the table: should you build churn prediction models on top of the data stack you already own, or implement a dedicated platform like ChurnZero, Catalyst, Totango, or ClientSuccess?

This is the most common infrastructure question we hear from VP RevOps and data leads at Series B SaaS companies ($10M–$50M ARR). The answer isn’t universal — it depends on your data engineering capacity, the number of systems your churn signals live in, and how urgently you need results. This guide gives you a structured decision framework to make the right call for your team.

We build Eru, so we have a perspective. We’ll be straightforward about where each approach wins and where it falls short — including Eru’s limitations.

Why This Decision Matters at Series B

At Series B, three things are true simultaneously:

1. Churn becomes a board-level issue. Investors scrutinise net revenue retention. A 5% monthly logo churn rate that was tolerable at $3M ARR becomes a growth ceiling at $15M. Your board wants to see churn trending down and wants to know why customers leave.
2. Your data stack is maturing but not mature. You have Snowflake, probably Fivetran or Airbyte, a growing dbt project, and maybe Hex or Looker for dashboards. Your data engineer (if you have one) is busy building pipeline for finance, product, and marketing. Churn prediction is one more project competing for limited capacity.
3. Your churn signals are scattered. At 200+ accounts, churn signals live across Stripe (billing failures, downgrades), Salesforce or HubSpot (renewal pipeline, engagement), Intercom or Zendesk (support sentiment), and your product database (usage decline). No single system sees the full picture.

The build-vs-buy decision for churn prediction is really a question about where to allocate scarce engineering time. Build custom and you get full control but tie up your data team for months. Buy a platform and you get faster time-to-value but add another tool to manage.

Option 1: Build Custom in Snowflake + dbt + Hex

What the Custom Stack Looks Like

A typical custom churn prediction build at Series B uses this architecture:

1. ELT pipelines — Fivetran or Airbyte ingesting data from Stripe, Salesforce/HubSpot, Intercom/Zendesk, and your product database into Snowflake
2. dbt staging and transformation models — Clean, deduplicate, and standardise raw data from each source. Build churn-predictive features: rolling usage averages, payment failure rates, support ticket sentiment trends, CRM engagement frequency
3. Entity resolution in dbt — Match customer records across systems using email, domain, or custom ID mapping. This is where most builds stall — Stripe customer_id doesn’t match Salesforce Account ID doesn’t match Intercom user_id
4. Scoring model — A logistic regression, decision tree, or heuristic scoring model in dbt or Python, combining features into a churn risk score per account
5. Hex notebooks and dashboards — Visualisation, ad-hoc analysis, and alerting. Hex connects directly to Snowflake and lets your team build interactive dashboards and scheduled reports without a separate BI tool
6. Alerting — Slack or email alerts triggered by score changes, typically via a cron job, Hex scheduled notebook, or reverse ETL tool like Census or Hightouch

Where the Custom Build Wins

Advantage	Why It Matters for Series B
Full transparency	Every transformation and feature weight is visible in your dbt models. When your board asks “how do you calculate churn risk?” you can show the exact SQL. No black boxes.
No new vendor	You’re building on Snowflake, dbt, and Hex — tools your team already knows. No new procurement cycle, no new security review, no new data-processing agreement.
Custom features	You can incorporate proprietary signals specific to your product (“days since last report exported,” “API calls per active seat”) that no off-the-shelf tool includes.
Data stays in your warehouse	No data leaves Snowflake. This matters for SOC 2 audits, GDPR compliance, and the data governance policy your investors want to see.
Hex makes exploration fast	Hex notebooks let your data team prototype churn models interactively, test hypotheses against live warehouse data, and share results with stakeholders before productionising in dbt.

Where the Custom Build Falls Short

Limitation	Impact at Series B
Entity resolution is the killer	Matching Stripe customer_id to Salesforce Account ID to Intercom user_id requires non-trivial logic. Email-based matching fails with group aliases. Domain-based matching fails with multi-brand accounts. This alone takes 4–8 weeks of a data engineer’s time and requires ongoing maintenance every time a source system changes its data model.
3–6 month build time	From pipeline setup to production-quality churn scores, expect 3–6 months of your data engineer’s time. At Series B, your churn problem doesn’t wait. Every month without signals is a month of preventable churn.
Cross-system accuracy gaps	dbt models run on batch-loaded data. If Fivetran syncs Salesforce every 6 hours and Stripe every hour, your reconciliation logic operates on stale snapshots. A customer who downgrades in Stripe at 2pm won’t show up in your dbt model until the next morning’s run. Discrepancies between billing and CRM data — one of the strongest churn signals — can persist for hours or days before detection.
Ongoing maintenance burden	Schema changes in Stripe or Salesforce break dbt models. New data sources require new pipelines. Feature drift degrades model accuracy over time. Budget 20–30% of a data engineer’s ongoing time — at a $150K–$200K salary, that’s $30K–$60K/year in maintenance alone.
Hex is a visualisation layer, not a platform	Hex is excellent for exploration and dashboards but doesn’t provide entity resolution, cross-system reconciliation, or automated playbook execution. It displays what your dbt models produce — the accuracy ceiling is still set by your dbt pipeline.

Option 2: ChurnZero

What It Is

ChurnZero is a customer success platform focused on real-time workflow automation, health scoring, and in-app engagement. It’s designed for CS teams that need to automate daily workflows — playbooks, task management, and customer communication — with health scoring as a core component.

Strengths for Series B

• Strong workflow automation — Playbooks, automated tasks, and in-app engagement sequences tied to health score changes. If your primary need is automating what CSMs do every day, ChurnZero is strong here.
• ChurnScore ML prediction — Machine learning–based churn prediction that goes beyond rule-based health scoring. The model trains on your historical data to predict churn probability.
• In-app engagement — Native in-app walkthroughs, surveys, and announcements. Useful if low product adoption is a churn driver and you want to address it directly.
• Deployment speed — 2–4 weeks to initial deployment with pre-built CRM and support connectors.

Limitations for Data Teams

• Separate data model — ChurnZero maintains its own copy of customer data. When its imported view diverges from your Snowflake warehouse, you get “ChurnZero says X, our warehouse says Y” conflicts. This is the data silo problem that data leads specifically want to avoid.
• Limited warehouse integration — ChurnZero ingests data from CRMs and via its JavaScript SDK, but it’s not designed to read from your Snowflake dbt models. Your warehouse-modelled metrics (custom MRR calculations, product-specific usage aggregations) don’t flow into ChurnZero natively.
• Billing data gaps — ChurnZero gets billing data through CRM integration, not direct Stripe or Chargebee connections. Billing–CRM discrepancies — one of the strongest churn signals — are invisible because both data sources flow through the CRM as a middleman.
• ML model is less transparent — The ChurnScore uses ML for prediction but the model internals are less visible than rule-based approaches. Data teams that need to audit and explain every score component may find this limiting.

Option 3: Catalyst

What It Is

Catalyst (now part of Totango following their 2024 acquisition) is a lightweight customer success platform built for lean CS teams. It provides health scoring, revenue tracking, and CRM integration with a focus on simplicity and fast deployment.

Strengths for Series B

• Lean team friendly — Designed for CS teams without dedicated CS ops. The setup is guided and less complex than enterprise platforms like Gainsight.
• Good CRM integration — Strong Salesforce integration with bidirectional sync. Health scores and account data flow back into your CRM for rep visibility.
• Revenue tracking — Native ARR and expansion tracking alongside health scoring, useful for RevOps leaders who need both in one view.
• Fast deployment — 2–6 weeks to initial deployment, depending on data complexity.

Limitations for Data Teams

• Limited data source breadth — Catalyst connects to CRMs and has some product analytics integrations, but it’s not built for consolidating 6+ data sources. If your churn signals span billing, product, support, CRM, and warehouse data, Catalyst’s coverage is narrow.
• No warehouse-native integration — Catalyst doesn’t read from Snowflake or your dbt models. Your warehouse investment doesn’t feed into Catalyst’s health scores.
• Creates a data silo — Like ChurnZero, Catalyst maintains its own customer data model separate from your warehouse. Two sources of truth is one too many for data leads who’ve spent months centralising data.
• Acquisition uncertainty — The Totango acquisition creates typical post-merger product roadmap uncertainty. Integration depth and feature parity are still evolving.

Option 4: Totango

What It Is

Totango is a customer success platform with pre-built health scoring, journey orchestration, and configurable SuccessBLOCs (modular workflow templates). It provides a native data model for customer health and connectors for CRM, billing, and product data.

Strengths for Series B

• Pre-built health scoring — Configurable health score templates (SuccessBLOCs) that combine usage, engagement, and financial signals without custom model building. Faster to deploy than a from-scratch build.
• Journey orchestration — Automated playbooks that trigger actions (emails, tasks, escalations) based on health score changes and customer lifecycle stages.
• Product usage tracking — Native event tracking and integrations with product analytics tools. Stronger on usage data than ClientSuccess.
• Deployment speed — 2–4 weeks to initial deployment with pre-built connectors.

Limitations for Data Teams

• Separate data model — Totango maintains its own copy of customer data. When its last Salesforce sync was 4 hours ago and a renewal was processed since then, the health score is stale. Data leads report “Totango says X, Snowflake says Y” discrepancies that erode trust in both systems.
• Limited warehouse integration — Totango can ingest data from warehouses but isn’t designed to use your dbt models as the source of truth. It imports data into its own schema rather than querying yours.
• Black-box scoring elements — Health score configuration is flexible, but the underlying calculations are not as transparent or auditable as dbt models. Data teams can’t run dbt docs generate to understand score lineage.
• Another data silo — For data teams centralising in Snowflake, Totango introduces a separate system with its own metrics definitions and its own version of truth.

Option 5: ClientSuccess

What It Is

ClientSuccess is a customer success management platform focused on account health tracking, renewal management, and CS team workflows. It’s designed for CS managers who need a unified view of account health without heavy data engineering.

Strengths for Series B

• CS workflow focus — Built for the daily workflow of CS managers: account reviews, renewal tracking, task management, and customer journey mapping.
• Renewal management — Automated renewal tracking with risk assessment based on account health signals. Strong for RevOps leaders focused on renewal pipeline.
• CRM integration — Strong Salesforce and HubSpot integrations with bidirectional sync.
• Deployment speed — 2–4 weeks to initial deployment.

Limitations for Data Teams

• Minimal warehouse connectivity — ClientSuccess has limited native integration with Snowflake or other warehouses. If your churn signals live in warehouse-modelled data, ClientSuccess can’t access them.
• Narrow signal coverage — Health scores are primarily driven by CRM and support data. Product usage signals require manual import or third-party connectors. Billing reconciliation is not a core capability.
• No billing–CRM reconciliation — ClientSuccess does not reconcile Stripe data against CRM records. Billing discrepancies — one of the most common sources of inaccurate churn metrics — go undetected.
• CS-focused, not data-team-friendly — Designed for CS managers, not data leads. If you need auditable feature engineering, custom scoring models, or warehouse-first architecture, ClientSuccess doesn’t fit.

Option 6: Eru

What It Is

Eru is an AI-powered revenue intelligence platform that connects billing, CRM, support, product analytics, and data warehouses — including Snowflake — to detect churn signals across systems and reconcile revenue data. For a detailed technical walkthrough of Snowflake integration, see our Snowflake integration guide.

Strengths for Series B

• Cross-system signal correlation — Eru connects to Stripe, Salesforce, HubSpot, Intercom, Zendesk, Mixpanel, Amplitude, and Snowflake, correlating churn signals across all sources. It sees the billing discrepancy and the usage decline and the support sentiment shift simultaneously.
• AI-powered entity resolution — Automatic matching of customer identities across systems using probabilistic matching (names, emails, domains, custom fields). The same problem that takes 4–8 weeks to solve in dbt is handled automatically.
• Billing–CRM reconciliation — Continuous reconciliation of Stripe billing data against CRM records, detecting the discrepancies that distort churn metrics and revenue forecasts. This is the cross-system accuracy gap that neither CS platforms nor custom dbt builds handle well.
• Snowflake + dbt integration — Eru connects to your Snowflake warehouse via OAuth and reads from your existing dbt models. Your warehouse-modelled metrics remain the source of truth. Eru adds cross-system intelligence on top, not alongside.
• Time-to-insight — OAuth connection in minutes, first signals within days. No 3–6 month build cycle.

Limitations

• Less customisation than a pure build — If you need highly bespoke scoring models with proprietary features that only your data engineer can build, a custom dbt pipeline gives you more flexibility. Eru’s scoring is configurable but not as open-ended as writing your own SQL.
• Newer platform — Eru is a younger product than ChurnZero or Totango. The ecosystem and community are smaller.
• Not a CS workflow platform — Eru is built for churn intelligence and revenue data accuracy, not for CS task management, in-app engagement, or daily CSM workflows. If your primary need is automating CS team activities, ChurnZero or Totango may be a better fit.

Head-to-Head Comparison

Capability	Snowflake + dbt + Hex	ChurnZero	Catalyst	Totango	ClientSuccess	Eru
Cross-system churn signals	Possible (custom build)	Partial (CRM + product)	Limited (CRM-focused)	Partial (own data model)	Limited (CRM + support)	✓ (all sources)
Entity resolution	Custom (4–8 weeks)	CRM-based	CRM-based	Built-in (limited)	CRM-based	✓ (AI-powered)
Billing–CRM reconciliation	Custom build required	—	—	—	—	✓
Snowflake + dbt native	✓ (it is Snowflake)	—	—	Import only	—	✓ (reads dbt models)
Model transparency	✓ (full SQL audit trail)	Moderate (ML model)	Configurable	Configurable	Configurable	✓ (signal-level drill-down)
CS workflow automation	— (build via reverse ETL)	✓ (core strength)	Good	✓ (journey orchestration)	✓ (renewal workflows)	Playbook alerts
Time to first signal	3–6 months	2–4 weeks	2–6 weeks	2–4 weeks	2–4 weeks	Days
Ongoing maintenance	High (20–30% of DE)	Low	Low	Low	Low	Low
Creates a new data silo	—	Yes	Yes	Yes	Yes	No (reads from warehouse)

Total Cost of Ownership: A 2-Year Comparison

This is the comparison VP RevOps and CFOs need to see. Total cost of ownership includes initial build/setup, annual platform cost, ongoing engineering time, and the opportunity cost of delayed insight.

Cost Component	Snowflake + dbt + Hex	ChurnZero	Catalyst	Totango	ClientSuccess	Eru
Initial build / setup	$37K–$100K (3–6 months DE)	2–4 weeks	2–6 weeks	2–4 weeks	2–4 weeks	Days (OAuth setup)
Annual platform cost	$10K–$34K (Snowflake + Hex)	$30K–$80K	$15K–$50K	$20K–$100K+	$15K–$60K+	Contact for pricing
Ongoing engineering / year	$30K–$60K (20–30% of DE)	Minimal	Minimal	Minimal	Minimal	Minimal
2-year total (excluding setup)	$80K–$188K	$60K–$160K	$30K–$100K	$40K–$200K+	$30K–$120K+	Contact for pricing
Time to first insight	3–6 months	2–4 weeks	2–6 weeks	2–4 weeks	2–4 weeks	Days
Cross-system accuracy	Depends on build quality	Limited (CRM-mediated)	Limited (CRM-focused)	Limited by data model	Limited signal coverage	Native cross-system

The hidden cost in the custom build column is opportunity cost. If your monthly churn rate is 3% on a $15M ARR base, every month without effective churn signals represents roughly $450K in at-risk revenue. A 3–6 month build delay versus a platform that delivers signals in weeks is not just an engineering cost — it’s a revenue decision.

Data Reliability and Cross-System Metric Accuracy

This is the dimension that matters most to data leads and the one most often underestimated. Cross-system metric accuracy — the confidence that your churn metrics reflect reality across all systems — varies significantly by approach:

Snowflake + dbt + Hex

Reliability depends entirely on your implementation. If your ELT pipelines are robust, entity resolution logic is sound, and dbt tests catch quality issues, you can achieve high reliability for the signals your pipeline covers. The risks: reliability degrades over time as source schemas change and the engineer who built it moves on. Batch-loaded data means reconciliation operates on snapshots — if Fivetran syncs Stripe every hour and Salesforce every 6 hours, a billing discrepancy that happened at 2pm may not surface until the next morning’s dbt run.

ChurnZero and Catalyst

Both platforms are reliable within the data they ingest. The accuracy gap appears at the boundaries: billing data flows through CRM rather than direct Stripe integration, so billing–CRM discrepancies — the most common source of inaccurate churn metrics — are invisible. The health score is accurate for what it sees, but it doesn’t see the billing-level signals that often predict churn earliest.

Totango

Totango’s health scores are reliable within its imported data model. The reliability gap is divergence: when Totango’s last Salesforce sync was 4 hours ago and a renewal was processed since then, the health score is stale. For data leads who need a single source of truth, this creates a “which number is right?” problem between Totango and Snowflake.

ClientSuccess

Similar to ChurnZero, ClientSuccess is reliable for CRM and support signals. The reliability gap is narrower because it tracks fewer signals — but that means it’s also missing entire categories of churn indicators (billing discrepancies, product usage decline, warehouse-modelled metrics).

Eru

Eru’s reliability advantage comes from two things: real-time event monitoring (Stripe webhooks, CRM change events) rather than batch sync, and cross-system reconciliation that explicitly flags when data sources disagree. Instead of silently using stale data or missing discrepancies, Eru surfaces them as signals. A billing amount in Stripe that doesn’t match the opportunity value in Salesforce isn’t ignored — it’s flagged as revenue drift, which itself is a churn predictor.

The Data Silo Problem

For data teams that have spent months centralising data in Snowflake, the most common objection to any new tool is: “Will this create another data silo?” Here’s how each option handles it:

• Snowflake + dbt + Hex: No silo. Everything stays in the warehouse. But you pay for this with engineering time and maintenance.
• ChurnZero, Catalyst, Totango, ClientSuccess: Each maintains its own customer data model. You now have two places claiming to know a customer’s health, MRR, or churn risk. When they disagree — and they will, because batch sync introduces lag — your team wastes time investigating which number is correct.
• Eru: Reads from your warehouse and other systems but doesn’t maintain a competing copy of your data. Cross-system signals and reconciliation results are Eru’s output. Your warehouse remains the analytical foundation. Eru adds intelligence, not another database.

Decision Framework: A Step-by-Step Guide

Use this framework to match your situation to the right approach. Answer each question honestly based on your current resources, not your ideal future state.

Step 1: How many systems hold your churn signals?

• 1–2 systems → A custom build is feasible. You can model churn from product usage alone or billing alone in dbt without entity resolution complexity.
• 3–4 systems → A custom build is possible but entity resolution becomes the bottleneck. Consider the maintenance commitment carefully.
• 5+ systems → A dedicated platform is almost certainly more cost-effective. The entity resolution and cross-system correlation complexity grows exponentially with each additional source.

Step 2: Do you have a data engineer with 3–6 months of available capacity?

• Yes, with available bandwidth → Building is viable. Your data engineer can prototype in Hex, productionise in dbt, and maintain the pipeline.
• Yes, but at capacity → Building means deprioritising something else. Quantify what gets delayed and whether the trade-off is worth it.
• No dedicated data engineer → A custom build is not viable. Without engineering capacity to build and maintain, the pipeline will degrade within 6 months. Choose a platform.

Step 3: How urgent is your churn problem?

• Churn is above target and trending up → You need signals in weeks, not months. A platform (Eru for cross-system signals, ChurnZero or Totango for CS workflow automation) delivers faster.
• Churn is manageable but you want to get ahead of it → You have time for a custom build if you have the engineering capacity.
• Preparing for board presentation or fundraise → You need defensible churn metrics fast. A platform with reconciliation capability (Eru) produces board-ready numbers faster than a custom build.

Step 4: What’s your primary use case?

• CS team needs workflow automation → ChurnZero (strongest automation) or Totango (journey orchestration). Health scoring is a means to an end — the goal is automating CS actions.
• Lean CS team needs a lightweight tool → Catalyst or ClientSuccess. Simple health scoring with CRM integration, without enterprise complexity.
• Data team needs cross-system accuracy → Eru. The goal is accurate churn signals that correlate data across all sources and reconcile billing against CRM. Warehouse-native, no new data silo.
• Data team needs maximum customisation → Custom build in Snowflake + dbt + Hex. Full control over every model, feature, and calculation.

Step 5: How important is billing–CRM reconciliation?

• Critical — Stripe and Salesforce numbers already disagree, and this causes problems in board reporting and churn analysis → Eru is the only option in this comparison that provides native billing–CRM reconciliation. A custom build can replicate this but requires significant engineering. For more on detecting and resolving these discrepancies, see our guide to revenue drift between Stripe and Salesforce.
• Nice to have → Any dedicated platform will work. Factor it into the decision but don’t let it be the deciding criterion.
• Not relevant → Focus on the other four dimensions.

The Snowflake + dbt + Eru Path

For data teams that have invested in Snowflake and dbt, the question isn’t always “build or buy” — it’s “what should we build and what should we buy?”

Eru is designed for this exact scenario. Rather than replacing your Snowflake + dbt investment, Eru layers on top of it:

• Your dbt models remain the source of truth. MRR calculations, usage aggregations, cohort definitions — whatever you’ve already built in dbt stays as-is. Eru reads from those models via OAuth.
• Eru adds what’s expensive to build in dbt: cross-system entity resolution, real-time billing–CRM reconciliation, and multi-source signal correlation across your warehouse, CRM, billing, and support tools.
• No schema migration, no duplicate pipelines. Eru adapts to your existing Snowflake schema. You point it at the relevant tables and it maps the fields.

This is the pragmatic path for Series B data teams: keep Snowflake + dbt as the analytical foundation, use Hex for exploration and ad-hoc analysis, and layer Eru for cross-system churn intelligence. You get the transparency and control of your warehouse stack with the speed and accuracy of a dedicated platform.

For more on building multi-tool customer health scores that consolidate data from 6+ sources, see our health scoring guide.

The Bottom Line

Churn prediction at Series B is a cross-system data problem. The accuracy of your model depends less on the algorithm and more on how many relevant signals it can see and how accurately it can correlate them.

Building in Snowflake + dbt + Hex gives you maximum control at the cost of 3–6 months and ongoing engineering maintenance. Dedicated CS platforms (ChurnZero, Catalyst, Totango, ClientSuccess) give you faster time-to-value for CS workflow automation but create data silos and miss the billing–CRM reconciliation signals that often predict churn earliest. Eru gives you cross-system churn intelligence that reads from your existing warehouse without creating a new data silo — the fastest path to accurate signals for data teams that have already invested in Snowflake.

The right choice depends on your engineering capacity, churn urgency, and whether your primary consumer is the CS team (choose a CS platform) or the data/RevOps team (choose Eru or build custom). For most Series B companies with 4+ data sources and limited data engineering bandwidth, the math favours a dedicated platform over a custom build.

Frequently Asked Questions

Which is better for a Series B SaaS company — building churn prediction in Snowflake + dbt + Hex or using a dedicated platform like ChurnZero or Catalyst?

It depends on your data engineering capacity and the number of data sources. Building in Snowflake + dbt + Hex gives you full control but requires 3–6 months and a dedicated data engineer. ChurnZero deploys in 2–4 weeks with strong CS workflow automation. Catalyst is lightweight for lean teams. For Series B companies with 4+ data sources and limited engineering capacity, a dedicated platform typically wins on time-to-value. Eru is the best fit if you want to keep your Snowflake + dbt investment while adding cross-system churn intelligence without creating a data silo.

What are the pros and cons of building custom churn prediction in Snowflake + dbt versus Totango or ClientSuccess for data reliability and cross-system accuracy?

Building in Snowflake + dbt gives you full transparency and keeps data in your warehouse, but cross-system accuracy is limited by batch sync schedules (discrepancies can persist for hours). Totango provides pre-built health scoring but maintains its own data model that diverges from your warehouse. ClientSuccess focuses on CRM and support data with limited billing integration. For data reliability, Eru offers the strongest cross-system accuracy — it monitors Stripe webhooks and CRM change events in real time and explicitly flags when data sources disagree rather than silently using stale data.

What is the total cost of ownership for building churn prediction in Snowflake + dbt + Hex?

Over 2 years: $37K–$100K in initial development (3–6 months of a data engineer), $20K–$68K in Snowflake compute and Hex licensing, and $60K–$120K in ongoing data engineer maintenance time. Total 2-year TCO: $117K–$288K. Dedicated platforms range from $30K–$200K+ over 2 years with minimal engineering overhead and significantly faster time-to-first-signal.

How does Eru work with an existing Snowflake + dbt setup?

Eru connects to your Snowflake warehouse via OAuth and reads directly from your dbt models and tables. Your dbt-modelled metrics remain the source of truth. Eru adds cross-system entity resolution, real-time billing–CRM reconciliation, and multi-source signal correlation on top — the three capabilities that are most expensive to build and maintain in dbt. No data duplication, no schema migration, no new data silo.