Connect with the Product Hunt community

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.

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?

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'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?

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 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.

In my field (small B2B software), the common knowledge is "you need a sales team once you pass a certain revenue threshold." Everyone says it like it's physics. But the two most profitable small software companies I know personally have zero salespeople the founders just answer support tickets and the customers upsell themselves. Meanwhile the companies I've watched stall out all hired salespeople too early and then had to feed them deals that weren't ready.

I'm not saying sales teams are useless. I'm saying the threshold gets repeated as a law when it's actually a guess, and a lot of people make expensive hiring decisions based on a guess.

So what's the "everybody knows" thing in your field that you suspect is just inherited folklore? Bonus points if you've actually tested it and been wrong either way I'm more interested in the people who believed the common knowledge, tested it, and found out it was right after all.

I was thinking about how annoying traditional sign-up forms are with all the CAPTCHAs and email verification steps. If an AI assistant is trying to set up a service for its owner our current onboarding flows completely block it. Allowing bots to auto-create accounts sounds like a fraud nightmare but forcing a human to manually type in details feels outdated.

I'm leaning toward letting the AI fill out all the fields while keeping just one single click for the human to approve everything.

How are you handling this in your own apps are you keeping sign-ups strictly human, or opening the door for agents?

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.

I used to treat headlines as just a quick marketing task something you polish right before launch to make the site look pretty.

But recently, while trying to explain a simple feature on a landing page we realized we couldn't describe the core value in one plain sentence without making it sound vague.

Trying to write a clear headline forced us to admit that our feature wasn't actually solving the problem as simply as we thought. It completely changed what we ended up building next.

Have you ever had a moment where rewriting a single line of text exposed a massive gap in your actual product?

I want to separate the mythology from the data here, because I keep hearing two contradictory things.

Version A: PH launches are a vanity metric now the upvotes don't convert, the badge is a participation trophy, and the real value is the backlink.

Version B: people still get their first 100 paying customers from a single good launch.

My situation: no audience, no list, product is B2B and costs $29/month. A launch would be my first real distribution moment. I'm trying to decide whether to spend six weeks building an audience first, or launch now and use PH as the audience-building event itself.

Working with enterprise tools all day means my brain is fried by the time I get home but I really don't want my Python skills to gather dust.

I tried tackling massive ML projects on the side before but I always end up quitting halfway because they're too heavy. I'm trying to find a balance maybe a lightweight automation or a simple local AI tool that I can hack away at for 30 minutes a day.

What small coding projects did you build that actually held your interest?

Last week, a customer paying our highest tier threatened to churn unless we built a custom reporting dashboard that has nothing to do with our core workflow.

Saying no felt terrifying because of the MRR at stake. But saying yes would turn us into a bloated agency instead of a focused product.

for founders past the early stages: where do you draw the line between keeping enterprise revenue happy and protecting your product roadmap?

early on whenever a paying user asked for a specific feature, my immediate reaction was to build it to keep them happy. Our roadmap became a messy patchwork quilt of random requests.

Eventually, I realized those feature requests were often band-aids covering up a confusing core UX or a deeper workflow mismatch. Building what they asked for didn't even stop them from churning later.

for founders managing small teams: how do you filter out the noise of individual feature requests and stick to your core product vision?

When users cancel right after their trial ends, it's easy to panic and think, "We're charging too much." So the instinct is to offer discounts or lower the price barrier.

but whenever we dug into exit surveys, price wasn't even the top complaint it was usually that they didn't reach the "aha!" moment fast enough to justify any price tag. Lowering the price wouldn't have saved them if they weren't getting value.

for founders who went through early monetization: how do you diagnose whether churn stems from pricing structure or a failure to communicate core value quickly?

The users who email you angry or leave detailed feedback are actually doing you a favor even if it hurts. You can learn from them.

The real ghosts are the ones who quietly downgrade, cancel via the billing portal, and ignore every single automated exit survey you send. You're left staring at a dashboard with zero qualitative context on why they left.

for SaaS builders: what creative strategies or prompts actually get silent churners to tell you what went wrong?

We used to think high onboarding ratings meant we built something sticky. Turns out, getting a 5-star review during a test run doesn't mean people will actually open your app next week.

If a tool demands extra mental effort instead of sliding smoothly into a daily routine users just drift away.

How do you design your product to become an automatic part of someone's morning workflow?

When a free user complains, it's easy to ignore. But when a long time paid customer drop a harsh cancellation note or leaves a blunt review, it hits differently even if the overall churn rate is low.

Early on, every churned user feels like a personal failure of your product vision.

As you scale, do you naturally build a thick skin toward churn feedback, or do you just learn to separate product noise from signal?

For the first year of our startup, it was just me and two co-founders writing code. We finally raised a small pre-seed round and decided to make our first big hire: a Senior Software Engineer.

We were thrilled when we snagged someone from a major tech company (think Google/Meta). On paper, they were a rockstar. The resume was flawless, they passed our technical interview easily, and we paid a premium salary to get them.

We recently had a small discussion about bottom spacing in a B2B product.

The layout was using 80px of bottom padding, and the feedback was that it felt a little cramped. So we started looking at 160px instead.

My first thought was whether doubling the spacing was really necessary.

But looking at different screens made me question the idea of having one fixed value in the first place.

When your software is free, users will gladly ignore a broken button or a slightly confusing layout. But as soon as you start charging even $5 a month, the grace period ends instantly. Suddenly, tiny glitches that no one cared about before become urgent refund requests. We noticed people stop treating the product like a fun tool to try out and start judging it strictly by the time or money it saves them. For those who switched from free to paid how did you handle that sudden jump in customer support demands?

Launch day gets all the attention. The day after is the part nobody writes about, and it's the part I'm least prepared for.

The upvotes stop, the notifications dry up, and you're left with a product, some new signups, and a very quiet inbox. The temptation is to immediately start planning the next launch. I think that's a mistake the week after is when you actually learn whether the launch meant anything.

What I'm planning to do with those seven days: personally email every signup from launch day, ask one question ("what made you click?"), and read the answers before touching the product again. No new features that week. Just listening.

For people who've launched: what did you actually do in that week, and did it change what you built next? I'm especially interested in anyone who ignored the post-launch week and regretted it.

agents made prompt edits scary for me. tweak one system prompt and a tool call 3 steps later starts failing. what helped: prompts live in git, every change runs against a small fixed set of real traces before shipping, and the last good version is always one revert away. curious what others do here, do you run evals on every prompt change or only the big ones

I ran the same read-only task in Claude Code twice: explain 4 source files and how they relate. Once with a single agent reading all four, once with a lead agent that launched one subagent per file and combined the answers. 3 runs each, same model, token counts from the CLI's JSON usage output (input + output + cache read + cache creation, subagents included).

Single agent: about 106k tokens, $0.14 on average. With 4 subagents: about 383k tokens, $0.41. So 3.6x tokens and 2.9x cost, and it was not faster either (about 12s vs 18s, though one run's timing looked unreliable). Cache reads dominate the token count and are billed cheaper, which is why cost grew less than tokens.

Caveats: n=3, one small task, one model. The files fit easily in one context, so subagents had no isolation benefit here. I did not test the case where each subagent would otherwise dump a huge output (big logs, large search results) into the main context.

What I'm unsure about: where is the crossover? Is it file count, size of intermediate output, or tasks that run long enough that the main context gets polluted? And do you have a rule of thumb for when you hand work to a subagent versus keeping it in the main thread? Real numbers from your own runs would be especially useful.