We fell right into the feature request trap early on. Users kept asking for complex PDF export options and fancy dashboard filters so we spent two whole weeks building them.

Once it shipped hardly anyone touched it because it didn't actually fix their core bottleneck. Shifting from "what feature do you want?" to "what are you trying to get done right now?" completely changed our roadmap.

When a vocal user asks for something specific how do you dig past their suggested solution to find the real problem?

We used to check our feature board like a crime scene every time someone canceled always blaming that one missing integration. Then we actually started jumping on quick exit calls with churned users.

Turns out, 90% of them didn't care about the missing feature they just hated that our app forced them to completely change how they communicated with their team.

Shifting an existing team habit is infinitely harder than building a new button. When a user blames a missing feature for leaving, how do you figure out if it's a workflow mismatch instead?

When users cancel their subscriptions their automated exit survey feedback is almost always polite and vague usually citing budget cuts or lack of time. Those generic answers never gave us detail to fix our actual product flaws.

We changed our email template to ask one question: "What specific task were you trying to finish today when you decided to cancel your account?" That shift in wording changed everything because it forced people to talk about a concrete workflow moment.

Of getting vague complaints about pricing we started hearing exact details about confusing button placements and slow load times. Those specific insights gave our design team direction on what to fix each week.

What phrasing works best when you ask departing users for feedback, about your product?

Standard remote interviews are honestly becoming a bit pointless because everyone just has an AI helper open on the side.

We noticed candidates giving these perfectly formatted textbook answers but then struggling with basic debugging during their first week on the job.

Asking people to walk through an actual mess of code or a real company problem live on a call changes everything. How has your hiring process changed to filter past the scripted AI answers?

We promised direct, instant 24/7 founder-led support to every new customer to stand out from larger competitors. At first, customers loved the personal attention, and our retention rates were higher than ever.

But as our user base grew, this turned into a constant stress point. Our team is now overwhelmed by midnight support tickets, resolving minor edge cases, and hand-holding users through basic onboarding. As a result, zero time is left for high-level strategy, product improvements, or scaling our marketing.

It made me realize that over-servicing customers early on builds unsustainable expectations that break the moment you try to grow.

Have you ever over-indexed on manual customer support, and how did you transition to automated or self-serve systems without upsetting your early users?

A developer described this in an r/SaaS thread I started this week and it is the cleanest version of the problem I have seen.

Their Symfony app had an exception listener on kernel.exception registered at priority 200. It called setResponse(), which stopped propagation before Sentry's listener at priority 128 ever ran. Every controller exception in the application stopped reaching Sentry. Nothing crashed, nothing errored, and the dashboard stayed quiet. A quiet dashboard and a working dashboard render identically.

They found it because a person reported a 500 on a CSV import and the stack trace was not in Sentry at that timestamp. Not from a system. From a customer, hours later.

The detail I keep thinking about is the exception to it. Twelve Untrusted Host errors did reach Sentry in that same period, because on those the listener threw before it got as far as setResponse(). So the error reporting worked precisely when the suppressor was broken. Seeing errors arrive was never evidence the path was intact.

I've been on Product Hunt a lot lately, mostly trying free tiers of stuff that launches here, and it's made me realize our whole team's subscription list is a mess.
I run a small 5-person team doing marketing and reporting for a few client accounts. Half our stack is stuff I actually found on PH over the years, some free, some paid, picked up whenever something looked useful at the time and never really reviewed since.
Went through it recently and found we're paying for at least 2 tools nobody's touched in months, tools I remember being excited about on their launch day here, while some of our free tools are quietly hitting real limits every week.
So I've been trying to change how I evaluate PH launches specifically. Instead of signing up the moment something looks good in the comments, I wait and actually watch usage. If a free tool hits its limit consistently for a few weeks, that's a real signal to upgrade. If something I signed up for during a launch goes untouched for a month, that's a signal to cut it.
How do you approach this?
When you find a tool here that you use regularly, what makes you decide to pay for it?
Do you track usage limits directly?
Do you run a periodic audit of everything you've signed up for from PH launches?
Do you just wait until something breaks or gets annoying enough?
Or something else entirely?
What's the ONE thing that convinces you: "yeah, this is worth paying for" versus "this one's getting cut," especially for stuff you find here versus tools you already knew about?
Would love to hear how other PH regulars handle this.

LLMs getting stuck in execution loops is such a huge headache when building DB tools.

We had a similar issue with API retries where the agent kept tweaking minor parameters forever. Capping it at two attempts and routing the failure directly to Slack is a solid circuit breaker.

In our setup, we usually allow two retries with an exponential backoff before killing the thread completely.

How do you handle the Slack notification does a developer jump in and manually correct it or just kill the process?

We ve been debating between offering a 14 day free trial or a permanently free tier restricted features. Freemium seems great for virality, but managing storage and server costs for inactive free users gets expensive fast. On the flip side, time-boxed trials create urgency but turn away casual explorers.

For early-stage SaaS, which model helped you convert high-intent users faster without burning resources?