Churn Prediction: Build vs. Buy for B2B SaaS

The Build Case

When to Build

Building a churn prediction model makes sense in three specific scenarios:

Fewer than 10,000 customers. At this scale, a logistic regression or gradient-boosted model built in Python or R delivers strong predictions without platform overhead. A B2B SaaS company with 2,000 customers and clean event data can build a model that catches 70% of churners with a weekend's work and a few 100 lines of code. Academic research on B2B SaaS churn using the KTH Younium dataset found that Random Forest models achieve an AUC of 0.905 on this scale — nearly perfect discrimination.

Clean data. Your event tracking, CRM, billing, and support data are consistent and linked by a common customer identifier. This is the prerequisite, not the outcome. If your data is dirty — inconsistent event naming, missing properties, orphaned customer records — no model will save you. The KTH thesis found that feature engineering (customer metrics like contract renewal rate and booking entropy) mattered more than the choice of algorithm.

Someone to maintain it. A data analyst or engineer who can retrain the model quarterly, monitor drift, and update features. The initial build is 20–30% of total lifecycle cost. Annual maintenance is 20–25% of the initial build cost. Over a 3-year horizon, maintenance is 70–80% of total cost. If nobody owns that, don't build.

What Building Costs

The $15K–30K Year 1 estimate assumes a mid-level data analyst at $120K/year (fully loaded). If you're using an existing engineer who's already on the team, the marginal cost is time, not cash. But that time has an opportunity cost — every week spent building a churn model is a week not spent on product features, activation optimization, or expansion experiments.

What Building Gets You

Full control over features. You decide which behavioral signals matter — engagement velocity, feature breadth contraction, support ticket patterns — not the platform's default feature set. In our work with a healthcare SaaS client, we found that the single strongest churn predictor wasn't login frequency or feature usage. It was the rate of change in support ticket sentiment — a signal no off-the-shelf platform includes by default. That engagement alone drove a 23% churn reduction in 90 days.

No platform lock-in. Your model runs on your infrastructure. If you switch tools, the model goes with you. This matters because the average B2B SaaS company changes its CS platform every 3–4 years.

Cost efficiency at scale. Once built, the ongoing cost is near-zero. A platform charges per month forever. At $5K/month, a Gainsight license costs $60K/year — more than the entire Year 1 build cost, every year.

Where Building Fails

Model drift. Training data from 6 months ago doesn't reflect today's user behavior. The KTH thesis found that XGBoost models achieved AUC scores between 0.79 and 0.92 depending on the dataset and feature set. That range tells you something important: the same algorithm can be excellent or mediocre depending on how well the training data matches the current reality. Most teams that build a model and forget it see precision drop from 85% to 60% within 6 months.

CS team adoption. If the model produces a list of 200 "at-risk" accounts with no explanation of why, the CS team will ignore it. Customer success teams abandon model scores within approximately 6 weeks when flooded with false positives. The model needs to produce not just a score but the top 3 signals driving that score.

The false positive trap. In production, 60–70% recall (catching 60–70% of actual churners) with 20–30% precision (20–30% of flagged accounts actually churn) is realistic. That means for every 10 accounts flagged as at-risk, 7–8 won't actually churn. If your CS team gets 200 flags per month and only 40–60 are real, they'll stop trusting the model. Don't chase 90%+ accuracy — you'll overfit to historical data and underperform on live customers.

The Buy Case

When to Buy

Buying a churn prediction platform makes sense in three different scenarios:

More than 10,000 customers. At this scale, a platform's automated feature engineering and model management become cost-effective. The marginal cost per customer drops as volume increases, and the platform's ability to handle complex feature interactions at scale exceeds what a small team can maintain manually.

No dedicated data science resources. You need churn prediction but can't justify hiring a data scientist or dedicating an engineer to model maintenance. Platforms handle the entire ML lifecycle — feature engineering, model training, drift detection, retraining — without engineering involvement.

CS team needs a no-code solution. The platform should produce an at-risk list that CSMs can act on without understanding the model behind it. If your CS team can't run a SQL query or interpret a confusion matrix, they need a platform that translates model outputs into plain-language alerts: "Account X is at risk because feature usage dropped 40% and their champion just left the company."

What Buying Costs

Platform pricing should be evaluated against the all-in cost of churned customers. For a company at $5M ARR with 5% monthly churn, that's $250K in lost MRR per month — or $3M annually. A $5K/month platform that reduces churn by even 5% relative ($12.5K/month) pays for itself 2.5× over.

What Buying Gets You

Automated model management. The platform handles feature engineering, retraining, drift detection, and precision monitoring. No quarterly maintenance sprints. No "hey, has anyone checked if the model still works?" Slack messages from 3 months ago.

CS integration out of the box. The at-risk list appears in your CS platform with intervention playbooks already attached. No dashboard-to-playbook translation needed. Gainsight, for example, includes 6 key data measures out of the box — usage, feature adoption, sentiment, engagement, relationships, and customer value — each mapped to specific CSM actions.

Faster time to value. Platforms deploy in 2–6 weeks vs. 4–8 weeks for a custom build (plus the time to figure out what you're building). If churn is bleeding $50K/month, the 4-week deployment advantage of a platform is worth $200K in saved revenue.

Where Buying Fails

The data cleanup tax. Platforms assume clean input. If your CRM has duplicate accounts, billing has orphaned subscriptions, and support has unlinked tickets, you'll spend 4–8 weeks cleaning data before the platform produces useful predictions. This cost is rarely included in the vendor's implementation estimate. We've seen teams budget 2 weeks for platform setup and spend 6 weeks on data reconciliation.

Platform lock-in. Your churn model lives inside the platform. The features it engineers, the patterns it learns, the weights it optimizes — all proprietary to the platform. If you switch, you rebuild from scratch. This is the mirror image of the build case's advantage.

Overkill for small teams. A $5K/month Gainsight license for a company with 500 customers is like buying a semi-truck to deliver pizza. The platform's value scales with customer count and CS team size. Below 2,000 customers and 3 CSMs, the platform's automation is solving a problem you don't have yet.

The Build vs. Buy Decision Tree

This decision tree is intentionally simple. The real world is messier. Here are the edge cases we see most often:

"We have 8,000 customers but our data is a disaster." Clean the data first. A platform won't fix dirty data — it'll just produce confident-sounding garbage. Start with event taxonomy design: define your core events, standardize naming, link customer records across systems. This is 4–8 weeks of work, but it's work you need to do whether you build or buy. See our event taxonomy guide for the 5 signal areas you must instrument.

"We have 15,000 customers and a data analyst who's excited about this." Let them build v1. Prove the intervention workflow works. Then evaluate platforms once you've learned what signals matter. Building first gives you the knowledge to evaluate platforms intelligently instead of trusting vendor demos.

"We're at $10M ARR and have neither data science nor CS ops." Buy. At this scale, the cost of churn exceeds the cost of the platform by orders of magnitude. If your monthly churn is 3% on $10M ARR, that's $300K/month in lost MRR — $3.6M/year. Even a platform that reduces churn by 5% relative ($15K/month) pays for itself 3× over at the highest price tier.

The Intervention Gap

Here's what most teams miss: the prediction is not the value. The intervention is.

A model that identifies 200 at-risk accounts but doesn't tell the CS team what to do about them produces anxiety, not action. The teams that achieve 5–15% relative churn reduction don't do it with better models. They do it with better intervention playbooks.

The playbook structure that works:

1. At-risk list — ranked accounts with the top 3 signals driving each score. Not just "Account X: 73% churn probability." But "Account X: 73% churn probability because (a) engagement velocity dropped 40% WoW, (b) feature breadth contracted from 12 to 4 features, (c) support ticket sentiment turned negative."
2. Intervention type — matched to the churn driver. Onboarding gap → guided walkthrough. Pricing concern → value review. Feature gap → roadmap briefing. Competitive threat → differentiation briefing. In our work with an HR platform, we identified 6 distinct churn drivers in a single cohort and built intervention playbooks for each — resulting in a $250K–400K conversion opportunity.
3. Outcome logging — did the intervention work? Saved, lost, or deferred. This becomes training data for the next model iteration. Without outcome logging, the model never learns whether its predictions were right.

The timing matters as much as the playbook. Our intervention timing data shows:

The difference between intervening at Day 0 and Day 45 is a 3–4× improvement in save rate. The prediction model's job isn't just to flag at-risk accounts. It's to flag them early enough for the intervention to work.

If you build: You need to design the intervention workflow yourself — dashboard → playbook → outcome logging. The advantage: you can customize it to your exact churn archetypes. The disadvantage: it's additional work on top of the model.

If you buy: Most platforms include intervention playbooks. But they're generic — "schedule a check-in call," "send a value review email." You'll need to customize them to your specific churn drivers. The platform gives you the skeleton. You provide the muscle.

The 6 Churn Archetypes

Your intervention playbook only works if it's matched to the reason the customer is churning. A pricing intervention won't save a customer who's churning because they never completed activation. A feature demo won't save a customer whose budget was cut.

We categorize churn into 6 archetypes, each requiring a different intervention:

The build vs. buy decision affects how you identify these archetypes. A custom model can be designed to classify customers into archetype buckets based on behavioral patterns. A platform gives you a generic risk score that you need to manually categorize. But the intervention itself — what you actually do — is the same either way. And it's the intervention that saves the account.

FAQ