Our Net Promoter Score was consistently sitting at a depressing 12, yet our revenue retention was over 110%. We were completely confused.
When we jumped on 1-on-1 calls with customers, we discovered that users found our product's interface ugly and clunky, but the core data it generated was so indispensable to their daily operations that they couldn't switch to a competitor even if they wanted to. They were paying us every month while actively disliking the daily experience.
If you've ever inherited a product with high utility but terrible UX: do you pause all new feature development to rebuild the interface, or keep shipping value and live with a frustrated user base?
Question for folks documenting APIs, especially with docs in a separate repo from the code: how do you find out about changes before a customer does?
The big features usually reach us. What slips is side effects: a PR about a new filter that also lowers the max page size from 100 to 50, a default that flips, a new error code, a renamed webhook field. One line in a diff that's mostly about something else.
We built a tool that people said looked great, felt smooth, and solved a neat problem. People signed up, paid for the tier, and then quietly drifted away. No angry emails, just silent cancellations.
That s when it hit us: we built a vitamin, not a painkiller. It was nice to have but when budgets got tight or schedules got busy, it was the first thing to get dropped from the daily routine.
If your product isn't tied to an urgent daily workflow, how do you pivot before churn drains your MRR?
I have so many ideas. So many. They arrive at random times, usually when I'm supposed to be doing something else, and they all sound incredible.
And then I look at my bank account and remember I have a budget. And the ideas are not free. They cost time, money, energy, all the things I don't have unlimited amounts of.
Meow Monday I recently enjoyed reading this Discussion on insights and best practices to get more stars on GitHub. @zoltanszogyenyi suggested nailing the README file -- the most important of a repo? -- as it's the first thing everyone looks at. So, what makes a README file awesome from your point of view? What are the key elements you'd expect when reading one? Any good example?
I spent a day trying to fix something and could not. Nothing worked. I tried everything I could think of.
Then I remembered I had deleted a block of code months ago because I thought it was useless. It was not useless. It was doing something I did not understand, and I had removed it because it was old and messy.
With all the recent data leaks and surveillance laws, it feels like the vibe is shifting toward 100% local, on-device compute, even if it means settling for smaller models. Running things locally used to feel like a niche hobby, but with the massive leaps in open-source efficiency, it is becoming a viable daily setup for privacy-first projects.
Granted, dialing in the right hardware and dealing with speed tradeoffs is still a massive pain compared to a ready-to-go API.
Are you guys actually moving your daily workflows and tech stacks to local alternatives, or is cloud still your go-to for convenience? Where do you stand on this?
Early on, we assumed cancellation reasons were mostly financial that users just didn't want to pay our monthly fee. But looking closely at user drop off data revealed something surprising.
Most churned users never even hit their plan limits or core paywalls. They canceled simply because the setup effort was too high to reach their first aha! moment. Lowering prices or offering discounts doesn't fix a onboarding flow that takes 3 days to deliver value.
For founders who have tackled this: how do you redesign your onboarding or activation steps to get users to core value before they lose interest?
