Connect with the Product Hunt community

When we started our first project, we shared every update on social media thinking it would build an instant waitlist. While we got a lot of high-fives and vanity metrics, very few of those followers actually converted into paying users at launch. On our next product, we stayed quiet and focused purely on talking to 10 specific target users. The launch was much smaller in terms of buzz, but our initial conversion and customer feedback were 5x better.

Is public building overhyped for early-stage validation, or were we just doing it wrong?

We used to require complete configuration right when a user signed up, but our drop-off rates were terrible. Watching heatmaps helped us realize people weren't losing interest in the product they just hated doing admin tasks before seeing any real results.

We're trying to restructure things so users see sample data or a working preview first, then finish the heavy integration later.

If your product relies on heavy account setup, how do you hook new users in their very first session?

Our launch day was incredible hundreds of signups, high engagement, and lots of positive feedback. We thought we had cracked the market.

30 days later, the cohort retention graph took a sharp nose-dive. The surge of early adopters brought curious visitors rather than long-term users, and as the initial hype wore off, the steady stream of daily active users dried up.

For makers who have launched on platforms like Product Hunt: how do you transition from top of funnel launch momentum to consistent week over week user retention?

We spent weeks perfecting our product's core engine, assuming users would stick around once they saw what it could do. But our dashboard analytics told a harsh story: most signups dropped off right at the empty-state screen before hitting the "Aha!" moment. we replaced the blank dashboard with pre-filled sample templates and a 2-step setup. Activation rates jumped overnight not because the product got better, but because time-to-value got shorter.

Is onboarding friction usually a product design issue, or a failure to set expectations before the user even signs up?

For a long time, using clean mock data during API integration felt fast and smooth. The problem was that edge-case bugs always snuck into production whenever real data contained missing fields, null values, or unexpected formatting.

Three weeks ago, I completely changed my approach. Now, before I write a single line of frontend code, I make AI generate worst-case API payloads missing fields, broken timestamps, and oversized strings.

Last Friday, testing against these broken mocks helped me spot a critical UI crash in under five minutes locally. Under my old workflow, this bad data issue would have quietly slipped through and wasted hours during QA.

Are you still using clean mock data during development, or do you test against bad payloads first?

Put up a simple feature list for my app a while back and users loved seeing what was coming. But the second a feature got delayed, people started emailing to check up on dates.

Nobody was mean about it but having strict timelines out in the open created way more stress than I expected. switching to a simple now/next/later setup helped a lot.

How do you guys share future plans without making yourselves feel bound to specific deadlines?

When I launched my first tool, I expected launch day traffic to convert into real revenue. In reality I got tons of traffic and nice compliments but zero sales from the main launch itself.

All my actual early paying users came from sending cold messages on X to people who were actively struggling with the problem plus a few referrals from niche Slack communities.

If you had to redo your first month where would you actually focus your time to land those initial buyers?

Between Samsung's engineers leaking their own source code into ChatGPT, DeepSeek leaving a database of a million chat logs sitting open with no login required, and Grok's share links somehow getting indexed on Google with 370k private conversations searchable, I've basically stopped believing "trust us" is a real answer from any frontier lab.

None of these were sketchy no-name startups either. These are the companies everyone's building on top of right now.

AI has made it much faster to turn an idea into something you can actually look at and use.

But I m starting to wonder if that shifts the bottleneck rather than removing it.

When producing a new version takes less time, there are simply more versions to look at, more decisions to make, and more things that can move forward without much discussion.

From a product design perspective, that makes review feel more important, not less.

Today a local MCP server I use came up about ten seconds after my session had already started and polled for tools. The client resolves the server list once at connection time and never retries. Every call to that server's tools returned ConnectionRefused for the rest of the session, even once the server was fully healthy.

Restarting the session works but throws away the whole conversation. The actual fix was smaller. Check whether the process is even running, confirm the port answers with a raw request to its own endpoint, and if it does, talk to that server directly over its own protocol instead of going through the client's tool list. Same server, same session, no restart.

We asked a coding agent fifteen times to make one button blue on a page built to tempt it: Add to Cart and Checkout shared a class, a badge and the nav link shared the accent variable. Every run added an id-scoped rule. Checkout stayed green. Appending "Do not change anything else" changed one thing: the five runs with it wrote the hex inline where nine of the other ten had added two CSS variables. A path rule fencing off every file but the stylesheet never fired.

Real repositories look different. One benchmark pre-applied the fix to 200 issues and reopened them for five recent models in their vendors' harnesses. The right patch is empty; 35 to 65% of instances got an edit to executable code anyway, and in the authors' analysis of one model's failed traces, 87.1% had modified code unrelated to the issue. Task wording moved that figure a long way in both directions. Telling the agent to "edit the codebase" dragged one model's correct-abstention rate to 36.5%; reproduce first, then fix or abstain if nothing was wrong, lifted it to 88.5%. Their explanation: the agent acts on whatever it believes success means.

The harness side: switch on auto-accepted edits in both CLIs whose docs we read and the grant is the whole working directory. A path rule brings that down to files; one vendor's docs state that it applies to the built-in edit tools and recognized shell commands, and that a script opening a file itself is outside it. A selector inside a permitted file sits below every layer's resolution. Whether the blue landed on one button or on every primary button is decided by the sentence you typed and by whoever reads the diff.

When your agent overshoots, where does the boundary live in your setup today: the prompt, a rule file, a path rule, a sandbox, or the person reading the diff? Which of those has caught a change for you inside a file the agent was allowed to edit?

Hey Makers,
Every AI tool is shipping its own version of "skills" now: Claude Skills, ChatGPT's skills and custom GPTs, saved prompts, agents, and so on.
I've built maybe a dozen skills across Claude and ChatGPT at this point. I use two of them. The rest looked like a great idea the day I made them.

That made me wonder whether it's just me, or whether skills are one of those features everyone sets up and nobody really lives in.

So just wanted to hear it out on your side:

• Which ones do you actually use, and for what?

• Did you write them yourself, or are you running someone else's?

• Has a skill ever spread through your team, or do they stay personal? If you've shared one, how? Repo, Notion page, pasted into Slack?

• If you stopped using them, what was the reason? Too fiddly, didn't trust the output, or just forgot they were there?

I ve seen launches get attention at very different times, so I m curious how much timing actually affects discovery now.

Do makers still plan around a specific launch day and time, or is the quality of the product and ongoing activity more important after launch?

Is there a setting for this? Because my eyes sting while browsing.

Logged my work time for a few months and the stats were pretty embarrassing. Turns out "doing research" and doom scrolling tech news was taking up almost a fifth of my day while actual user calls were under 10%.

I always felt busy but looking at the spreadsheet proved I was just wasting hours on passive stuff.

For anyone who tried tracking their time like this did seeing the raw numbers actually fix your habit or did you slide right back?

I've tried the build-in-public thing a few times. Sharing milestones, posting screenshots, writing little updates. And honestly? I'm not sure it ever moved the needle. A few likes, a couple of "this looks cool" replies, zero meaningful signups.

I see others do it and they seem to get traction from it. But I can't tell if that's because they have an existing audience, or because their updates are genuinely interesting, or because they've just been doing it consistently for years.

For anyone who's actually seen build-in-public convert into users or revenue: what was the specific thing that worked? Was it a particular format, a platform, a frequency? Or is it mostly just a slow compounding thing that only pays off over a long time?

AI notetakers are dumb... like, they just transcribe and summarize...

I'm trying to build something that's actually an online assistant that, being wired into your calendar, emails, and knowledge base, and with that it can actually support you during meetings with things like:
- live capture tasks

- find available times for the next meeting
- live capture tasks (and even prepare prompts before and hand off prompts to Claude before you hang up

When i first started using productivity apps I thought i d stick to one simple system and never overcomplicate it.

A while later I somehow ended up with different apps for notes tasks reminders and random ideas. Some of it is useful but sometimes I wonder if I m just creating more work for myself. How do you tell when your system is actually improving versus just becoming more complicated?

When I first started building things I thought adding more features would always make the product better.

Then I realized every extra feature also adds more decisions suppor and things that can break. Sometimes the hardest part is knowing what to remove. How do you decide when a product needs more features versus when it just needs to be simpler?

We kept our high-tier enterprise plan pricing hidden behind a sales call form, thinking it would give our sales team leverage to negotiate bigger contract sizes. Instead, it was driving mid market prospects straight to our competitors who listed transparent pricing upfront.

Once we published clear, fixed enterprise tiers on our pricing page inbound qualifies leads actually increased rather than dropping off.

For founders targeting B2B clients: does transparent enterprise pricing build trust or does it cap your maximum deal size?

How do you all come up with a name when you're launching something new?

For me naming is always the hardest part. I've named around 30 products so far and this is roughly my flow:

- One sentence on what the product actually does, not the feature list. Most of my names come out of that sentence

- Then names from anywhere. One of my apps basically stands in for you, so it became Kagemusha, a Japanese word for a double. Short, and no AI or Pro stuck on the end

I don't mean the ones you tried for a weekend. I mean the one that stuck.

Mine is omp (oh-my-pi), an open source coding agent that runs in the terminal. I use it for most of

my coding now. I still decide what gets built, but I barely write glue code or config by hand

Our API lets a customer register a URL we call when an invoice is paid. The whole job of that feature is to make a request to an address a stranger chooses, so the check on the address is the security of the feature.

The first version did what most guides say. Allow only http and https, resolve the hostname, and refuse it if PHP filter flags for private and reserved ranges reject the address. Those flags cover the ranges everyone remembers: 10.x, 192.168.x, loopback, and 169.254.169.254, where a cloud server hands out its own credentials to anything that asks from inside.

The first hole was the resolver. The function we called returns IPv4 records only. The HTTP layer resolves the name again and will happily connect over IPv6. So a hostname with a public IPv4 record and a loopback IPv6 record passed the check at registration and again at every send, with no timing trick involved. The fix was asking for both record types and refusing if any single address fails.

The second hole was the flags themselves. Checked one at a time rather than read off a table, six ranges pass them. Four are merely odd, like the shared address space some clouds use for internal networking. Two are translations: a NAT64 address and a 6to4 address can each carry 127.0.0.1 inside an IPv6 address, and a gateway will translate it back. Both passed everything. They now sit in an explicit deny list beside the flags.

When you start getting regular users, everyone asks for random additions that sound good in the moment.

Slowly you look up and realize your simple app is turning into a bloated tool you didn't even want to make in the first place.

Where do you draw the line between listening to real feedback and just saying no to keep the app simple?