Forem: Jules

SaaS Churn Rate: How to Calculate It, What It Means, and How to Fix It (+ Free Calculator)

Jules — Fri, 24 Apr 2026 10:50:55 +0000

Churn is the metric that quietly destroys SaaS businesses. You can be growing 15% month-over-month and still be dying if your churn rate is high enough. Yet most founders either don't track it properly, don't know what a "good" rate looks like, or don't connect it to the right levers.

This guide covers the formula, the different types of churn you need to track, what the benchmarks actually say, and how to diagnose the root causes when your numbers are off.

What Is Churn Rate?

Churn rate is the percentage of customers (or revenue) you lose over a given period. It's the opposite of retention. If you have 200 customers at the start of the month and lose 6, your monthly customer churn rate is 3%.

Simple concept. Devastating in practice.

The Two Types of Churn You Need to Track

Most founders only track one. You need both.

Customer churn rate — the percentage of customers who cancelled in a period.

Revenue churn rate — the percentage of MRR lost from existing customers (due to cancellations and downgrades).

They tell different stories. If your highest-value customers are churning while lower-tier ones stay, your customer churn looks fine but your revenue churn is bad. Always track both. Revenue churn is usually the more important signal.

The Churn Rate Formula

Customer Churn Rate = (Customers Lost in Period ÷ Customers at Start of Period) × 100
Revenue Churn Rate = (MRR Lost from Cancellations + MRR Lost from Downgrades) ÷ MRR at Start of Period × 100

Example: You start the month with $8,000 MRR. Two customers cancel ($400 total MRR) and one customer downgrades from $199 to $49/month (-$150). Your revenue churn = ($400 + $150) ÷ $8,000 = 6.875%.

That's not a typo. 6.875% monthly revenue churn is a serious problem.

Net Revenue Retention: The Number That Actually Matters

Once you understand churn, the next metric is Net Revenue Retention (NRR). It factors in both losses (churn, downgrades) and gains (expansions, upgrades) from your existing customer base.

NRR = (Starting MRR + Expansion MRR − Contraction MRR − Churned MRR) ÷ Starting MRR × 100

NRR above 100% means your existing customers are growing in value faster than you're losing them. The best SaaS companies run at 120–140%+ NRR.

What's a Good Churn Rate for SaaS?

Monthly Revenue Churn	Benchmark
Under 1%	World-class
1–2%	Healthy
2–5%	Acceptable early stage
Above 5%	Serious problem

One important nuance: self-serve, low-price-point products ($10–49/month) will naturally have higher churn than enterprise products ($500+/month).

The Math That Should Scare You

High churn rates compound brutally. Here's what different monthly churn rates mean for customer retention over 12 months:

1% monthly churn → 88.6% of customers retained after 12 months
3% monthly churn → 69.4% retained after 12 months
5% monthly churn → 54% retained after 12 months
10% monthly churn → 28.2% retained after 12 months

At 10% monthly churn, you're replacing nearly three-quarters of your customer base every year just to stay flat. That's a treadmill.

Why Customers Churn: The Root Causes

Onboarding failure — The customer signed up but never got value. This is the most common cause for self-serve tools, and it happens in the first 7–14 days.

Poor product-market fit — The customer's real problem wasn't the one your product solves. No amount of retention tactics fixes this.

Price sensitivity — The value delivered doesn't justify the price at the customer's current scale. This often appears as plan downgrades before full cancellation.

Competitive loss — A competitor offered something meaningful you don't.

Involuntary churn — Failed payments. Card expired, payment declined, no dunning emails. Often accounts for 20–40% of total churn in early-stage products.

How to Reduce Churn

Fix involuntary churn first — Enable Stripe's Smart Retries and set up dunning emails. This is the easiest churn to recover and most founders leave it broken.

Run exit surveys on every cancellation — Even a simple one-question cancellation form gives you pattern data within weeks. Stripe allows you to add cancellation surveys natively.

Improve early activation — Define your "aha moment" and optimize onboarding to get every new customer there within the first session.

Offer annual plans — Annual subscribers churn at a fraction of the rate of monthly subscribers. A 20% discount for annual payment is almost always worth it.

How to Track Your Churn Rate Properly

If you're on Stripe, calculating accurate churn requires pulling your subscription data and accounting for the timing of cancellations, trial conversions, and plan changes. A spreadsheet works but gets messy fast.

The free churn rate calculator at NoNoiseMetrics connects directly to your Stripe account, reads your subscription data session-only (nothing stored, no tracking), and calculates both customer churn and revenue churn in seconds. No spreadsheet. No $100/month dashboard.

Quick Churn Diagnostic

Before you try to fix churn, answer these four questions:

Is my revenue churn higher or lower than my customer churn? (If higher: your best customers are leaving first)
When in the customer lifecycle does most churn happen? (First 30 days = onboarding problem; months 3–6 = value delivery problem)
What percentage of my churn is involuntary (failed payments)?
Do churned customers come back? (Reactivation rate tells you whether the product has latent value)

The Bottom Line

Churn is not a problem you solve once. It's a number you track every month and use to diagnose the health of your product-market fit, your onboarding, and your pricing. The formula is simple. The hard part is being honest about what the number is telling you.

Calculate your actual churn rate now — directly from Stripe, no spreadsheet needed: free churn rate calculator

Originally published on Medium.

What is MRR and How to Calculate It (+ Free MRR Calculator for Indie SaaS Founders)

Jules — Fri, 24 Apr 2026 08:12:34 +0000

Monthly Recurring Revenue is the one number that tells you whether your SaaS business is growing, stagnating, or quietly dying. But most early-stage founders either calculate it wrong, read it wrong, or both.

This guide covers the formula, the edge cases that trip people up, and why MRR alone can mislead you if you're not careful.

What is MRR?

MRR (Monthly Recurring Revenue) is the predictable revenue your SaaS generates every month from active subscriptions. It's not total revenue — it specifically captures the recurring component, normalized to a monthly figure.

If you have 50 customers paying $49/month, your MRR is $2,450. Simple. But it gets complicated fast.

The Basic MRR Formula

MRR = Number of active customers × Average revenue per customer per month

If you have one pricing tier, this is trivial. Most real products don't.

How to Calculate MRR When You Have Multiple Plans

Let's say you have three tiers:

Free: 200 users at $0/month → $0 MRR
Indie: 80 users at $19/month → $1,520 MRR
Pro: 22 users at $49/month → $1,078 MRR

Total MRR = $2,598

Free users don't count. Ever. MRR only includes paying customers.

The Annual Plan Trap

This is where most founders get it wrong.

If a customer pays $468 upfront for an annual plan (equivalent to $39/month), you did NOT just add $468 to your MRR. You added $39.

Wrong: MRR += $468
Right: MRR += $468 ÷ 12 = $39

Why does this matter? If you count the full annual amount in month one, your MRR spikes artificially — then flatlines for 11 months even if you're growing. Always normalize annual and quarterly plans to monthly equivalents.

The 5 Components of MRR Movement

Every month, your MRR moves because of five things:

New MRR — Revenue from brand new customers this month
Expansion MRR — Revenue from existing customers who upgraded
Contraction MRR — Revenue lost from customers who downgraded
Churned MRR — Revenue lost from customers who cancelled entirely
Reactivation MRR — Revenue from previously churned customers who came back

Net New MRR = New MRR + Expansion MRR − Contraction MRR − Churned MRR + Reactivation MRR

Two products can have identical MRR growth rates but completely different health profiles. A product growing 10% MoM because it acquires tons of new customers while churning most of them is a leaky bucket. A product growing 10% MoM because existing customers expand is a compounding machine.

MRR vs ARR: When to Use Which

ARR (Annual Recurring Revenue) = MRR × 12

Use ARR when talking to investors, comparing to industry benchmarks, or planning annual resources. Use MRR when monitoring month-to-month health, calculating churn, or tracking early-stage growth velocity. At under $1M ARR, MRR gives you more useful signal.

What's a "Good" MRR Growth Rate for Indie SaaS?

Stage	MRR	Target MoM Growth
Pre-traction	$0–$1K	Anything positive
Early	$1K–$10K	15–25%
Growing	$10K–$50K	10–20%
Scaling	$50K+	5–15%

A product growing 8% MoM consistently from $10K MRR will reach $100K MRR in about 2.5 years. That's a real business. Your own trend line matters more than external benchmarks.

Common MRR Calculation Mistakes

1. Including one-time payments — Setup fees, consulting, lifetime deals are not MRR. They inflate your number and make growth look better than it is.

2. Counting trials as MRR — A user on a free trial has not generated MRR. Count them only when they convert to a paid plan.

3. Not accounting for failed payments — If a payment fails and you're in grace period, they shouldn't be in your MRR. Count collected revenue, not billed revenue.

4. Using "cash collected" instead of "normalized recurring" — In a month where you sell 20 annual plans, your cash collected might be 5× your actual MRR. Different numbers, different purposes.

5. Ignoring expansion and contraction — Watching only total MRR hides whether you're growing healthily or papering over churn with acquisition.

MRR and Churn: The Number That Changes Everything

MRR without churn context is almost meaningless.

A company at $10K MRR with 15% monthly churn is bleeding out. In 6 months they'll need to replace most of their customer base just to stay flat. A company at $10K MRR with 1% monthly churn is compounding quietly.

Revenue Churn Rate = Churned MRR ÷ MRR at Start of Period × 100

Benchmarks: Under 2% monthly revenue churn = healthy. Under 0.5% = exceptional. Above 5% = fix retention before you think about scaling.

How to Calculate Your MRR Right Now (Without a Spreadsheet)

If you're on Stripe and want your actual MRR without paying $100/month for a dashboard, the free MRR calculator at NoNoiseMetrics reads directly from your Stripe data, session-only (nothing stored, no tracking), and gives you MRR broken down by plan in seconds. No signup. No credit card. No storage.

Quick MRR Sanity Check

Before you trust any MRR number, confirm:

Have I excluded all one-time payments?
Have I normalized annual/quarterly plans to monthly?
Have I excluded users in failed payment / grace period states?
Am I counting only active paying customers?

Four yeses = your number is trustworthy.

The Bottom Line

MRR is the foundation metric for every SaaS business. Get it right from day one. The formula is simple — the execution details are where founders make expensive mistakes.

If you want to skip the spreadsheet and see your real MRR directly from Stripe — broken down by plan, no setup, no storage, no monthly fee — the free MRR calculator is here.

Originally published on Medium.

Stripe's 2026 Annual Letter: 5 Signals That Actually Matter for Indie SaaS Founders

Jules — Thu, 23 Apr 2026 07:44:36 +0000

Every year, Stripe publishes an annual letter. Most of the coverage focuses on the enterprise numbers — payment volume, new markets, financial infrastructure ambitions. That's fine. But if you're a solo founder or small team building on Stripe, the interesting signals are buried three layers down. Here's what I actually took away from the 2026 letter.

Signal 1: The 2025 startup cohort grew 50% faster — and that changes how you should read your own numbers

Stripe's data shows the 2025 startup cohort growing roughly 50% faster than 2024. Companies reaching $10M ARR within 3 months of launch doubled year-over-year. That's remarkable — but it also means the benchmarks you've been using to evaluate your own growth are shifting underneath you. "Healthy" churn rates, typical CAC payback periods, normal MoM growth for early-stage SaaS — these are all anchored to a different era. If your $2K MRR product grew 8% last month, is that good? Compared to what cohort, on what baseline? The letter doesn't answer that for small founders. It just makes the question more urgent.

Signal 2: Stripe is buying the entire revenue stack — and that widens the gap for indie founders

The letter buries this, but it's significant: Stripe's Revenue Suite — billing, subscriptions, usage-based billing via the Metronome acquisition — is on track to hit $1B ARR. Stripe no longer wants to be just a payment processor. It wants to own invoicing, metering, and analytics. For indie founders, this is a clarification, not a threat: Stripe's built-in tools will keep improving, but they'll also keep moving upmarket. More complex, more enterprise-focused, more expensive to unlock. The gap between what Stripe shows you natively and what you actually need to understand your business isn't closing. It's moving.

Signal 3: Usage-based billing is becoming the default — and it makes your MRR harder to read

Metronome — which powers billing for OpenAI, Anthropic, and NVIDIA — is now part of Stripe. Usage-based billing is going mainstream fast. If you're building anything AI-adjacent, or even just considering a consumption pricing model, your MRR will become much harder to read. A flat line in your dashboard might hide massive variance in actual usage patterns. Month-over-month comparisons lose meaning when pricing is metered. You need to understand what's driving revenue at the session level, not just top-line MRR. Most analytics tools weren't built for this shift.

Signal 4: Atlas formations up 41% — more founders are shipping faster than ever

20% of Atlas startups charged their first customer within 30 days of incorporation — up from just 8% in 2020. More solo founders are getting to revenue faster than ever. That's great for the ecosystem. But it also means tools that help early-stage founders understand their metrics without enterprise pricing are more needed than ever. When you're at $500 MRR, you genuinely can't justify $100/month for a dashboard. But you still need to know if you're growing, what your churn rate actually is, and which customers are worth keeping.

Signal 5: Software drove ~46% of all US GDP growth in 2025 — but the market is bifurcating hard

Stripe's analysis shows that software, computers, and data center investment drove nearly 46% of all US GDP growth in 2025. The top 10% of S&P 500 companies now account for roughly 59% of total index profits — the highest concentration on record. Brick-and-mortar retail grew just 5% over three years; ecommerce grew 30%. The same split is happening inside SaaS. Winners are pulling away. The difference between a business that compounds and one that flatlines is often just visibility — knowing your real numbers early enough to act on them.

What Signals 2 and 4 pushed me to think about is analytics at the indie scale. Baremetrics starts at $108/month. ChartMogul at $100/month. That pricing made sense when your only customers were Series A startups. It makes no sense when 20% of new Atlas companies charge their first customer within 30 days of incorporating. I've been building NoNoiseMetrics for exactly this gap — a lightweight Stripe analytics tool that reads your data session-only (no storage, no third-party tracking, fully GDPR-compliant) and shows you MRR, churn, LTV, and customer-level detail without a $100/month subscription.

Stripe's letter is optimistic about infrastructure. As a founder, your job is to make sure you can actually see your own business clearly — at whatever stage you're at. The infrastructure is there. The visibility layer is still missing for most indie builders.

Originally published on Medium.

I Built a SaaS Analytics Tool That Stores Zero Customer Data: Here's the Architecture

Jules — Sat, 18 Apr 2026 13:45:51 +0000

Article

Most SaaS analytics tools work the same way: connect your payment provider, we ingest your data, store it in our database, and show you dashboards. Simple, proven, and... a privacy nightmare.

When I built NoNoiseMetrics, I went a different route. Session-only architecture: your Stripe data is fetched, processed, and displayed in real time — then discarded. Nothing is persisted on our servers. Ever.

Here's why, and how it works.

The Problem with Traditional Analytics Pipelines

Tools like ChartMogul and Baremetrics follow the same pattern:

Stripe API → ETL → PostgreSQL → Dashboard

Your raw financial data — every invoice, every customer, every charge — lives on someone else's server, indefinitely. For bootstrapped SaaS founders, that creates three issues:

GDPR compliance becomes your problem AND theirs
Data breach surface area doubles
Trust is harder to build when you're asking for full Stripe access

The Session-Only Alternative

NoNoiseMetrics flips the pipeline:

Stripe API (read-only key) → Real-time processing → Browser render → Session ends → Data gone

Here's what happens under the hood:

User connects a restricted Stripe API key (read-only — we can't modify anything)
On each session, we call the Stripe API to pull the relevant objects: subscriptions, invoices, charges, customers
Metrics are computed server-side in memory: MRR waterfall, churn cohorts, NRR, LTV
Results are sent to the frontend and rendered
When the session ends, nothing is retained

No database stores your financial data. No background sync. No data warehouse.

The Tradeoffs (Being Honest)

This architecture isn't free lunch:

	Traditional (ChartMogul/Baremetrics)	Session-only (NNM)
Historical data	Pre-computed, instant	Fetched each session
Dashboard load time	~1s	~3-8s (depends on Stripe data volume)
Offline access	Yes	No
Data stored on 3rd party	Yes, all of it	None
GDPR surface	Shared responsibility	Minimal — session data only
Background alerts	Yes	Not yet

For indie hackers tracking MRR under $100K, the tradeoff is worth it. You get your metrics without handing over your financial data to yet another SaaS.

The Stack

For anyone curious about the infrastructure:

Frontend: React, deployed on Vercel
Backend: Node.js on Railway
Auth & minimal state: Supabase (user accounts only — no Stripe data)
Payments: Stripe (yes, we use Stripe to analyze Stripe)
Blog/SEO: Astro (separate from the React SPA)

Monthly infrastructure cost: under $50.

Key Metric Computations

Here's a simplified version of how I compute MRR breakdown from raw Stripe data:

function computeMRRWaterfall(subscriptions, period) {
  const waterfall = {
    newMRR: 0,
    expansionMRR: 0,
    contractionMRR: 0,
    churnedMRR: 0,
  };

  for (const sub of subscriptions) {
    const current = getMRRForPeriod(sub, period);
    const previous = getMRRForPeriod(sub, previousPeriod(period));

    if (previous === 0 && current > 0) {
      waterfall.newMRR += current;
    } else if (current > previous) {
      waterfall.expansionMRR += (current - previous);
    } else if (current < previous && current > 0) {
      waterfall.contractionMRR += (previous - current);
    } else if (current === 0 && previous > 0) {
      waterfall.churnedMRR += previous;
    }
  }

  return waterfall;
}

The real implementation handles edge cases (prorations, trials, multi-currency), but the core logic stays straightforward.

Why This Matters for Indie Hackers

If you're a bootstrapped founder, you probably care about three things:

MRR growth — is the trend going up?
Churn — who's leaving and why?
NRR — are existing customers growing?

You don't need a data warehouse for this. You need a clean dashboard that tells you the truth and doesn't store your financial data on servers you don't control.

That's what I built with NoNoiseMetrics. It's free to start, and your data stays yours.

If you want to dig deeper into Stripe analytics, I wrote a full guide on what Stripe's native dashboard misses and how to fill the gaps.

What's your approach to SaaS analytics? Do you care about where your financial data lives, or is it a non-issue? Curious to hear.``

I Built a Stripe Analytics Dashboard That Never keep Your Data: Here's the Architecture Behind It

Jules — Wed, 18 Mar 2026 20:48:48 +0000

For months, I tracked my SaaS metrics from Stripe in a spreadsheet.

Every month I'd export CSVs from Stripe, paste them into Google Sheets, and manually calculate MRR, churn, and net revenue retention. The formulas kept breaking. The numbers never matched what Stripe showed. And every month I told myself I'd automate it next time.

I looked at the existing tools. ChartMogul, Baremetrics, ProfitWell. They all do the job. But they all share one architectural decision that bothered me:
They copy your entire Stripe billing history onto their servers.

Every customer name, every payment amount, every subscription change, every refund — duplicated and stored indefinitely on infrastructure you don't control.

As a solo founder running a small SaaS on Stripe, giving a third-party tool permanent access to my most sensitive business data felt like a bigger trade-off than it needed to be.

So I built NoNoiseMetrics, and I made a different architectural choice.

The Core Idea: Session-Only Data
The central constraint I set for myself was simple:

Raw Stripe data should exist on my servers only while the user is actively looking at it.

When you connect NoNoiseMetrics to Stripe, here's what happens:

OAuth with read-only scope. You authorize via Stripe's OAuth flow with restricted permissions. NoNoiseMetrics can read subscription and payment data. It cannot create charges, modify subscriptions, issue refunds, or access bank account details.

Session-scoped data fetching. During your active session, the app calls the Stripe API, pulls the relevant objects (subscriptions, invoices, charges), and computes your metrics in real time.

Aggregates stored, raw data wiped. When your session ends, raw Stripe objects are discarded. Only computed metrics (MRR value, churn percentage, NRR, etc.) are persisted for historical tracking.

One-click disconnect. Revoke access anytime from your Stripe dashboard. There's nothing to export, nothing to migrate, nothing left behind.

This isn't a privacy policy. It's the architecture.

Why This Was Harder Than It Sounds

The obvious downside of not storing raw data is that you can't query it later. Every analytics tool in this space keeps a full copy specifically because it makes everything easier: historical recalculations, cohort comparisons, retroactive metric changes.

I had to solve several problems differently.

Problem 1: Historical Metrics Without Historical Data If I don't store raw Stripe objects, how do I show MRR trends over the past 6 months?

The answer: compute and snapshot on each session. Every time a user logs in, NoNoiseMetrics calculates the current state of all metrics and stores the computed values with a timestamp. Over time, these snapshots build up a historical series.

The trade-off is real. If a user doesn't log in for two months, there's a gap in their trend line. I decided that's acceptable for the target audience — indie hackers and solopreneurs who check their metrics at least weekly.

For the first session (when there's no history yet), the app does a deeper Stripe API pull to backfill key metrics from available invoice and subscription data, computes the aggregates, and then discards the raw objects.

Problem 2: Multi-Account Aggregation A surprising number of bootstrapped founders run 2–3 Stripe accounts (one per product). They want to see combined MRR across all of them.

This meant the session layer had to handle multiple concurrent Stripe API connections, normalize the data into a common schema, compute unified metrics, and then discard all raw data from every account when the session ends.

The key abstraction here was a StripeAccountContext that wraps each connected account's API calls and exposes a normalized interface. The aggregation layer doesn't care which account a subscription came from — it works with the normalized shape.

interface NormalizedSubscription {
id: string;
accountId: string;
status: SubscriptionStatus;
currency: string;
mrrCents: number;
startedAt: Date;
canceledAt: Date | null;
interval: "month" | "year";
}

Keeping this interface tight made it possible to write the metric calculation logic once and have it work across single and multi-account setups.

Problem 3: Stripe API Rate Limits Stripe's API has rate limits (25 read requests/second in live mode for most accounts). When computing metrics for an account with thousands of subscriptions, you can't just fire off requests in parallel and hope for the best.

I implemented a simple token-bucket rate limiter that sits in front of all Stripe API calls. It's not sophisticated — just a counter with a refill interval — but it prevents 429 errors and keeps the session-scoped fetch reliable.

class RateLimiter {
private tokens: number;
private maxTokens: number;
private refillRate: number;
private lastRefill: number;

async acquire(): Promise {
this.refill();
if (this.tokens <= 0) {
const waitTime = (1 / this.refillRate) * 1000;
await new Promise((r) => setTimeout(r, waitTime));
this.refill();
}
this.tokens--;
}

private refill(): void {
const now = Date.now();
const elapsed = (now - this.lastRefill) / 1000;
this.tokens = Math.min(this.maxTokens, this.tokens + elapsed * this.refillRate);
this.lastRefill = now;
}
}

Nothing fancy. But it was one of those things where getting it wrong would silently break the entire user experience.

The Metric Calculations

The metrics themselves are less trivial than they look. MRR sounds simple until you deal with:

Annual subscriptions that need to be normalized to monthly
Multi-currency accounts (a founder in Europe with USD and EUR customers)
Prorations from mid-cycle plan changes
Trial periods that shouldn't count as active MRR
Paused subscriptions that Stripe still reports as active

Each edge case is a small if branch that's easy to get wrong. I chose to handle these explicitly rather than building an abstract "subscription normalizer" — similar to the reasoning in this post about not over-abstracting scheduling algorithms. When the logic itself is the product, keeping it readable matters more than keeping it DRY.

MRR waterfall breakdown (new, expansion, contraction, churn, reactivation) was the trickiest piece. It requires comparing the current state of every subscription against its state in the previous period, classifying the delta, and summing by category. Getting this right took more iterations than any other part of the codebase.

Tech Stack

Frontend: React on Next.js, deployed on Vercel
Backend: Node.js on Railway
Database: Supabase (EU region — important for GDPR)
Payments: Stripe
Email automation: Loops.so
Styling: Tailwind CSS
Validation: Zod

Why This Stack
I'm a solo founder. Budget is close to zero while the product finds its market. Every choice was driven by "what can I ship and maintain alone without going broke?"

Vercel + Railway gives me separate scaling for frontend and backend without managing infrastructure.
Supabase is Postgres with auth and real-time features I might need later, and hosting in EU keeps GDPR simple.
Zod for runtime validation of Stripe API responses was a decision I'm particularly glad I made early. Stripe's API is well-typed, but parsing real-world webhook payloads and API responses revealed enough edge cases that having a validation layer caught bugs I wouldn't have found otherwise.

What I Didn't Build (On Purpose) One of the hardest parts of building a product alone is deciding what to leave out.

NoNoiseMetrics doesn't have:

A CRM. ChartMogul has one. My users don't need one inside their analytics tool.
Dunning / failed payment recovery. Baremetrics charges $129/mo extra for this. It's a separate product category.
Cancellation surveys. Same logic. Useful, but out of scope.
47 chart types. The dashboard shows 8 core metrics. MRR, ARR, churn (revenue + customer), NRR, ARPU, LTV, and cohort analysis. That covers what a bootstrapped founder should check weekly.

Every feature I didn't build is one less thing to maintain, one less surface area for bugs, and one less reason for the interface to feel overwhelming.
The indie hackers I talk to don't want a "powerful analytics platform." They want to connect Stripe, see their numbers, and get back to building their product.

What I Actually Learned

Stripe's API is excellent but deep
The documentation is some of the best in the industry. But the object model is more complex than it looks from the outside. A single subscription can have multiple items, each with different prices, coupons, tax rates, and billing anchors. Getting metric calculations right required reading the Stripe docs more carefully than I've read almost any technical documentation.
Session-only architecture forces better engineering
When you can't fall back on "just query the database," you're forced to think carefully about what you compute, when you compute it, and what you persist. It's a constraint that made the codebase simpler, not more complex.
The privacy angle resonates more than expected
-When I explain the architecture to other founders, the most common reaction is: "Wait, the other tools store all my data?" Most people don't read the fine print. Knowing that your financial data is never copied to a third-party server is a relief that's hard to quantify but easy to feel.

Solo founder ≠ no feedback loop

I can't afford a QA team, but I can afford to be obsessive about Zod validation, TypeScript strict mode, and testing metric calculations against known Stripe test data. The type system is the cheapest co-worker you'll ever have.

Try It

If you're running a SaaS on Stripe and you want clean metrics without handing over your billing data:
🔗 Nonoisemetrics

Free up to €10K MRR. €19/mo after that.

What's Next

AI-powered weekly digest (plain-language summary of what changed in your metrics — delivered via email, no data stored)
Improved first-session backfill for faster time-to-insight
Public blog with SaaS metric guides (MRR, churn, NRR explainers)
Automated tests for every metric calculation against Stripe's test clock

If you have questions about the architecture, the Stripe API edge cases, or building a SaaS analytics tool as a solo founder, happy to discuss in the comments.

The best side projects are the ones where the constraint teaches you more than the feature set.