Day 13 on Indie Hackers — what PulseOps shipped, what we learned, and how to get early access

Two weeks ago we posted our launch thread on Indie Hackers. The thesis was simple: founders shouldn't have to check Stripe every morning to know whether their business is healthy. Today is Day 13. Here's what shipped between the original post and now, what the early thread taught us, and how you can get into the next onboarding cohort.

What we shipped for the thread

The first version of PulseOps you could sign up for was a thin wrapper around a daily email digest. That wasn't enough. The founders reading the thread wanted the same thing they always want — tell me when something is wrong, don't make me look — and a daily email still asked them to read.

So between Day 1 and Day 13 we shipped four things that turned PulseOps from a digest tool into an actual alerting stack:

1. Stripe Connect onboarding. New users can connect their own Stripe account in under two minutes via the standard OAuth flow. No manual API key pasting.
2. 15-minute alert sync. A scheduled job pulls the latest Stripe events every 15 minutes per connected user and fans them out through the alert-rules engine. An MRR drop, a failed-charge spike, or a high-LTV cancellation fires an alert within that window — not at the end of the day, not on Monday morning.
3. Daily 9 AM digest. Still ships, but now in parallel with the real-time alerts. The digest is for the slow-moving weekly view; the alerts are for the thing that needs a response today.
4. Selective on the frontend. We got more than one comment along the lines of "I don't want my phone buzzing every hour." So the alert preferences are configurable per user — channels, thresholds, which rules are even enabled.

The cumulative effect: the founder signs up, connects Stripe, sets their thresholds in onboarding, and then mostly stops visiting the app. If something needs them, the email or Slack message tells them. If nothing needs them, the 9 AM digest tells them the business is fine — and they get their morning back.

What we learned from the thread

A few patterns showed up in the comments that we hadn't anticipated:

The people who responded fastest were not the people with the biggest MRR. They were the people who had just crossed a threshold — usually their first $5k MRR, or their first failed charge that didn't auto-recover. The dashboard-checking habit is most painful at the moment a founder stops being able to hold the business in their head and isn't yet comfortable trusting automation.

The objection that came up most was "I already have a dashboard." It came up so often we wrote a whole blog post about why that's not the same thing (see Why Founders Keep Checking Dashboards). The short version: a dashboard you have to remember to check isn't a monitoring system. It's a habit with a UI.

The thing founders didn't push back on was the daily digest. Everyone wanted the morning email. It's the alerts — the interrupting ones — that need a softer onboarding. We adjusted the default thresholds in the prospect_sla_breach and high-LTV churn rules to fire less aggressively out of the box, and let users dial them up once they've lived with the system for a week.

The best feedback we got was a founder who said: "I deleted three monitoring tools the week after I connected PulseOps. I didn't realize I'd been paying for the feeling of watching my numbers until I stopped."

That single comment re-shaped the homepage.

Early traction — what we can honestly say

We don't have vanity numbers to share here. There's no "47 founders signed up in 48 hours" headline to put on the blog. What we can say is more useful, and we think more grounded:

• The first Indie Hackers comments started arriving within the first day of the launch post going up. Most were founders in the $3k–$40k MRR range who'd been doing the manual dashboard check for long enough to be tired of it.
• The waitlist started picking up signups attributable to the thread — small enough that we know which ones came from where, large enough that it changed our onboarding capacity planning.
• The first Stripe Connect onboarding completed end-to-end without a support email. That was the milestone we were watching for; the system worked for a complete stranger on the first try.
• Several founders asked the same question on a loop: "What happens when I cancel my subscription?" — which told us the cancellation UI needed to be more prominent. We pushed that fix in the second week.

What we can't tell you is the conversion rate from waitlist to paid, because the cohort is still small and the numbers would lie. We're publishing this update instead of a metrics post on purpose.

What's next

The two pieces of work in flight right now are:

1. Prospect SLA alerting. For users who opt in, PulseOps watches inbound leads and fires an alert when a tracked lead goes unanswered past a threshold (default 24 hours). This was the most-requested feature in the thread comments. It's live in the alert-rules engine now; we're tuning the default thresholds based on the first cohort's response patterns.
2. Lead response time analytics. A small dashboard for inbound leads: average first-reply time, distribution buckets, who's falling behind. We added this because the founders using PulseOps for Stripe monitoring kept asking for the same view on their sales pipeline.

Both roll out to the early-access cohort first, then to everyone else once the kinks are known.

How to get early access

If you've read this far and the idea of "one alert instead of five dashboards" resonates, the next cohort is open. We onboard a small number of new Stripe accounts each week so we can keep the alert-quality bar where it is.

Join the early-access waitlist →

We'll email you when your slot opens. If you're already on the waitlist from the Indie Hackers thread, you're in the queue — no need to re-sign up.

Thanks to everyone who commented, asked hard questions, and pointed out the rough edges. Day 13 is better than Day 1 because of it.