Genuinely curious. Most rejections I've seen are some version of "we've decided to move in another direction" and nothing else.

Has anyone ever gotten actual, useful feedback after an interview? What did it say, and did it change how you interviewed next time?

Builders, for those of you who have launched on Producthunt or actively engage in comment sections; What is the ROI here? As a new user and builder myself, how do you get the most value out of this platform?

For those who've launched: How many people are actually following through with feedback, beta testing, or staying in contact long term? Are those 10-20% of people worth it?
For those active in threads: How do you get value? How often does the scratch my back and I'll scratch yours exchange actually take place/help? Are you just here to scroll?
If you come here looking for an answer, how much time do you spend looking for it before you go to the next platform? Is reddit the alternative?
If you have any good strategies, let me know!! Would love to learn more.

I ve launched a few small tools before, but I usually skipped the whole talk to people first step. I d just build, ship, and hope something stuck.

This time, I m trying something different. I started asking around about a pain I kept noticing, SaaS free trials and how hard it is to get meaningful feedback from 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.

I m not a designer. I build landing pages by telling an AI what aesthetic I want and letting it generate the interface. It s magical, but it has one hidden trap: I can t tell if the layout actually makes sense to a user.

A few weeks ago, I had AI design a sign-up flow for a mini project. It looked modern, sleek, and worked smoothly on my laptop. A week later, when I watched a friend try to use it on mobile, they couldn't even find the submit button because the contrast was terrible and it was buried off-screen. Nothing looked "broken" to me at first glance, so I almost missed it.

It made me wonder if non-designers are launching products too easily just because the preview looks pretty.

How do you test UI/UX when you can t evaluate the design code or principles? Do you run blind user tests, ask the AI for accessibility audits, or just hope visitors figure it out? And has a "perfect" AI design ever failed you in the real world?

I've been using Claude Code heavily for the past few months while building my startup (12k+ line Python codebase), and it's genuinely changed the way I develop. It navigates large codebases with context that I haven't seen from any other tool: understanding file relationships, catching upstream/downstream effects of changes, and reasoning about architecture-level decisions, not just autocompleting lines.

But what really caught my attention is the business side. Anthropic is forecasting cash-flow positive by 2027, while OpenAI is projected to burn through $115B+ through 2029. Claude Code alone reportedly crossed $1B in annualized revenue. Their API revenue is estimated at double OpenAI's. And they're doing all of this with significantly lower burn.

In the second half of the year, I wanted to use some kind of lead magnet that I sent to people in exchange for their email address.

My questions are for observing purposes:

Using AI to spin up new features is awesome for speed, but letting it handle the test suite usually creates a mess of brittle tests. They either pass by mocking out half the application or fail because the agent didn't understand the broader system architecture. Lately I've started treating AI-generated code as untrusted until I manually write or review the tests myself.

What kind of review workflow or safety checks do you use to make sure your test suite doesn't slowly rot away?