6 signups, 5 activated, and the bugs that shipped anyway
Two weeks post-launch, wrote down the actual numbers instead of the flattering ones.
6 signups. 5 generated a report. 1 didn't, so I followed up with them directly instead of just... not counting it.
Also wrote up the bugs that shipped anyway: a BYOK key-nulling bug, a percentage-vs-dollar misclassification bug, a Templates bug where 4 of 7 report sections rendered regardless of the toggle, and a CookieYes install that silently killed GA4 for a day because two consent systems didn't know about each other.
None of it's impressive. That's kind of the point — this is what a two-week-old bootstrapped SaaS actually looks like before the numbers get big enough to round off the edges.
Full writeup here if you want the details: https://www.naxely.com/blog/two-weeks-building-naxely?utm_source=indiehackers&utm_medium=social&utm_campaign=two_weeks_post
Curious how others handle the "do I post the ugly numbers or wait for better ones" question — I went with ugly-now.
Ugly-now is the better update because 5 of 6 activated is interpretable only alongside the failure. For the next snapshot, show whether each bug blocked report generation, corrupted output, or only affected analytics, then whether those five activated users returned. That turns the small cohort into product learning instead of vanity math.
Checked — none of the 5 have come back for a second report yet. Everyone's still sitting at exactly one, including the founder-adjacent counting I was doing. So "ugly-now" gets uglier: 5 activated isn't retention, it's one-time trial. Appreciate the push, that's a sharper number to be tracking than the one I posted.
Good catch. Don't call the cohort failed yet; define the next moment a report becomes useful again and trigger around that. If reports depend on new spend or data, ask each user when their inputs change and schedule one reminder for that event. The metric becomes returned when the problem recurred, not returned within an arbitrary 14 days.