Connect with the Product Hunt community

I used to waste way too much time looking for clever distribution tricks or viral loops, hoping I could skip the slow grind. But whenever I see a success story broken down the hack usually turns out to be pretty hands-on work personally onboarding users replying to feedback and actually writing good content.

Sometimes calling basic consistent marketing a growth hack makes it sound like there's some secret shortcut to traction.

curious if anyone here has seen a tactic actually work long-term that wasn't just good old-fashioned work in disguise?

We thought sending daily status emails and automated triggers would keep our app top-of-mind for users. Instead, a bunch of people told us in their exit surveys that the constant inbox noise was the exact reason they unsubscribed. They actually liked the tool but they hated feeling spammed every single morning. We switched everything to a single weekly summary and let users opt into alerts only when something critical breaks.

Have you audited your automated emails recently to see if they're actually helping or just driving people away?

When a free user bounces, it's a data point. When a paying customer cancels, it feels personal.

We realized most cancellation feedback wasn't about bugs it was about our tool failing become a daily habit. Fixing workflow fit is harder than shipping code.

Does the sting of churn ever go away, or do you just analyze exit feedback faster?

We built automated alerts, summaries, and email digest triggers thinking we were keeping users engaged. But cancellation feedback showed the exact opposite.

Instead of bringing users back our notifications were creating inbox noise, causing users to mark us as spam or cancel just to clear their mental clutter. They liked the product, but hated the daily noise around it.

For founders who have optimized re-engagement: how do you design smart notification frequencies that build habits without causing fatigue?

Hi guys, if the demo at a product launch dinner doesn't go well, due to some errors/issues, how do you deal with it? A lot of time is spent on invited investors, other company leads, prospective customers, etc. and it's disheartening when the demo doesn't go as planned. How to deal with this?

One of the things that I have done is instruct my assistant to give me an algorithm, data-structure, distributed-system, or system-design problems that align with my current project.

The goal is to define invariants, choose the structure, reason about complexity and failure cases, rather than have the assistant do all of the thinking.

Some that I recently worked on:

• Counting Bloom Filter design for a specified false-positive rate, deletion, counter saturation, and memory constraints.

• Consistent Hashing with Virtual Nodes distribute agent jobs/provider traffic while minimizing reassignment when workers enter or leave the pool.

• Topological Sort + Cycle Detection for Agent DAGs validate dynamically assembled agent workflows, detect illegal dependency cycles, and produce a valid execution order.

• Weighted Reservoir Sampling select representative evidence/content from a stream under bounded memory when items have different priorities or relevance weights.

• Interval/Dependency Graph for Evidence Invalidation propagate a changed or revoked source through dependent claims, proposals, approvals, and released artifacts without recomputing unaffected branches.

No first paying customer here yet, so this is less a story and more a suspicion I want to test.

When you start out, the first people you talk to are usually people who already like you. They re warm, they totally get it, and they say they d use it.

I m starting to think those conversations are great for learning and terrible for validating. People who like you are bad at telling you they won t pay.

It's so easy to fall into the trap of automating everything just because you can write a script for it.

I automated our weekly invoice sorting process but it turned out that going through those files manually was the only time I caught subtle client trends and bugs.

Once it became fully automated, I stopped looking at those details altogether. Are there certain tasks you purposely refuse to automate now because you need eyes on them?

During our days we would send surveys asking our users what new tools they wanted us to add to the platform. We ended up building a reporting dashboard because a dozen vocal customers requested it.

After spending three weeks developing the dashboard only two of those customers actually used it more than once. We learned the way that customers are excellent at identifying their frustrations but terrible, at designing software solutions.

We changed our feedback process to focus entirely on their workflow instead of feature wishlists. Now we only ask them to describe the tedious part of their week or the task that takes them the longest to finish.

This subtle shift gave us a deeper understanding of their underlying problems. We recently built an automated export function based on workflow feedback and it immediately became our most popular feature of the year.

When we released our public beta our inbox filled up with excited users asking for custom integrations, dark mode and complicated export formats. We spent three weeks building the popular feature only to see no one use it.

We found out that users suggest solutions based on their specific limited workflows, not the main problem they are trying to solve. They ask for a horse when they really need a car.

We changed how we handled feedback to ask "what are you trying to accomplish today?" Of "what feature do you want next?". That change uncovered hidden problems we never would have found from lists of feature requests.

Pay attention to user frustration. Think of their suggested features as signs of a problem, not the problem itself.

I logged every indexing API notification for 58 days. 551 total. 187 were for pages already indexed weeks earlier. My sitemap was regenerating on every deploy, so the API kept seeing "new" URLs that were unchanged.

I gated the build behind a content hash. Notifications dropped to 12 the next week. What's your duplicate notification story?

Launch day is exciting, but traffic can fade fast. For those of you who ve launched, what did you do in the first 15-30 days that made the biggest difference to retention and expansion of user base?

I m especially curious whether things like free credits or referral rewards moved the needle for you, or whether community and onboarding mattered more. I'm thinking of going down the free credits route but would love some inputs.
Would love to hear what worked and what didn't.

I ve tried quite a few AI tools recently but I noticed I keep using only two or three of them. Some look useful when you first try them but after a few days they just sit there unused. How do you decide whether an AI tool is actually useful enough to keep using?

Focusing on signup momentum feels amazing early on, but cancellations hit differently once revenue is involved.

We used to celebrate new user milestones. Then the paid tier launched and churn taught us a lesson: people don't leave because of missing features. They leave because our product didn't fit into their daily workday routine.

Fixing actual workflow friction is the real bottleneck.

Do experienced founders get used to churn, or do you just build faster ways to analyze cancellation reasons?

A few years ago, juniors cut their teeth on writing basic CRUD endpoints, fixing simple UI bugs, and writing unit tests. Now, an LLM can spin those up in ten seconds. Because of this, companies are raising the bar for entry-level roles to what used to be mid-level expectations, locking fresh grads out entirely. We started a micro-internship program focused purely on code review and refactoring AI output, and it completely changed our talent pipeline.
How is your organization adjusting its junior hiring model now that AI handles the boilerplate?

It feels great seeing high signup numbers every week, but watching 60% of a specific user segment churn after month one is demoralizing.

We realized these users were signing up with expectations our tool was never built to solve. They churn not because the product is bad, but because they were the wrong audience from day one and their feedback was polluting our roadmap.

How do you implement qualification gates or repositioning early in the funnel without turning away good prospects?

It's so easy to use "we need more features" as a comforting excuse when retention dips, because building a feature feels like productive work.

But a lot of the time churn happens simply because the tool creates extra steps instead of removing them.

If a user has to break their daily routine just to fit your software into their day they're going to bounce no matter how good your roadmap looks.

What specific questions do you ask during churn feedback to get past the fake excuses and find the real workflow problem?

When customers ask for features, our instinct is to build them to keep everyone happy. But over time, our core product started feeling cluttered and overwhelming for new paid signups.

The hard truth is that every new toggle or tab adds cognitive load. Users aren't canceling because we lack features; they're churning because the tool started feeling like work instead of solution.

For founders who have pruned their product. how do you balance power user feature requests against keeping the core experience clean and friction-free?

Doing a massive refactor that ships zero new features is mentally exhausting especially when your task board stays completely static for days.

It feels like you're falling behind while everyone else is shipping cool stuff. But you're so right about the payoff later touching that messy code cuts your future development time in half.

My biggest struggle is always justifying that time to stakeholders who only care about feature lists.

Do you have a specific way you pitch clean-up work to keep the pressure off?

This hits way too close to home. I used to give textbook technical answers to client bugs, only to realize later that their entire architecture was completely different from what I assumed.

Giving the technically right solution for the wrong setup just creates more confusion. Now I try to make them explain their whole workflow first before writing a single line of code.

Have you found a good way to steer users away from asking the wrong technical questions in the first place?

Starting a new app with AI is easy. Editing an old project is where I see things go wrong: it rewrites a file that was fine, ignores the existing structure, or changes something nobody asked about.

What do you give it before it touches the code? A short notes file, the folder structure, a list of files it must not change, or just the task?

Building a startup is hard. Proving you exist to an algorithm is apparently harder.

I'm a solo founder building an iOS social app. Somewhere between shipping the product, finding users, fundraising, and maintaining LinkedIn, Product Hunt and a dozen other channels, being a founder has turned into a full-time job in being visible.

And here's the irony: my LinkedIn account is restricted, while its identity-verification flow keeps sending me in circles. My passport is a valid identity document, but the automated process hasn't given me a workable way to complete verification or reach a meaningful human review.

The issue isn't whether I can prove who I am. It's whether the system accepts the document I actually have.

I counted mine for a recent freelance project:

A Google Doc for the proposal, exported to PDF

An e-sign tool for the contract

Testing with friends and fellow developers is a massive trap.

They always tell you the app looks great and the idea is solid because they want to support you not because they actually face the problem you're solving.

We built an entire feature based on positive feedback from a non-target audience, and when we launched publicly real users didn't care about it at all. It took months to pivot back.

How do you stop yourself from listening to polite feedback instead of real market signals?

Getting nice compliments during beta testing feels amazing, but it gives you total false confidence.

The real test is whether someone is annoyed enough by their current workflow to pull out their credit card or log in every single day.

If your testers don't desperately need a solution their feedback on UI or buttons doesn't matter much.

Do you offer incentives to bring in complete strangers for testing or do you rely on communities like this one?