Connect with the Product Hunt community

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?

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.

Looking at who pays in my app, the split by language surprised me. Spanish-speaking users convert at around 12%, Arabic-speaking users at about 2.5%, even though Arabic users found the app on their own and used it a lot.

I never localized the store page for either.

Is this mostly purchasing power, store pricing tiers by country, or trust in a small unknown app?

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.

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?

There is nothing quite as humbling as reading a cancellation reason that says: "Great product, but we just didn't use it enough to justify the cost."

It s not a bug, it s not a broken feature it s just indifference. But those brutal honesty suryeys have secretly taught us more about our product than all our positive user reviews combined.

How do you structure your offboarding flow to actually get honest feedback from churning users without annoying them on their way out?

Our freemium tier was meant to be our primary top-of-funnel acquisition engine. It worked too well.

Within six months, our customer support queue grew by 400%. Over 80% of our team s time was spent responding to free users asking for custom setups and bug fixes, while our paying customers were waiting 24+ hours for an answer. We were giving away human support to users who had zero intention of ever entering a credit card.

How do founders restrict support scope for free tiers without creating a toxic brand reputation or completely alienating potential upgraders?

When we first launched, we celebrated every activation milestone like a major win. But a few months in, we noticed a brutal pattern: users hit our "Aha!" moment, loved the onboarding, and still churned by week three.

Turns out, experiencing value once isn't the same as building a habit.

For those running SaaS products, how do you bridge the gap between initial onboarding and making your tool an absolute daily non-negotiable? Do you rely on lifecycle emails, in-app nudges, or something else entirely?

One hard lesson from onboarding paid users: people don't churn because you lack features. They churn because your tool disrupts their workday routine instead of simplifying it.

Fixing habit-loop integration is a much tougher challenge than shipping another update.

How do you bridge the gap between initial signup and daily routine adoption?

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?

Hey everyone :)

One thing I'm learning while building a product is that getting it built is only half the work. Finding the right people who actually need it is a completely different challenge.

I'm trying to understand how early-stage makers approach distribution without spending all their time posting everywhere or chasing vanity metrics.

I've been thinking about a few approaches, like sharing useful content, joining relevant communities, and talking directly to potential users.

I launched something last month and it went exactly as planned. No bugs, no drama, no backlash, a modest bump in signups.

And I felt nothing.

I spent a day trying to fix something and could not. Nothing worked. I tried everything I could think of.

Then I remembered I had deleted a block of code months ago because I thought it was useless. It was not useless. It was doing something I did not understand, and I had removed it because it was old and messy.

Early on, we assumed cancellation reasons were mostly financial that users just didn't want to pay our monthly fee. But looking closely at user drop off data revealed something surprising.

Most churned users never even hit their plan limits or core paywalls. They canceled simply because the setup effort was too high to reach their first aha! moment. Lowering prices or offering discounts doesn't fix a onboarding flow that takes 3 days to deliver value.

For founders who have tackled this: how do you redesign your onboarding or activation steps to get users to core value before they lose interest?

Building in public definitely turns into a performance after a certain point. Once you have an audience watching admitting that a feature failed or that you made a bad architectural choice feels way harder than it should be.

People online love giving loud opinions on things they aren't even paying for which can easily pull your roadmap in ten different directions.

Where do you draw the line now do you still share your early failures, or only the final polished updates?

This is such a real trap. When you share everything publicly you subconsciously start picking tasks that look flashy on a timeline rather than the boring bug fixes or database cleanup your app actually needs.

The vanity metrics feel good for a day but they distract you from the actual work. I stopped posting real-time stats and milestones completely for a while and my product velocity went right back up.

Do you keep a strict boundary between what you share on social media and what you work on behind closed doors?

It is so easy to fall into expert mode and just blurt out the most precise answer without checking the context. Most of the time, people do not need a complex technical breakdown they just want a quick workaround that fits their current mess.

When I am on the receiving end of those perfect answers, it honestly just makes me feel more stuck.

Do you usually ask follow-up questions right away or do you try to guess what their actual bottleneck is?

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

That middle of the training data problem is so real. If you don't actively push for diversity every generated image ends up looking identical.

My main issue when adding random weather conditions or film stocks was that the product itself started changing colors or losing its original branding details.

Did you have to lock specific seed weights for the product while letting the background parameters randomize?

It is so easy to fall into the trap of thinking that adding more text fixes bad outputs. We used to write massive instructions packed with edge cases and the model would end up ignoring half of them anyway.

Trimming everything down to clear bullet points and simple variables made the responses way more reliable. Cutting out the fluff really does force the model to focus on the actual task.

Do you prefer keeping your system instructions short or do you like adding strict guidelines for formatting?

Our Net Promoter Score was consistently sitting at a depressing 12, yet our revenue retention was over 110%. We were completely confused.

When we jumped on 1-on-1 calls with customers, we discovered that users found our product's interface ugly and clunky, but the core data it generated was so indispensable to their daily operations that they couldn't switch to a competitor even if they wanted to. They were paying us every month while actively disliking the daily experience.

If you've ever inherited a product with high utility but terrible UX: do you pause all new feature development to rebuild the interface, or keep shipping value and live with a frustrated user base?

AI agents are getting better at finding products and comparing options but completing a purchase is a different challenge. Cart updates checkout forms shipping details and payment verification can all create friction along the way. Has anyone tested an agent against a real checkout flow? I'd love to know where it gets stuck and how much human intervention is still needed.