132 users, 3 current customers, and a renewal failure I should have prevented

The gap between "active usage" and "buying intent" is brutal, and you nailed the diagnosis. At Pick an Agency, we see this constantly: people kicking the tires hard but never crossing into paid. One thing that shifted for us was treating signup flow as a learning moment, not a funnel stage. When someone completes advanced setup without converting, that's signal, they're either evaluating competitors, validating a workflow, or testing something specific. Ask them directly in an onboarding email what they're deciding between. That one question turned our "active but broke" cohort into legible feedback about what's actually missing.

"A renewal failure I should have prevented" — that line is basically the whole reason I'm heads-down on retention right now. Your point that deep setup activity isn't buying intent matches what I keep seeing too: intent shows up at the billing moment, not in the usage graph. Genuinely curious about that non-renewal — was it a payment/card failure you could've caught and retried, or a real "don't want it anymore" churn? I'm trying to work out how much early churn is actually recoverable vs. not, and founders who've lived it are the only real source.

The renewal bug lesson generalizes: after 20 years running an MSP I came to treat billing as retention infrastructure, not back office, because every failed charge or missed reminder is a churn event you caused. The tactical fix is a dunning sequence plus an alert on any failed renewal event, built before you have enough customers to notice the pattern. Separating cash collected from normalized MRR this early also puts you ahead of most founders who pitch me.

The churn story is the hard-won wisdom here. A lot of makers celebrate the first sale but miss that retention is the real metric.

A question: what's the ratio you're aiming for? (Like, do you know what % of users need to convert for the math to work?) And have you mapped when users typically decide to churn? (Day 5? Week 2? Month 1?)

For paid one-time purchases especially, understanding why someone says "no" on day 1 vs. day 7 changes everything about how you position the product.

Thanks for sharing such an honest and transparent update. The lessons you highlighted here are absolute gold.

I’m currently facing a very similar "free utility trap" with my SaaS, qrbrand (a custom branded QR code generator). Since we allow users to generate QR codes as guests without forcing them to register, we see active traffic but zero conversion.

Looking at our Google Analytics funnel for the last 30 days, we had 60 active users and hundreds of events, but a brutal 100% abandonment rate when it comes to the signup/purchase step. People just want a quick free utility, download their code, and bounce. It’s a constant battle trying to bridge the gap between "free active usage" and "willingness to pay."

As for the renewal bug: that is incredibly frustrating because it leaves you in that uncomfortable zone of not knowing. If you haven't yet, try sending them a personal email. A simple, "Hey, we noticed our renewal notification failed, just wanted to check if you wanted to keep using the tool or if it wasn't providing enough value" can be a great way to either win them back or get the definitive feedback you need.

Keep pushing. 42 million uptime checks is a massive operational milestone!

The renewal email bug is the expensive kind of failure: you lost the data, not just the customer. I ran an MSP for 20 years and we learned to treat billing and renewal flows like production infrastructure, because a silent failure there corrupts your churn signal forever. Your instinct to separate MRR from cash collected is right, most founders at this stage do the opposite.

Really appreciate the honest update, Nikola. This is the kind of transparent building in public that helps the rest of us the most.
The distinction between heavy usage and actual buying intent is such a painful but important lesson. And that renewal email bug hitting your very first monthly customer… oof. The fact that it contaminated your churn signal is such a sharp observation — "noisy churn" is a perfect way to put it.
Congrats on getting to real revenue and real operational responsibilities so quickly. StatusPage.me is clearly past the idea stage now.
Are you planning to reach out personally to the most active free users who haven’t converted yet? Curious to hear how that goes.
Keep going — rooting for you!

i like how you stayed consistent even though it took you months to get your first paying customer. and you are right, understanding your customer needs is a great way to understand what might be causing friction , why some customers stay and why some leave.

The fact that you're tracking this at all puts you ahead of most people at your stage. Most founders don't even notice a churned customer until months later. The renewal failure is useful data though, not just a loss. Did the customer ever respond to any outreach after the failed payment? The gap between "forgot to update card" and "decided to cancel" is everything for figuring out what to build next. At your stage with 132 users and 3 paying, your real question isn't retention yet. It's activation. You've got 128 people who signed up and didn't pay. That's where the leverage is. What's the gap between what free users see and what would make them reach for their wallet?

Hey Nikola — small update: CancelKit (the thing I mentioned above) is finishing up billing setup this week, and I'm opening a few early access spots to indie SaaS founders before public launch — free during beta, plus a lifetime discount for the first 10. Given the renewal story above, thought you might want first pick. Happy to send more details if you're interested.

This is a really honest breakdown, especially the churn/billing-bug tangle. "I cannot cleanly separate product churn from billing-flow failure" is the part that actually costs founders, not the churn itself. I built FounderFlow (AI chief of staff for founders running more than one business) partly because of this exact failure mode, a renewal reminder silently failing sits in a dashboard nobody's watching that day. Have you added a daily check specifically for billing/webhook failures since, or still manual?

Nikola, this resonated.

I'm building a vertical SaaS too, and I've learned that activation matters more than signups. I've had people discover us organically, create an account, and then... do nothing. No data, no setup, no "aha" moment.

What changed my thinking was realizing people don't buy software—they buy relief from a specific problem. In my case, compliance tools generate far more engagement than "property management software" ever did because they solve an immediate need.

At this stage, every customer is valuable enough to onboard personally.

Did the customer come back after you reached out, or was the renewal failure just the final step in an already-fading relationship?

The renewal email bug is one failure, but there's a second layer under it worth checking too. Stripe's own subscription status already distinguishes past_due from canceled from unpaid, a card that's mid-retry looks completely different from a customer who actually walked away, and that distinction exists in the webhook data whether or not your reminder email ever sends.

If the app only tracks "did they renew by date X," all three of those get flattened into one bucket, and you end up rebuilding by hand a signal Stripe already handed you. Worth checking whether the churn number is reading subscription.updated status transitions directly, or just inferring from an email that may or may not have gone out.

One thing I would add is a renewal evidence trail before trying to interpret churn. For each paid account, I would want to see: reminder sent, webhook received, payment attempt result, customer-facing email delivered/opened if available, and whether the product stayed in a grace state. If any of those are missing, the churn reason is contaminated.

At your current size, I would not over-automate the analysis yet. For the 20-30 users who did meaningful setup, manually tag the first moment they trusted the product (custom domain, public status page, teammate invite) and the first moment they hit uncertainty (pricing, limits, reliability, setup friction). That will probably teach more than aggregate conversion math right now.

The strongest line in the post is that operational correctness becomes part of the product. For monitoring/status-page tools, that is especially true: users are buying confidence that the boring failure cases will behave predictably.

Treating the renewal flow as production-critical instead of back-office plumbing is the right lesson to pull from that, a silent reminder-email bug is brutal because it looks exactly like churn. The part I'd sit with: at 3 paying customers, even once the billing is airtight, can you actually read any signal yet on what makes someone convert, or is it still too few to separate a real pattern from noise?

Nikola, this resonated.

I'm building vertical SaaS as well, and one thing I've learned is that activation matters more than signups. I've had users find us organically, create an account, and then never add any data.

The product wasn't the problem—they never reached the "aha" moment.

At this stage I'm treating every new user like an enterprise customer. Manual onboarding is cheaper than losing someone before they've experienced value.

Did your customer return after you reached out, or was the failed renewal just the final step in an already-fading relationship?

"作为一个刚开始做 side project 的设计师,读你这个 renewal failure 的教训帮我看到一个自己完全没想过的问题 —— 我甚至还没到收 customer 那一步。我想问的是:你在 renewal 之前有没有做任何 usage-based touchpoint(比如用户接近额度时的邮件)?还是完全依赖 auto-charge?"

The point about renewal infrastructure needing to be reliable enough that a churn signal can actually be trusted is one of the most underrated lessons in early SaaS. A lot of founders conflate "no one clicked renew" with "the product wasn't valuable enough," when the truth is sometimes buried in a broken webhook or a silently-failing email, exactly like what happened to you. One thing that's helped us separate the two is adding a human-triggered failsafe (a Slack alert or dashboard flag) whenever a renewal reminder job fails to send, so you catch it within hours instead of discovering it after the subscription has lapsed and the customer has gone quiet. Your point on activity vs. buying intent also rings true from our experience: setup depth correlated much better with retention after purchase than with likelihood to purchase, so we stopped using it as a lead score entirely. Have you tried reaching out directly to the users who did deep setup (multiple status pages, custom domains, invited teammates) but never converted, and if so, was there a common theme in why they stalled, or is it scattered across price, timing, and trust?

The renewal reminder bug mixing in with your churn signal is exactly the kind of thing I built FounderFlow around (I'm the founder, mentioning since it's directly relevant here). The failure that actually gets you usually isn't a customer saying no, it's a follow-up that quietly never went out, and you don't find out until it's too late to tell "they left" apart from "we dropped the ball." I've started treating anything time sensitive, renewal reminders, follow-ups after a big setup session, as needing a second independent check that it actually happened, not just that the job ran. Cheap insurance against exactly the spot you're in now.

Point 4 is the one most founders learn too late: every avoidable operational failure contaminates your data about why customers leave. At SocialPost.ai we treat billing and renewal flows as part of the product for exactly this reason. Separating "they chose to leave" from "we fumbled the handoff" is worth more than any new feature this quarter.

the renewal-reminder bug is the sharpest thing in here, and i'd frame it harder than 'ordinary churn.' a reminder that silently doesn't fire is the same failure class as a payment webhook that half-processes: the system reports a normal-looking outcome (subscription expired, user churned) while the real event, giving them the choice to renew, never happened. you didn't lose a customer, you lost the event that would have kept them, and the dashboard filed it under churn. those are the ones that hide for months because nothing errors.

the habit that's saved me is treating anything meant to fire on a schedule as guilty until proven sent: log the intent, then reconcile a day later against what actually left the outbox, and alert on the gap. the reminder not firing should have paged you, not shown up as a stat.

and strong agree on separating cash from MRR. annual and lifetime flatter the headline and bury the one number that tells you what to fix. the less flattering number is almost always the honest one.

This hit close to home. We're even earlier — 10 downloads, 0 paying customers — so I'm reading every line of this carefully.
The part about "usage, buying intent, and willingness to pay are three different things" is something I'm only starting to understand. We've had people download TankSync (an aquarium parameter tracking app my family built), but no way to tell yet whether they tried it and bounced, or just never opened it.
Your point about the renewal bug contaminating the churn signal is the kind of thing I wouldn't have thought to worry about at this stage — but now I will. Thanks for publishing the real numbers instead of the flattering ones.

With a sample this small, I'd stop looking for one conversion rate and trace five individual accounts instead: one that published a page, one that connected a domain, one that invited a teammate, one that hit a paid feature, and the customer who did not renew. Rebuild each path from first value to last action, then interview only where the trail goes quiet. You'll probably find five different jobs instead of one "2% conversion" problem.

What part of your approval process takes the most time? Trying to understand if this is a universal pain.

mind blowing, scaling is often the main challenge over here, effective delivery is yet another. All the best!

The cleanest test here might be to tag each active user by the moment they first create external dependency, not just setup depth. For a status page that could be custom domain live, public page shared, teammate invited, or monitor connected to something they would be embarrassed to have fail. Those are different from “configured a lot,” because they create social or operational consequence. I’d compare conversion and churn around that line before adding more features.

The part that would keep me up isn't the lost renewal, it's you saying "now I cannot cleanly separate product churn from billing-flow failure." That one missed reminder didn't just cost you a subscriber, it put a weird asterisk on every retention read from this whole cohort.

I've been buried in exactly this on the failed-payments side, and what surprised me most is how invisible it is by default. A renewal reminder that silently doesn't send, and a card that expires at renewal and quietly hard-declines, look identical from the dashboard, the number just doesn't show up. You only caught yours because you went digging, which most founders never do.

The cheap fix that separates the two buckets going forward is to log every step of the renewal path as its own event: reminder queued, reminder sent, charge attempted, decline code returned. Next time a renewal doesn't happen, the timeline tells you whether it was a billing-flow bug or a real goodbye before you have to guess.

Did the customer ever reply after you sent the direct checkout link, or just go quiet? That answer alone usually tells you which bucket it really was.

Point 1 is the one that stings. I read deep setup activity as buying intent too — until a customer who used everything churned because the product didn't map to a pain they felt daily. Usage told me they understood it, not that they needed it. And point 4 is somehow worse than churn: "we don't need this" is at least clean signal. A billing bug that muddies the reason robs you of the one useful thing a lost customer gives you — a straight answer. Fixing renewal infra first is the right call.

This point about product activity vs. buying intent really resonates. I just shipped a consumer iOS app and I'm seeing a version of the same thing on the free-to-paid side: people who swipe through hundreds of photos in one session look like power users, but plenty of them are just testing the free tier's daily limit rather than genuinely converting later. Deep usage and willingness to pay turned out to be two different signals for me too, even in a pretty different product category than yours. Appreciate you sharing the raw numbers — not many people are this transparent about the behavior shift after the first payment.

The part that will bite you again is the "cannot cleanly separate product churn from billing-flow failure" problem, not just this one customer's renewal. I'd treat "renewal reminder failed to send silently" as a P0 regardless of whether this specific customer comes back, because if it happened once without you noticing, it's almost certainly happening to a slice of users you haven't caught yet, and you won't find out until they've also gone quiet on you. On the conversion side, the fact that your two paying customers are mid-pack on setup depth rather than your heaviest users is a useful signal too - it suggests deep-setup users are comfortably self-serving on the free tier rather than hitting a real wall, which is worth instrumenting separately from the churn issue. Do you have any alerting on transactional email delivery itself (bounce/failure webhooks from your ESP), or is catching this kind of silent failure still something you find manually after the fact?

The distinction between usage and buying intent is one of the hardest lessons for early-stage founders.

It’s easy to look at active users, setups completed, and product usage as signs that revenue is coming soon. But sometimes the real challenge is not getting people to understand the product — it’s creating enough urgency for them to pay.

I also liked the point about operational reliability after the first customers arrive. Before revenue, founders often optimize for building. After revenue, the product becomes the entire experience: billing, renewals, edge cases, support, and trust.

The renewal failure is actually a valuable lesson because it shows how small operational details can directly impact retention.

Early customers teach you not only what features to build, but what kind of company you need to become.

The broken feedback loop point really hit home — not knowing if a user left because of your product or a bug is one of the most frustrating positions to be in as a founder. Your point about doubling down on fixing useful features rather than adding new ones is exactly right too. Understanding what users actually interact with most is what separates teams that build the right things from teams that build the most things. I'm actually building a tool called Featly around this exact problem — helping PMs and founders see which features their users use vs ignore, in plain English, without the complexity of PostHog. Would love your thoughts on it when it's ready.

This is a really honest breakdown of the gap between usage and willingness to pay. I especially resonated with point #4 — the renewal email bug masking real churn signals is a nightmare scenario. When infrastructure failures contaminate your retention data, you lose the ability to learn from churn at all, which is arguably worse than the churn itself. We had a similar issue on our API platform where a billing webhook silently failed for 3 days. By the time we noticed, we had lost two customers and had no idea if they left because of the bug or because they genuinely did not need the product anymore. After that, we implemented a dead-letter queue with Slack alerts for any billing event that fails to process within 5 minutes. It is not glamorous work, but as you said — once people pay you, operational correctness becomes part of the product. Out of curiosity, what are you using for your uptime monitoring stack? We are running something similar with our own status page and always looking to compare notes with other indie founders in the monitoring space.

damn, renewal failures are the worst what caused it, failed payment or just churn?

The distinction between product churn and renewal-flow failure is an important one. I’d consider logging a simple “renewal decision trail”: reminder attempted, delivered, opened, checkout visited, payment failed, or explicitly cancelled. Without that trail, churn becomes an ambiguous metric rather than useful feedback.

I’d also interview the active users who connected custom domains or invited teammates. Those actions may indicate operational dependence more reliably than general activity. Thanks for sharing the less flattering numbers — they’re much more useful than a polished MRR headline.

The distinction between usage, buying intent, and willingness to pay is something I wish more early-stage founders talked about openly.

I'm two days into early access on Ridgewell, an options coaching tool, so I don't have paying customers yet — but your point about deep setup activity not being a reliable conversion signal is already something I'm watching carefully. Had a user make it all the way through onboarding and into the scanner and still not come back. No idea if that's a product problem, a timing problem, or just someone who was curious.

Your point about operational correctness becoming part of the product after people depend on it also hit hard. Right now everything feels manageable because the user count is small. I'm trying to build the boring infrastructure now before it becomes a crisis later.

The churn situation where you can't separate product failure from billing failure is genuinely uncomfortable to read — not because it's bad, but because it's the kind of thing that looks obvious in hindsight and invisible in the moment.

Appreciate the transparency on the real MRR number vs the all-time gross. That's the kind of honesty that's actually useful.

The corrupted signal point is the right lesson, but I would push it one step further. A customer who said they intended to renew, then got a direct checkout link and a dashboard notice and still did not complete it, is telling you something even through the noise. When the value is strong, people push through far more friction than a broken auto renew. The billing failure muddied the reason, but the non completion after you fixed the path is its own quiet data point.

The practical fix that saved me elsewhere was an alert on the absence of an event, not just on failures. Fire a warning when an expected renewal does not arrive inside its window. Silent failures never page you, but a missing success will.

132 signups to 3 paying customers is brutal, and that renewal failure on top of it must sting. What happened with the renewal - was it a payment issue or did they just ghost you?

The "completed meaningful setup but did not buy" segment is probably the highest leverage list here. I'd split it into two groups before interviewing: people who created something public-facing, like a status page/custom domain, and people who only tested privately. Same activity count, very different urgency. Public exposure usually means "I need this to keep working," private testing often just means evaluation.

the honest part, that you can't cleanly separate the bug from real churn now, is the sharpest bit here. one push though: your fix (verify the customer actually got the reminder) still leaves a reminder in the critical path, and anything in the critical path eventually fails quietly. the stronger version is to not need the reminder at all. a subscription should auto-charge the card on file, so the renewal happens whether or not any email lands. then email is only for the exception: dunning. card declined or expiring, retry on a schedule, and you only ping the customer when a retry actually fails. dodopayments handles this, you just lean on it instead of your own reminder flow.

and to get the clean churn signal you're after, log the reason at the moment it happens (declined / canceled / lapsed) instead of reconstructing it later. that way an involuntary billing failure never gets filed as "they didn't want it" in the first place.

Really honest breakdown — respect that.
How do you currently handle billing
verification with your customers?

Brilliant breakdown, Nikola. The realization that deep setup activity doesn't automatically mean high buying intent is a tough pill to swallow for technical founders. It’s easy to focus on feature-building when the real battle is understanding the friction in the trial-to-paid path. Hope you get clear answers from that churned user soon!

This distinction between billing-flow failure and product churn is such an underrated problem. I'm building CancelKit specifically because of this — without an intent signal captured at the moment someone cancels, you're left reconstructing motive from indirect clues, which is exactly the trap you describe with the missed renewal email. Even a simple "why are you leaving" at cancel time would have told you decisively whether it was the bug or genuine disinterest. Really appreciate you publishing the raw numbers too — $24.65 real MRR vs. the flattering headline number is a distinction more founders should sit with.

Great transparency. It's interesting to see the difference between product usage, buying intent, and actual revenue. Wishing you continued growth—every lesson here is building a stronger product. 🚀

The renewal example is a good reminder that small operational gaps can quietly affect business decisions in ways that aren't obvious at first.

This is exactly the failure mode I've been building CancelKit around - the "I can't tell if this was a decision or a bug" problem. Once you can't cleanly separate churn signal from billing-flow failure, you lose the ability to trust your own retention data going forward, not just for that one customer.

One thing that's helped me think about it: keep the renewal reminder on its own monitored path (log every attempt fired, not just "sent" from Stripe/webhook events) so it's not entangled with your marketing email pipeline. If a renewal reminder can be blocked by the same infra as your newsletter, it'll eventually go down silently exactly like this did.

Congrats on the first paying customers, by the way - $24.65 MRR looks tiny written down, but it means real people decided your product was worth paying for. That's the hard part.

This distinction between operational failure and signal loss is gold. Most products view billing bugs as technical debt. But when your renewal email doesn't send, you've poisoned the entire feedback loop - you'll never know if they actually churned or if your infrastructure did.

That missed reminder cost more than revenue; it cost certainty. You're now running a product where churn data is noisy, which means you can't confidently iterate on retention.

The fact that you immediately prioritized fixing the renewal infrastructure over adding features shows you understand that in SaaS, operational reliability IS the feature at this stage. Most founders don't realize that until much later.

The free vs paid conversion gap is brutal at this scale. One thing that helped me: identifying the 5-10 most engaged free users and personally reaching out before renewal. Most churn at this stage is silent — they just don't come back. A direct conversation recovers more than any email sequence.

The distinction that stood out to me is between operational failure and product failure.

If a customer leaves because they chose to, that's valuable feedback. If they leave because your renewal process broke, you've lost the ability to interpret the signal. Protecting the quality of your feedback loops is just as important as protecting revenue.

Free users are not converting