What's a good LTV for an indie SaaS?

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

There's no single "good" LTV number, because LTV means nothing on its own — it only becomes useful next to your customer acquisition cost (CAC) and your churn rate. A common rule of thumb is LTV should be at least 3x CAC, but for a solo-run indie SaaS with low or zero paid acquisition cost, the more useful question is usually "is LTV high enough to justify the time I spend on this product," not "is it above some industry benchmark."

That reframing matters because most indie founders don't actually have a reliable CAC to compare against. If you're not running ads, your "acquisition cost" is mostly your own time — content, SEO, cold outreach, community posts — which is real but hard to put a dollar figure on. So before chasing a benchmark, get the calculation itself right.

What LTV actually measures

Lifetime value is the total revenue (or gross margin, in stricter versions) you expect to collect from an average customer over the entire time they stay subscribed. The simplest formula for a subscription business is:

LTV = Average Revenue Per Account (ARPA) ÷ Monthly Churn Rate

If your ARPA is $25/month and monthly churn is 5%, LTV = $25 / 0.05 = $500. Change churn to 2%, and LTV jumps to $1,250 — same product, same price, wildly different number. This is why churn, not price, usually drives LTV for small SaaS products. A $15/month tool with 2% churn often beats a $40/month tool with 8% churn.

A stricter version multiplies ARPA by gross margin before dividing, which matters more once you have real infrastructure or support costs eating into revenue. For most single-founder tools with low hosting costs, the simple formula is directionally fine — just be consistent about which version you're using when you compare months or products.

Why the "3x CAC" rule barely applies to solo founders

The 3x rule comes from SaaS businesses with dedicated sales and marketing spend, where CAC is a real, trackable dollar figure per channel. If you run 5-10 small products yourself, your acquisition "cost" is often a mix of:

• Time spent on content or SEO (hard to attribute per customer)
• A few dollars of ad spend you tested and abandoned
• Zero cost for word-of-mouth or App Store search traffic

In that situation, computing a precise CAC is often more effort than it's worth. A more practical question for a 1-20 product portfolio: given the time this product takes to maintain, does its LTV comfortably cover that time, plus whatever marginal acquisition spend you do have? If you're spending real money on ads for one specific app, then yes, compute CAC for that channel and compare it directly — that's where the ratio earns its keep.

The number that usually matters more: payback period

For indie products without heavy ad spend, payback period is often more actionable than the LTV/CAC ratio. If a customer costs you roughly $20 in trackable spend to acquire (a boosted post, a small ad test) and pays you $10/month, payback is two months. Anything under 3-6 months is comfortable for a solo operation with thin cash reserves; longer than that and you're financing growth out of pocket for a while, which is fine if you have runway and risky if you don't.

Payback period also tolerates imprecise CAC better than LTV/CAC ratio does, since you're only comparing against the cost to acquire, not projecting years of future revenue on top of it.

Where LTV breaks down across a portfolio

If you run several products, the mistake isn't calculating LTV wrong for one app — it's comparing LTV across apps as if ARPA and churn mean the same thing everywhere. A $9/month habit-tracker app with 10% monthly churn and a $49/month B2B tool with 3% churn will never look comparable on a bare LTV number, and they shouldn't. What's actually useful is tracking LTV trend per product over time, and noticing which products have churn improving (LTV rising even at flat price) versus which have churn quietly eating into any growth in signups.

This is also where blended numbers lie to you. If you're pulling revenue from both Stripe and RevenueCat for a web-plus-mobile product, churn defined differently in each source will produce two different LTVs for the "same" customer base. Reconcile the definitions — same billing period length, same treatment of trials, same handling of refunds — before you trust a combined number enough to act on it. The metrics dictionary is worth checking if you want to see exactly how a given tool defines churn and ARPA before you compare it to another tool's version.

A reasonable range to sanity-check against

Since every product's price and churn differ, treat any published "good LTV" figure as a sanity check, not a target. Rough shape to expect for a small, healthy subscription SaaS: monthly churn in the 3-7% range (lower is better, and much above 10% monthly is usually a retention problem worth investigating before you worry about LTV at all), and LTV that's at least 3-5x whatever you can clearly attribute as acquisition cost for that specific product. If you can't attribute acquisition cost cleanly, fall back to the time-justification question above — it's less precise but more honest for how most solo portfolios actually grow.

What you should actually measure, instead of hunting for a universal number: your own churn rate per product, trended over at least 3-6 months, and ARPA after accounting for any discounts or annual-plan effects. Those two inputs, tracked consistently, will tell you more about whether a specific app's economics are improving than any external benchmark will.

Keeping LTV honest across a portfolio

Disclosure: SoleOS is portfolio intelligence for multi-product founders, so this post is naturally shaped by that lens — if you run one product and already know your numbers cold, a dedicated billing analytics tool or even a spreadsheet may get you everything you need without another subscription. Where a portfolio view helps is in catching the cases above: when Stripe and RevenueCat disagree on churn for the same product, or when one app's LTV is quietly declining while a blended "portfolio MRR" number still looks fine. You can see this reconciliation approach in the live demo with sample data, no sign-up required, or read about real numbers from a 10-app portfolio to see what the trend lines actually look like at that scale.

Frequently asked questions

Should I use gross revenue or gross margin for LTV?

Gross margin is more accurate once you have meaningful infrastructure, support, or payment-processing costs. For a solo founder running lean apps with minimal fixed costs, gross revenue is often close enough — just note which version you're using so you don't compare mismatched numbers across products or months.

Does LTV include one-time purchases or only subscriptions?

The standard LTV formula (ARPA ÷ churn) is built for recurring revenue. If a product mixes subscriptions with one-time purchases or in-app purchases, calculate them separately or use a cohort-based LTV (sum of actual revenue collected per cohort over time) instead of the simple formula, since churn doesn't apply cleanly to one-time buyers.

How long of a time window do I need before LTV is reliable?

You need enough churned customers to get a stable churn rate, not just a few data points. For a small product, this often means waiting until you have at least a few dozen cancellations to trust the monthly churn percentage; before that, any LTV calculation is a rough estimate that will swing a lot month to month.

Is a higher LTV always better?

Not automatically — a high LTV built on high prices and high churn can still mean an unstable business, since you're constantly fighting to refill a leaky bucket. A lower LTV with low churn and low acquisition effort is often healthier for a solo founder than a higher LTV that requires constant new-customer spend to sustain.

Where do I find my actual churn and ARPA numbers?

Stripe's dashboard and RevenueCat both expose churn and revenue-per-customer metrics, but they define things slightly differently (trial handling, refund treatment, billing period length). Check what SoleOS connects to for the exact scopes each connector reads, or pull the raw numbers directly from each platform's dashboard if you're not using a reconciliation tool yet.