The Math Behind $1M ARR: Why Your Spreadsheet Can't Predict Lifetime Value

By Dr. Evelyn Hartwell, PhD in Artificial Intelligence

You've built a beautiful spreadsheet. You've plugged in your monthly churn rate, your average contract value, and your growth coefficient. You run the projection forward 24 months. The number at the bottom says $1.2M ARR. You feel good about it. Your investors are happy. Your board is impressed.

Here's the uncomfortable truth: that spreadsheet is a model of your assumptions, not of your customers. And those two things diverge more often than you'd like to admit.

The gap between "projected LTV" and "realized LTV" is where most SaaS companies quietly die—not with dramatic failure, but with the slow drift of customers who stay longer or shorter than your formula predicted, who expand or shrink in ways your static multiplier didn't account for, who churn in clusters during economic downturns that no single number captures.

This isn't a spreadsheet problem. It's a mathematics problem. And the solution is less about better data entry and more about fundamentally different tools.

The Static Formula That Flatters You

The classic LTV calculation looks deceptively simple:

$$LTV = \frac{ARPU \times (1 - ch) + ARPU \cdot ch \cdot (1-ch)}{ch}$$

Or, in the more common simplified form you've probably used:

$$LTV = \frac{ARPU}{ch}$$

Where $ARPU$ is your average revenue per user and $ch$ is your monthly churn rate. Clean. Elegant. And quietly wrong for anyone past seed stage.

The assumption baked into that fraction is that every customer is identical, that revenue is a constant stream, and that churn is a uniform probability applied to every account on the same schedule. It's like predicting how long a population of people will live by calculating the average lifespan of a single person. You get a number. That number tells you almost nothing about any specific individual.

For your spreadsheet, this works fine up to maybe 50 customers. You can eyeball the outliers. You know which accounts are expanding because Sarah in marketing called and said so. You remember that Acme Corp just signed on with three new seats. Your model is a collection of facts you happen to have stored in your brain, and the spreadsheet is the part you don't need to think about.

Scale past 200 customers and something changes. Now Sarah's memory isn't reliable enough. Now the "average" churn rate is being computed over accounts that behave in fundamentally different ways—a startup with a 4-person team that will expand 10x or be acquired, versus an enterprise account with procurement cycles measured in months and budget committees that can stall renewal for two quarters. Your spreadsheet treats them as interchangeable inputs to the same formula.

And yet both are just rows in your CSV export.

The Non-Linearity Problem

Here's where it gets genuinely interesting mathematically, and where most people stop caring about the details because they're not in the spreadsheet.

Customer lifetime value is not a linear function of time. It's not a function of contract size alone. It isn't even really a function of churn rate as a single scalar.

Consider what actually determines whether a customer generates $50K or $500K over their lifetime:

• Adoption depth: How many teams within the account are actually using the product? A 200-seat contract where only 30 people log in weekly is economically different from one where all 190 are active. Your spreadsheet sees "200 seats" for both.

• Feature migration paths: Customers who adopt your advanced analytics module in month three behave differently than those who stay on the basic tier indefinitely. The relationship between "features used" and "revenue per user" is not a constant ratio—it's a function that shifts based on which features, in what order, at what frequency.

• Integration depth: Accounts with API integrations into their internal systems have structurally different switching costs than those who just log in daily. Your churn rate averages these together and loses the information entirely.

• Expansion triggers vs. contraction triggers: A customer who gets a new VP of Engineering often expands. One who goes through a reorg might quietly shed seats without you knowing for two billing cycles. These are correlated events, but correlation isn't causation, and your spreadsheet can only average over both directions.

If we model this properly, LTV becomes:

$$LTV _i = \sum_{t=1}^{T_i} R_i(t) \cdot \prod_{s=1}^{t}(1 - p_i(s))$$

Where $R_i(t)$ is the revenue from customer $i$ at time $t$, and $p_i(s)$ is the probability that customer $i$ churns at step $s$. Notice what this looks like: it's a product of probabilities multiplied by a sequence of revenues. Every single term in that product depends on the specific trajectory of that specific customer. Your spreadsheet collapses all of that into two numbers and a division.

For 10 customers, you can track these trajectories manually. For 500, you need something that can learn the relationship between observable signals—usage patterns, support ticket frequency, feature adoption velocity, integration count—and the actual revenue trajectory that unfolds over months or years.

That's not a spreadsheet task. That's a pattern-recognition problem operating in a high-dimensional space where the dimensions are customer behaviors and the output is a probability-weighted revenue curve.

Where Machine Learning Actually Helps (And Where It Doesn't)

Let me be precise here, because the AI industry has a habit of overclaiming, and I'd rather not contribute to that.

What you need for LTV prediction at scale is not a single neural network with 50 layers doing some mysterious computation on your CRM data. What you need is a system that:

1. Learns the conditional probability structure: Given that customer $i$ has used feature set $F_i$, filed support tickets at rate $\lambda_i$, integrated systems in category $C_i$, and has been active for duration $d_i$—what is the expected revenue trajectory over the next 12, 24, 38 months?

This is a supervised learning problem with a twist: your target variable (future revenue) isn't fully observable until time passes. You're essentially doing survival analysis crossed with regression, where you need to model both whether a customer stays and how much value they generate while they stay.

2. Handles the non-stationarity: Your churn drivers in Q1 2024 are not your churn drivers in Q3 2026. Product changes, market conditions, competitive dynamics—all shift. A static model trained on last year's data is predicting this year's customers with last year's rules. You need a system that updates its internal representation continuously as new outcomes become observable.

3. Accounts for heterogeneity: Not all segments respond the same way to the same signals. For your startup segment, support ticket frequency might be a strong negative predictor of retention. For your enterprise segment, it might indicate active adoption (more tickets = more usage). A good model learns these segment-conditional relationships without you having to manually define them.

4. Quantifies uncertainty: Your spreadsheet gives you one number: $LTV = 28{,}400$. A proper predictive system gives you a distribution: there's a 65% probability this customer generates between $15K and $30K over their lifetime, a 25% chance they expand to $50K+, and a 10% chance they churn within 8 months. That range of uncertainty is what your CFO actually needs to make budgeting decisions.

Now, where does AI not help? If you have 30 customers and you know each one personally, a spreadsheet plus your gut instinct will outperform any model I can build for you. The overhead of building, validating, and maintaining a predictive system is only worth it when the volume and heterogeneity of your customer base makes human tracking impractical.

And if your product has a very simple value proposition with minimal feature depth—think: a single API call that either works or doesn't—then LTV prediction is closer to what your spreadsheet does, because there really aren't many different trajectories for customers to follow. The model just learns the same relationship your formula encodes.

Building Toward the Model That Matches Your Reality

Here's a practical framework for thinking about this transition from spreadsheet to predictive system:

Start with your data quality audit. Before you build any model, ask: do I have granular usage logs? Do I know which features each customer uses? Do I track expansion events as discrete data points or just in revenue totals? Can I distinguish between organic growth and contractual seat increases? If the answer is "sort of" to all of these, your first project isn't a model—it's an instrumentation project. You need the signals that actually predict outcomes before you can learn from them.

Build the baseline. Before any ML, build a simple segment-based projection: group customers by company size, industry, and adoption depth (you'll define "adoption depth" based on your product's actual feature set). Compute LTV per segment using historical cohorts. This is still spreadsheet-level work, but it starts to respect heterogeneity. You'll probably find that your "average" LTV hides a spread of 3x or more between segments.

Add the dynamic layer. Now you can introduce a model—gradient-boosted trees are usually the right starting point for tabular customer data (they're interpretable, robust to missing values, and don't need GPU clusters). Feed it your usage signals, engagement metrics, firmographics, and time-since-signup. Train on customers whose full lifecycle you already know (you have 12+ months of outcome data for them) and predict forward for current active accounts.

Close the loop. This is the step most people skip. Every month, new cohorts complete their first year or two. Your model's predictions can now be validated against actuals. Update weights, refine features, retire signals that stopped predicting well. The spreadsheet doesn't do this—it just keeps using the same formula forever, even as your customer base and product evolve.

What This Looks Like in Practice

Let me sketch what a mature LTV prediction system looks like operationally:

You have 340 active customers. Your model outputs, for each account, an expected revenue curve over the next 36 months with confidence intervals. You segment these into:

Your spreadsheet would have said: "Average LTV is $41,000." That number isn't wrong. It's just not useful for any specific decision you actually need to make—because it tells you nothing about which 18 accounts drive most of your revenue, which 56 are quietly bleeding value, or which segment's expansion behavior is shifting this quarter.

Your CS team knows the high-adoption enterprise accounts and treats them differently. Your onboarding team focuses energy on the startup segment where adoption depth determines whether they expand or churn. Your product team looks at usage patterns in the mid-tier segment to identify which features drive stickiness. Each decision needs different information, and a single average number serves none of them well.

The Deeper Point About Prediction

Here's something I think is underappreciated: prediction is not a property of your data. It's a property of the relationship between your data and the outcome you care about.

Your spreadsheet assumes that relationship is simple, stable, and uniform. A predictive model learns that it's complex, shifting, and heterogeneous—and then makes that complexity usable for decisions without any individual needing to track 340 customer trajectories in their head.

You don't need AI to replace your spreadsheet. You need a system that does the work your brain currently does—remembering which accounts are expanding, which features correlate with stickiness, which segments behave differently under economic stress—and scales that cognitive labor across hundreds or thousands of accounts without fatigue.

The math is more elegant than the spreadsheet. The implementation is more complex. But if you're building toward $1M ARR and beyond, the difference between "we project LTV at $40K per customer" and "here's what we expect from each account, how confident we are, and which signals to watch"—that difference is where the margin lives.

And it's where your spreadsheet quietly underestimates you.