Connect with the Product Hunt community

It s funny how all our automated tests can pass with 100% green checks and yet a simple user action like hitting the browser's Back arrow completely breaks the app experience.

I spent hours debugging why an onboarding wizard kept dragging finished users backward because of how router pushes stack up in Next.js. Unit tests just don't catch browser level history states unless you're running heavy end-to-end browser tests.

For UI flows with multiple steps do you rely on tools like Playwright to test history behavior or is this just one of those things you catch manually by testing it yourself?

When you're early post-launch, everyone has an opinion on what your product is missing. It's so easy to get pulled in five different directions trying to please the loudest voices.

I've caught myself almost rebuilding the roadmap just because two people asked for the same feature on the same day.

How do you filter out the noise and figure out which feature requests will actually move the needle for retention?

One thing I keep struggling with while building products is figuring out which features are actually worth spending time on.

I sometimes come up with ideas that sound great, but then I wonder whether anyone would really use them. I also don't want to spend days building something that people don't actually need.

I'm trying to get better at understanding user needs before jumping straight into coding.

For those who've built and launched products, how do you usually decide what to work on next? Do you talk to users, look at feedback, or just build your ideas and see what happens?

early on every request feels urgent because there are so few users. one person asks for something twice and it starts to feel like the roadmap. but a loud user and a common need look the same when you only have a handful of people talking to you. my view is the request matters less than the problem under it, and if three people describe the same problem in different words thats worth more than one person asking for the exact feature five times. curious how others draw the line. do you have a number, a rule, or is it mostly gut until you have enough users to see patterns?

I feel like internal documentation has become a losing battle lately. Code changes endpoints move around, and setup configs tweak every few days but no one wants to pause momentum just to write static markdown files. Eventually onboarding becomes a game of "ask the lead dev on Slack" because the official docs are useless.

We're trying to figure out if there's a lightweight habit that actually sticks like auto generating API docs from code comments or keeping docs right inside the codebase itself.

If you work on a fast moving project what's one actual practical workflow that kept your docs from falling behind without feeling like a chore?

It took me a good while to figure this out. When my programming agent makes an error and I point out the wrong part, the correction doesn't vanish inside the chat log. It's saved as a file. So the next session never trips over the same issue twice.

So far the agent has written 100 incident notes. It also keeps memory notes in the project, one fact for each file. Each time a session starts, a one-line index of those notes gets loaded. If the same mistake happens again, it becomes more than a mere memory. It becomes a hook. And that hook runs on every tool call and every reply, regardless of whether the agent remembers it. I currently have 63 hooks.

A few of those hooks came from pretty ordinary situations. After long sessions in another language, the agent started replying in English. According to the note, the more English documents it had read recently, the higher the chance it would drift. So now, whenever a reply comes out in English, one of the hooks forces a rewrite.

Another time it claimed something was fixed without ever testing it. That led to a rule: it must write down exactly how it checked. Dash usage also got restricted.

Something I keep running into: the work gets approved, everyone's happy, and then a week later comes "can we just tweak one small thing?" Then another. None of them are big on their own, but together they quietly eat the margin on the project.

I'm curious how others deal with it:

• Do you include a set number of revision rounds in the original scope, or handle each request as it comes?

• Is there a point where you start quoting post-approval changes as new work, and how do you say that without souring the relationship?

• Does writing down exactly what was approved (and when) actually help, or do clients just ignore it?

Would love to hear what's worked for you, and what backfired.

Moving upmarket brings a wave of requirements around compliance, audit logs, and granular permission controls.

Implementing these systems takes months of engineering bandwidth, which pulls focus awat from the snappy lightweight experience our core self serve user signed up for.

For teams expanding upstream: how do you manage this split focus without diluting your original product identity?

Ngl, I'm kinda tired of AI case studies that read like fairy tales. Pilot, rollout, ROI, done.

The numbers tell a different story. MIT's NANDA report (2025) found about 95% of gen AI pilots showed no measurable P&L impact. Gartner expects 40%+ of agentic AI projects to get scrapped by the end of 2027. So where do all the messy middles go?

I spent months on acquisition. Ads, content, outreach, the whole playbook. New signups every week.

Churn ate all of it. I was filling a bucket with a hole in the bottom and calling it growth.

Our earliest adopters built impressive custom habits around our product's initial limitations, using spreadsheets and manual exports to fill the gaps.

When we finally shipped the native automation to replace those hacks ,engagement actually dropped for a week because their familiar routine were disrupted.

For teams launching core updates: how do you introduce structural product changes without alienating users who rely on the old way?

Whenever we run a contest or promo to reward our community with free access the biggest headache is always our existing paid subscribers. They're the ones who support us the most so ignoring them or making the process complicated feels wrong. But auto extending active paid plans manually is quickly becoming an operational hassle.

I m curious if anyone has found a clean automated solution for this.

Do you pause their recurring billing for a month gift them an upgraded feature tier instead or is there a simpler workflow I m missing? Would love to know how other founders structure this to keep subscribers happy without messing up billing records.

There s so much noise right now about how AI lets you pump out 10x more video content in half the time. But honestly most of the fully generated stuff I see feels lifeless and gets scrolled past instantly.

I find these tools great for brainstorming concepts or grabbing quick placeholder visuals but pulling together a real story still takes manual tweaking and human intuition.

For those making content regularly have these speed up tools actually helped your quality or just pushed you to create more noise?

Every bug report, logged. Date, user, severity, what broke.

The pattern was not what I expected. Half of them were not bugs at all. They were confusion. People using the product in a way that made sense to them, hitting a wall, and reporting it as broken.

I built a couple of web-apps that barely have or have none users, and because of that I'm really stuck right now. I can't get any feedbacks on how the web-app is or how could I improve it. Could someone share a working advice?

Month a partner platform changed their API payload structure without telling anyone turning a regular user ID field into a nested object. That small change broke three days of data across our CRM and email marketing systems.

Of going through thousands of bad records in the database one by one we created a simple validation middleware between our webhook receiver and our internal processing queue. Every incoming payload now goes through a schema check before it reaches any business logic.

If a field does not match the schema we expect the middleware moves the payload to an error log table. Sends a message to our developer channel on Slack right away. This small change has saved us a lot of time that we would have spent fixing data

What error handling strategies do you use to keep your automated workflows safe, from API changes?

Every time I look at pre built AI roles for things like customer support or lead qualification the sales page makes it look effortless.

But in reality as soon as you connect your own data and approval rules you realize your internal process is way too messy for a plug and play bot. You end up spending hours re configuring everything anyway which makes me wonder if starting from scratch with modular tools is just better from the start.

For anyone who brought AI into their daily ops did buying a pre packaged role save you time, or did you end up building your own logic?

For the longest time my weekly dopamine hit was watching the signups counter tick up. I thought traction meant volume.

Then we started tracking 7-day and 30-day active usage, and the reality check was brutal. We were pouring water into a leaky bucket, celebrating every new registration while users slipped away silently within 48 hours.

For founders who survived this transition: what specific metrics or milestones forced you to stop celebrating signups and actually fix your activation loop?

Google Search Console told me one of my blog pages had 2,246 impressions over 28 days for the query "workout app development", sitting on page one. Semrush has no US volume figure for that query at all. When I split the same query by device in Search Console, 19 of those 2,246 impressions were mobile.

So I checked a second one. "ai manufacturing cost reduction case study": roughly 825 impressions a month in Search Console against Semrush's 320 a month, and 1 mobile impression.

When a user asks for a new button or a custom dashboard, it's super tempting to just build it and make them happy. But half the time what they re asking for is just a band aid over a much bigger issue they re having with your app. If you just keep adding every requested feature your product becomes a bloated mess.

On the flip side if you question everything they say you risk sounding like you aren't listening to them. How do you decide when to just build what they asked for versus spending time investigating what's actually broken in their workflow?

Every launch guide says the same thing: go live at 12:01 AM Pacific so you get the full 24-hour window. But I've now watched enough launches to suspect that's a leftover from an older version of the platform, and that the algorithm and the audience have both changed.

What I actually observe: the first few hours are dominated by people in a similar timezone, most upvotes come from a few concentrated windows during the day, and a late-afternoon launch with a strong push can outperform a midnight launch with a weak one.

But I don't have real data I have vibes and a handful of launch pages I've stared at.

So: if you've launched more than once at different times, did the time actually move the outcome, or did the audience and prep dominate everything? And has anyone seen a launch succeed that went live at, say, 9 AM Pacific? I'm looking for counterexamples specifically.

I've been building for developers for four years, and the pattern I keep seeing in my own product and in every dev tool I've watched succeed or die is this: developers don't switch tools because the new one has more. They switch because the old one wasted their time in a specific, annoying way, and the new one removed that specific annoyance.

"More features" is what vendors think developers want. "Less friction in the exact place I'm already annoyed" is what actually drives adoption.

The corollary: every feature you add is a new thing a developer has to evaluate before trusting you. The best dev tools I use are the ones that resisted adding things.

So my claim is: in developer tools, feature count is a cost, not a benefit. Curious whether people agree or think I'm overstating it. And if you build dev tools. what's the one feature you deliberately refused to build, and did it help or hurt?

Three launches on the board today price in credits, and the complaint underneath each one is the same.

Solid's reviews say credits burn while fixing errors the tool itself caused. Speechka charges 1 credit per minute of translation mode, so you pay full freight for the call where the other person does most of the talking. GBrain bundles $100 of usage into a $199 seat, which is fat margin or underwater depending on which model the user happened to pick that week.

I just got off a brutal call with a prospect we ve been courting for six weeks. They are a mid-sized logistics company, exactly our ideal customer profile. We did the demo, they loved the UI, and the VP of Ops said our automated reporting would save his team hours every week.

Then he asked about the price. When I quoted our standard $3,000/month plan, he went quiet.

An hour later, he emailed me saying they decided to pass. They are going to keep using the Excel spreadsheet their intern built three years ago.

I was shocked. Our product solves the exact pain point they complained about. But when I dug deeper, the reality hit me: their current spreadsheet is "good enough." It s a mess of broken macros and manual data entry, but it costs them $0 in software spend and they already know how to use it. The friction of learning our tool and migrating their data (plus the $36k annual price tag) outweighed the pain of the spreadsheet.

I see a lot of "raise your prices" advice, and I mostly agree with it, but I think it's hiding a harder question: sometimes raising prices is the right move, and sometimes it's a way of avoiding the fact that your positioning is wrong and churn is telling you so.

The distinction I'm trying to draw: raising prices to capture value you're already delivering is good. Raising prices to fix a conversion or retention problem is rearranging deck chairs.

The tell, I think, is whether your existing customers would pay the new price. If yes, you were underpriced. If no, you have a different problem.

Curious how others have told the difference especially anyone who raised prices and then realized the real issue was something else entirely.