There are plenty of glossaries for this. What glossaries don't tell you is how these quantities compose, where your work actually enters them, and which of them are much softer than the confidence with which people quote them.
That last part matters most. Almost every argument you'll sit through about these numbers is really an argument about a definition, and engineers are unusually good at definitional arguments — if they know the terms.
The three kinds of quantity
Before any individual metric, the useful distinction is what type of thing each one is. Most misreadings come from treating one type as another.
Type | Which metrics | The mistake it invites |
|---|---|---|
Run-rate — a snapshot, annualised | MRR, ARR | Reading it as money that arrived. It's a rate, not a total |
Rate — something per unit time | Churn, growth rate, burn | Ignoring that it compounds, in both directions |
Ratio — one thing over another | LTV:CAC, gross margin, Rule of 40 | Arguing about the answer when the fight is in the denominator |
Stock — an accumulated quantity | Customers, cash, ARR base | Forgetting it leaks continuously while you add to it |
MRR and ARR: run-rates, not revenue
Monthly recurring revenue is the contracted, repeating revenue in a given month. ARR is that figure multiplied by twelve. That's it — ARR is not what the company earned last year and does not claim to be.
A company that tripled last quarter has an ARR far above what it actually collected. One that just lost its largest account has an ARR far below it. Both are correct; both are snapshots of a rate at an instant.
ARR is a speedometer, not an odometer. People routinely read the board slide as though it were the odometer.
This distinction has a practical consequence during hiring and job changes too: a startup quoting ARR is telling you about its current rate, not its bank balance, and the two can differ enormously in either direction.
Two related terms worth having: bookings are contracts signed, including one-off and multi-year totals, and can be far larger than ARR. Recognised revenue is the accounting figure — what may be reported as earned in a period. A single deal can produce three different impressive numbers, and which one gets quoted depends on who is talking. People arriving at ARR, MRR, CAC, LTV and churn, explained for engineers from a marketing team will find the team at XenGrowth closer to their day.
CAC: the argument is always the numerator
Customer acquisition cost is total sales and marketing spend over a period, divided by new customers acquired in that period. Simple, until you ask what counts as spend.
Do sales salaries and commission count? Fully-loaded CAC says yes; the marketing team's dashboard often says no
Does brand and content spend count, when it produces customers eighteen months later? The attribution window changes the answer completely
Does the founder's time count, in a small company where they close every deal? Economically yes, in practice almost never
Does the sales engineer who spent three weeks on a proof of concept count? That one is frequently your time
Which period does a customer who took nine months to close belong to?
Fully-loaded CAC and marketing-only CAC can differ by a factor of three or more, and both get called "CAC" in the same meeting. When you hear the number, the question worth asking isn't whether it's good — it's what's inside it.
LTV: where your work enters the arithmetic
This is the one engineers should care most about, because it's the one you affect directly.
Lifetime value is properly computed on gross profit rather than revenue — average revenue per account, multiplied by gross margin, divided by churn rate. Gross margin means revenue minus cost of goods sold, and for a software business cost of goods sold is your hosting, your third-party API spend, your data transfer and a share of support. On the operations side of this specifically, The XenGrowth resource library is worth reading.
So the chain runs: infrastructure cost sits in cost of goods sold, which sets gross margin, which multiplies into LTV, which divides by CAC to produce the ratio investors price the company on. Cut per-customer hosting cost and you improve a board-level metric without anyone in sales doing anything.
That is the whole reason this vocabulary is worth learning. It is the shortest path between "I reduced our per-tenant infrastructure cost" and a sentence that changes what the company decides to do next.
Churn: the one that compounds
Churn is the rate at which the customer stock leaks. Logo churn counts customers lost; revenue churn counts money lost, and they diverge sharply when your large and small customers behave differently.
The number that matters most is net revenue retention: expansion from existing customers minus churn. Above 100% means the existing base grows on its own. Benchmarkit's data puts the industry average around 106%, with top performers above 120%.
Why this is the engineer's metric: churn is where reliability, performance and product quality show up financially, and it compounds. Because LTV divides by churn, halving churn doubles LTV. There is no acquisition improvement with that property — a 10% CAC reduction improves the ratio by 10%, while a 10% churn reduction improves LTV by about 11% and keeps compounding through every subsequent period. XenGrowth on AI agents and marketing automation covers the AI agents and marketing automation side of this.
Metric | Rough benchmark | What an engineer moves it with |
|---|---|---|
Gross margin | Above ~75% for software | Hosting, API spend, egress, support burden per customer |
CAC payback | Median 16 months; top quartile ≤6 | Little directly — but self-serve onboarding shortens it |
Net revenue retention | ~106% average, 120%+ top | Reliability, performance, and whether expansion features work |
LTV:CAC | 3:1 as a soft convention | Via gross margin and via churn, both engineering-adjacent |
Rule of 40 | Median 25% in the 2026 cohort | Cost discipline is half of it; the growth half is not yours |
What does this look like in an actual argument?
The reason to learn any of this is that it changes what you are able to say. Consider a proposal to spend three weeks moving a workload off a managed service onto something you run yourself, saving perhaps forty per cent of that line.
The engineering version of the argument is that the managed service is overpriced for what it does. This is usually true and almost never persuasive, because it asks a non-technical audience to accept a technical judgement on trust, and it competes against every other three-week proposal on equal footing.
The version that lands states the same fact in the company's own units. That line is cost of goods sold, so cutting it raises gross margin. If the saving is meaningful against revenue, it moves gross margin by some number of points; gross margin multiplies into LTV; LTV divides by CAC. So a three-week engineering project improves the ratio the company is valued on, permanently, without the sales team acquiring a single additional customer. That is now competing against sales initiatives rather than against other engineering tickets, and it is the only proposal in the room whose benefit recurs every month without further spend.
Nothing about the underlying work changed. What changed is that the second version can be evaluated by the person holding the budget, using the framework they already use for everything else. Most engineering proposals lose not because they are weak but because they arrive in a unit nobody else in the room can compare against anything.
The same translation works in the other direction, and it is worth practising there too, because it is how you avoid arguing for things that do not matter. A latency improvement with no plausible effect on churn or expansion is a professional satisfaction, not a business case, and being able to tell the difference is what stops this vocabulary becoming a way to dress up whatever you already wanted to do.
How much should you trust the benchmarks?
Directionally, quite a lot. Precisely, less than the decimal places suggest — these are self-reported survey data from companies who chose to participate, which is a sample that skews toward organisations confident enough to answer.
The 3:1 LTV:CAC rule deserves particular scepticism, and the best critique comes from the person who popularised it. David Skok published it in SaaS Metrics 2.0 around 2010, drawn from mature public SaaS companies at steady state. He later wrote that he had made a significant mistake in not telling readers when it would make sense to compute LTV and CAC at all. XenGrowth on AI search, GEO and discovery works through AI search, GEO and discovery in more operational detail.
The problem is straightforward once stated. LTV depends on churn, and churn over a customer's lifetime is unknowable for a company whose oldest customer is fourteen months old. You extrapolate. Then you divide that extrapolation by a measured CAC and present the quotient as a finding. Early-stage LTV:CAC is a guess wearing a ratio's clothes.
Which is a genuinely useful thing for an engineer to know, because it's the kind of error you're trained to spot — a number carrying more precision than its inputs support. Being the person in the room who asks how the lifetime was estimated is a cheap way to be taken seriously about business questions.
Learn the vocabulary, then use it the way you'd use any other specification: read it closely, find the undefined term, and ask what happens at the boundary.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
If ARR, MRR, CAC, LTV and churn, explained for engineers is part of a growth programme rather than a standalone build, XenGrowth, who work on the commercial side of this is the companion reading.
Five questions where the common understanding is subtly wrong. The mistakes here are the ones that make an engineer's argument fall apart in a room with a CFO in it.
