3
19 Comments

4 things about SaaS unit economics that surprised me while building free calculators

I've been building free SaaS calculators as a side project (churn, CAC, LTV, revenue growth, and client qualification). While researching the formulas and benchmarks, I kept finding stuff that made me rethink how I look at my own numbers.

Your LTV (life time value) is probably lower than you think

Most LTV calculators online use ARPU (average revenue per user) × average lifetime. Simple, but wrong. A $99/mo customer who stays 18 months looks like $1,782 in LTV. But if your gross margin is 60%, you're actually only keeping $1,069. I've seen founders use the inflated number to calculate their LTV:CAC (life time value to customer acquisition cost) ratio and conclude their economics are healthy when they're actually not.

Churn reduction compounds in a way that's hard to intuit

You probably already know this one. Going from 5% monthly churn to 4% doesn't sound like much, but average customer lifetime goes from 20 months to 25 months. A 25% increase in lifetime (and LTV) from a single percentage point. Going from 4% to 3% is even bigger, 25 months to 33 months. The lower your churn gets, the more each additional point is worth. This is why enterprise SaaS with 1% churn have such insane LTV numbers.

LTV:CAC ratio is meaningless without payback period

A 3:1 LTV:CAC ratio sounds healthy, but if your payback period is 18 months, you need to fund 18 months of negative cash flow per customer before you see profit. Compare that to 3:1 with a 6-month payback, completely different cash flow reality. For bootstrapped founders without a runway buffer, payback period matters more than the ratio itself. I didn't fully get this until I built the CAC calculator and started modeling both numbers side by side.

"Good" churn depends entirely on your segment

5% monthly churn is fine for B2C SaaS (where 5-8% is normal). The same 5% in enterprise B2B is a disaster (should be under 2-3%). Without knowing your segment's benchmark, you can't tell if you have a retention problem or if you're actually doing well. I added segment-specific benchmarks to the calculators because I kept seeing founders either panicking about normal numbers or ignoring churn that was actually killing their business.

I built free calculators for all of these if anyone wants to check their numbers: beyondfolder.com/tools

Curious if others have run into similar surprises with their own metrics. What's one number you calculated that changed how you thought about your business?

on March 9, 2026
  1. 2

    nice to see churn<->average lifespan connection (y)

  2. 1

    The number that changed everything for us: which blog post actually drives paying customers. We tracked traffic attribution for months but had no idea conversions were almost entirely from one article. Revenue attribution tied to content source — that single metric rewired how we approach content completely. zenovay.com does exactly this for $20/mo.

  3. 1

    Free calculators are underrated as a distribution tool and I think it is because the connection to the paid product is not always obvious.

    The ones that work have two things: they solve a real question (not just a toy), and they make the answer feel uncomfortable in a way that points toward the product.

    I built an Apollo cost calculator (apollocalc.surge.sh) that shows what people are paying per contact per month on Apollo vs what the same coverage costs with a script and Hunter.io API. The result is almost always a 5-10x cost difference. It does not tell people what to do - it just makes the math visible.

    The insight on unit economics you described is exactly what that calculator is designed to show in a concrete, personalized way. Generic advice about "Apollo is expensive" does not land. Showing someone their specific number ($186/month for 200 contacts vs $19/month for the same) lands immediately.

    What surprised you most in the unit economics - was it the cost side or the revenue side?

  4. 1

    Free calculators are underrated as a distribution tool and I think it is because the connection to the paid product is not always obvious.

    The ones that work have two things: they solve a real question (not just a toy), and they make the answer feel uncomfortable in a way that points toward the product.

    I built an Apollo cost calculator (apollocalc.surge.sh) that shows what people are paying per contact per month on Apollo vs what the same coverage costs with a script and Hunter.io API. The result is almost always a 5-10x cost difference. It does not tell people what to do - it just makes the math visible.

    The insight on unit economics you described is exactly what that calculator is designed to show in a concrete, personalized way. Generic advice about "Apollo is expensive" does not land. Showing someone their specific number ($186/month for 200 contacts vs $19/month for the same) lands immediately.

    What surprised you most in the unit economics - was it the cost side or the revenue side?

  5. 1

    Free calculators are underrated as a distribution tool and I think it is because the connection to the paid product is not always obvious.

    The ones that work have two things: they solve a real question (not just a toy), and they make the answer feel uncomfortable in a way that points toward the product.

    I built an Apollo cost calculator (apollocalc.surge.sh) that shows what people are paying per contact per month on Apollo vs what the same coverage costs with a script and Hunter.io API. The result is almost always a 5-10x cost difference. It does not tell people what to do - it just makes the math visible.

    The insight on unit economics you described is exactly what that calculator is designed to show in a concrete, personalized way. Generic advice about "Apollo is expensive" does not land. Showing someone their specific number ($186/month for 200 contacts vs $19/month for the same) lands immediately.

    What surprised you most in the unit economics - was it the cost side or the revenue side?

  6. 1

    Free calculators are underrated as a distribution tool and I think it is because the connection to the paid product is not always obvious.

    The ones that work have two things: they solve a real question (not just a toy), and they make the answer feel uncomfortable in a way that points toward the product.

    I built an Apollo cost calculator (apollocalc.surge.sh) that shows what people are paying per contact per month on Apollo vs what the same coverage costs with a script and Hunter.io API. The result is almost always a 5-10x cost difference. It does not tell people what to do - it just makes the math visible.

    The insight on unit economics you described is exactly what that calculator is designed to show in a concrete, personalized way. Generic advice about "Apollo is expensive" does not land. Showing someone their specific number ($186/month for 200 contacts vs $19/month for the same) lands immediately.

    What surprised you most in the unit economics - was it the cost side or the revenue side?

  7. 1

    Free calculators are underrated as a distribution tool and I think it is because the connection to the paid product is not always obvious.

    The ones that work have two things: they solve a real question (not just a toy), and they make the answer feel uncomfortable in a way that points toward the product.

    I built an Apollo cost calculator (apollocalc.surge.sh) that shows what people are paying per contact per month on Apollo vs what the same coverage costs with a script and Hunter.io API. The result is almost always a 5-10x cost difference. It does not tell people what to do - it just makes the math visible.

    The insight on unit economics you described is exactly what that calculator is designed to show in a concrete, personalized way. Generic advice about "Apollo is expensive" does not land. Showing someone their specific number ($186/month for 200 contacts vs $19/month for the same) lands immediately.

    What surprised you most in the unit economics - was it the cost side or the revenue side?

  8. 1

    Free calculators are underrated as a distribution tool and I think it is because the connection to the paid product is not always obvious.

    The ones that work have two things: they solve a real question (not just a toy), and they make the answer feel uncomfortable in a way that points toward the product.

    I built an Apollo cost calculator (apollocalc.surge.sh) that shows what people are paying per contact per month on Apollo vs what the same coverage costs with a script and Hunter.io API. The result is almost always a 5-10x cost difference. It does not tell people what to do - it just makes the math visible.

    The insight on unit economics you described is exactly what that calculator is designed to show in a concrete, personalized way. Generic advice about "Apollo is expensive" does not land. Showing someone their specific number ($186/month for 200 contacts vs $19/month for the same) lands immediately.

    What surprised you most in the unit economics - was it the cost side or the revenue side?

  9. 1

    The gross-margin-adjusted LTV point is criminally underemphasised. Founders optimising LTV:CAC on revenue rather than gross profit are flying blind — your real LTV could be 40-60% of what you think if your COGS are significant.

    One thing worth adding to the churn section: involuntary churn (failed payments, expired cards) is often excluded from churn calculations because it doesn't look like intent-to-cancel. But it's 20-40% of actual churn for most SaaS products and it's almost entirely recoverable with a proper Day1/Day3/Day7 email sequence. Reducing it from 3% to 1.5% monthly has the same compound effect as the examples you showed, but it's mechanically fixable rather than a product problem. We built tryrecoverkit.com/connect specifically to automate this.

  10. 1

    The LTV point is a good reminder of how easy it is to accidentally look at “optimistic” numbers.

    Something else I’ve noticed is that many founders track churn and LTV but don’t analyze when churn happens. Early churn in the first 1–2 months usually points to onboarding or expectation mismatch, while later churn often relates to value decay or pricing perception.

    Looking at churn timing instead of just the percentage can completely change where you focus improvements.

    Curious if you’ve noticed any patterns like that while building the calculators.

    1. 1

      Honestly haven't notice this regarding churn, seems outside of the scope of the calculators since it's a harder thing to track

  11. 1

    The LTV/CAC math changes significantly when you shift from subscription to one-time pricing.

    With one-time pricing, the CAC has to be recovered in a single transaction - there's no LTV multiplier working in your favor. This forces really tight targeting: you need to find people who both have the problem AND will act on it now.

    The interesting flip side: your payback period is day 1 (or never). No churn risk, no monthly MRR anxiety. The metric that matters becomes "did they buy?" rather than "do they keep paying?".

    Free calculators are smart at the top of funnel - they remove the friction of "will this be worth my money" by letting people see the value first. What's the conversion rate from free calculator use to paid product?

    1. 1

      Only started creating the tools, so no conversions yet. Waiting on SEO to work

      Your point about one-time pricing is right though, might have to include that in the calculators

  12. 1

    Interesting breakdown. The payback period point especially stands out — a lot of founders focus heavily on the LTV:CAC ratio without thinking about the cash-flow timing behind it.

    One thing I've been noticing while working on backend infrastructure for SaaS products is how many founders underestimate how usage-based costs affect margins over time. Things like API calls, storage, or third-party services can slowly eat into gross margin, which then impacts the “real” LTV number you mentioned.

    Curious — did you notice any patterns in how different SaaS pricing models (subscription vs usage-based) affect those benchmarks?

  13. 1

    The churn compounding section is the one most founders under-internalize. Going from 5% → 4% monthly sounds small, but you're right that it's a 25% increase in customer lifetime. The arithmetic is counterintuitive until you see it modeled.

    One thing worth adding to the churn analysis: not all churn is equal. Voluntary churn (cancellations) and involuntary churn (payment failures) have completely different economics. Involuntary churn — where the customer's card expires or gets declined and they never come back — is typically 20-30% of total churn for subscription SaaS. It's 'free' churn to fix because the customer didn't want to leave.

    The implication for your compounding math: if your churn is 5% and 1.5% of that is involuntary, you can potentially get to 3.5% churn with better dunning automation before needing to touch product or pricing. That jump from 5% to 3.5% monthly is a 35% increase in customer lifetime.

    Good calculators. The segment benchmarking point is underrated — a lot of founders are comparing their B2C numbers to B2B benchmarks and freaking out for no reason.

    1. 1

      Thanks for checking them out! Indeed churn is underrated but it seems more people are aware of it now

  14. 1

    The gross margin-adjusted LTV point is probably the single most important correction most early-stage SaaS founders need to make. I've seen the "naive LTV" number get used to justify CAC spending that was actually completely unsustainable — founders were essentially celebrating economics that didn't exist.

    The payback period point is equally underrated. A 3:1 LTV:CAC ratio with a 36-month payback is basically a bet that you won't run out of cash before the economics kick in. For bootstrapped founders especially, payback period is the number that actually determines survival.

    One more thing I'd add to the list: the relationship between NRR (net revenue retention) and LTV. If your NRR is above 100% — meaning expansion revenue from existing customers exceeds churn — your LTV math changes completely. The cohort doesn't have a "lifetime" in the traditional sense; it grows. Most LTV calculators don't even have a field for this.

    Were you surprised by how much the gross margin assumption changed the implied LTV:CAC ratios in your calculators?

    1. 1

      Indeed was a bit surprised since people don't usually share their margins, only gross MRR

  15. 1

    The churn compounding point is the most counterintuitive, and the one that makes payment recovery so financially interesting.

    Going from 5% to 4% monthly churn: average customer lifetime goes from 20 to 25 months. A 25% lifetime increase from one percentage point — your example is exactly right.

    The question worth adding: how much of your 5% monthly churn is involuntary — subscriptions lapsing because a payment failed, not because the customer chose to leave? Industry benchmarks put involuntary churn at 20-40% of total churn for subscription businesses. If 1-2% of that 5% is payment failures, fixing it with a proper D+1/D+3/D+7 recovery sequence (which recovers 20-40% of failures) could move you from 5.0% to ~4.7% monthly churn for essentially no product investment.

    A smaller lifetime gain than your example, but the ROI is different: you're not reducing churn by improving the product or acquiring better customers — you're recovering customers who already wanted to stay. That's the churn reduction no one models into their LTV calculator. tryrecoverkit.com

Trending on Indie Hackers
7 years in agency, 200+ B2B campaigns, now building Outbound Glow User Avatar 102 comments 11 Weeks Ago I Had 0 Users. Now VIDI Has Reviewed $10M+ in Contracts - and I’m Opening a Small SAFE Round User Avatar 47 comments The "Book a Demo" Button Was Killing My Pipeline. Here's What I Replaced It With. User Avatar 41 comments I built a desktop app to move files between cloud providers without subscriptions or CLI User Avatar 24 comments How I built an AI workflow with preview, approval, and monitoring User Avatar 23 comments My AI bill was bleeding me dry, so I built a "Smart Meter" for LLMs User Avatar 19 comments