Connect with the Product Hunt community

Whenever I share something I m working on, the feedback comes in all directions. One person says it needs more features, another says it s already too complicated, and a third wants a completely different design.

Last month I changed a small feature because three people asked for it in the same week. After the update, nobody used it, and the people who had asked never came back to try it. I realized I had counted requests instead of asking who really needed it.

It made me wonder if I m too quick to act on feedback just because it s loud or repeated.

How do you decide which feedback is worth acting on? Have you ever built something because people asked, only to find they didn t use it?

First, we tried decreasing first response time.

We refined the template, used automation for easy answers, and carefully measured the response time.

The number seemed great.

However, customers were creating additional queries as the first response didn t solve the problem.

In the early days, everything from customers seemed like an urgent request.

We'd throw in little tweaks, integration hooks, options and workarounds because saying not yet was the equivalent of not listening to our users.

And the product became more complex and difficult to understand and maintain along the way.

Today, we always ask ourselves three things before building a feature:

The car did a graceful fall more so than full-flight, and that too with the correct height, speed, friction of the ramp, pressure, etc/ all calculated meticulously to make it happen with multiple thrusters. Even if they are able to build this fully within the next 20 years, would such a vehicle be safe to have on the road?

I've been the sole developer at a startup for close to two years now. No code reviews, no one to ask when something breaks at midnight, no second opinion on architecture decisions.

The hardest part wasn't the coding itself. It was making decisions with no feedback loop. You ship something, it either works or it doesn't, and there's nobody to tell you if you did it the right way or just the way that happened to not break.

I've started keeping notes on every major technical decision I make what I chose, what I considered, and why. It's the closest thing to a code review I've found when you're solo.

Curious how other solo devs or tiny-team builders handle this. Do you just get used to it, or did you find something that actually helps?

In the early days, it s tempting to keep driving top-of-funnel traffic to see sign-up numbers grow. But if only 10% of those sign ups actually activate and get value pouring more traffic into the funnel feels like pouring water into a leaky bucket.

On the flip side, pausing marketing to fix activation with a small user sample size makes it hard to gather enough statistical data.

How do you balance top of funnel growth with product activation during the first few months after launch?

When looking at our user session replays, we noticed a trend: users who didn't experience the main benefit of the product within the first 3 minutes almost never returned. We tried adding guided walkthrough tours, but most users just clicked Skip as fast as possible.

It made us realize that users don't want to be taught how to use a tool they tool just want to get to the result immediately.

How did you streamline your onboarding to get users to their Aha moment faster? Did you strip away setup entirely or show dummy/pre populated data first?

Struggling to get recurring subscribers, we launched a limited Lifetime Deal on a deals platform to raise quick capital. It brought in $15k in two weeks, which helped us fund infrastructure and product upgrades.

Six months later, those lifetime users accounted for 70% of our active support load while bringing in zero recurring revenue to sustain server costs.

Are Lifetime Deals a smart way to bootstrap early development, or do they create a long-term debt that ruins SaaS economics?

We started with a 14 day free trial, assuming urgency would push users to explore the tool deeply. Instead, most users signed up, got busy with work, and returned on day 13 asking for an extension because they never had time to test it properly.

Switching to a limited freemium model gave them breathing room but conversion to paid slowed significantly.

For founders who have tested both models: which one worked better for your product archetype, and how did you balance urgency with user activation?

During a recent round of feedback calls, our power users requested a workflow feature that would fundamentally change how our product operates. On paper, it solves a big problem for them but it moves our app away from the simple, focused solution we set out to build.

Balancing listening to your customers with sticking to your core vision is much harder in practice than in theory.

How do you handle conflicting user feedback? Do you adapt your roadmap to high value requests or stay firm on your original vision?

When we launched our lowest tier, the goal was simple: lower the barrier to entry and get as many people through the door as possible. But looking at our churn data, this group had the highest churn and required the most support time.

It made us wonder if we were solving the wrong problem maybe a lower price point just invites users who aren't fully committed to the solution.

For those running SaaS products, how did you find your ideal entry pricing? Did you end up raising prices to filter for intent or did you keep a low entry point to build top to funnel momentum?

Early on, every time a user asked for a feature, we put it on the roadmap. We thought we were being customer obsessed. But a few months in, our clean dashboard turned into a cluttered menu, and new users started dropping off during onboarding.

Stripping back features felt terrifying because we were afraid of losing active users, but keeping them was confusing every new signup.

How do you decide when to say no to feature requests? Have you ever had to sunset a feature to save the core user experience?

Been working on a solid product n the launch of the product, but what's that we need to do to have a sustained spike and retain users who come in to explore the platform and convert them into power users.
Been thinking about this and working closely with teams who have launched in the past and gone through the same problems, Happy to have this thread open to record my findings/ strategies. If there are specific questions, do post, happy to chat!

Set a bunch of strict rules for myself when starting out about keeping things simple and never taking quick shortcuts.

A couple years in half of those rules are gone because real life hit and decisions got way more complicated.

How do you tell if you're just adjusting to real business needs or actually losing your original vision?

been thinking about this while working with LLM-based agents.

We still use retries, fallbacks, state machines and routing logic to make agents more reliable. But with newer models getting better at tool calling and handling failures, I wonder how much of this we really need to maintain ourselves.

Personally, I'd still keep permissions and critical actions deterministic. But for things like deciding the next step or recovering from a failed tool call, I'm not sure we need to hardcode everything.

Curious how others are handling this in production. Have you actually removed orchestration logic because newer models handle it better or has the complexity just moved elsewhere?

While building a competitor monitoring tool, I'm finding that collecting updates is the easy part. Deciding what matters is much harder.

If a competitor cuts its price, adds a major integration, or changes its positioning, how do you decide whether to respond? Do you have a rule for separating a real market signal from noise? Have you ever ignored a competitor move and later realized it was the right, or wrong, decision?

One thing I find tricky when designing AI products is deciding when the product should just act and when it should ask the user first.

Asking for confirmation feels safer, especially when AI is making decisions or changing something for the user.

But if every action needs confirmation, the experience quickly becomes annoying. At some point, the user is basically supervising the AI instead of benefiting from it.

I don t think the answer is simply confirm important actions, because what counts as important can depend on the user, the context, and whether the action can be reversed.

I kept convincing myself I was fine because tasks were still getting shipped but taking calls on weekends and working past dinner slowly drained all my energy.

I didn't need a long vacation I just needed to stop letting work leak into my evenings.

Taking a full step back and enforcing a hard no work rule after a specific hour made a massive difference in my sleep and overall focus within a month.

How do you keep small work exceptions from turning into permanent bad habits?

I did not notice I was burning out until I was already there. There was no single moment. It was a series of small things that individually seemed reasonable:

• Answering one message at 11pm because it would take 30 seconds

• Skipping one workout because there was a deadline

• Taking one call on a Sunday because the timezone worked

• Not taking a day off because nothing was on fire

Each one was defensible. Together they were a slow leak. By the time I noticed, I had been running on fumes for months and had convinced myself I was fine because I was still shipping.

The thing that helped was not a vacation. It was writing down a hard rule: no work after 8pm, no exceptions, for 30 days. The first week was uncomfortable. The second week I started sleeping properly. By the fourth week I was making better decisions and had stopped dreading the morning.

I love using AI to speed up boilerplate and early prototypes, but after a few iterations, the code always feels untidy and hard to manage.

It feels like every time I ask AI to fix a small bug, it rewrites parts of the logic in a completely different style, making the whole file messy.

For those using AI tools in production daily: what is your personal rule or workflow to prevent AI from creating a mess in your codebase?

Early on, I thought if users loved the product and gave great feedback, retention would take care of itself. But after sending our first renewal notices, the reality hit differently.

The hardest part was realizing that the end-user loving the product isn't enough. People are canceling not because they dislike the app, but because they can't quantitatively prove its ROI when budgets get tight.

For founders managing paid tiers: how do you adjust your product or messaging to help users clearly demonstrate value to their decision makers?

Many agent demos work well. Then in production, one confused loop calls the same tool 40 times and the bill jumps overnight.

Before I let an agent go live, I add three limits:

1. Max steps: stop after about 10 loops and hand over to a human.

2. A timeout on every tool call, so one slow API cannot hang the whole run.

Our e-commerce catalog was suffering from low search visibility because hundreds of pages had identical manufacturer-provided descriptions. Google bots simply ignored the text treating our category pages as low-quality content.

We solved this by writing a script that pulls customer review highlights most frequently asked questions and top use cases into a dynamic FAQ section on each product page.

Within a month of updating our fifty pages organic impressions doubled as unique keyword combinations started ranking naturally. Search engines reward pages that offer contextual value rather than copied manufacturer text.

What tools do you rely on to find keyword opportunities, in competitive product categories?

Silent failures are the absolute worst especially when users rely on sync data for daily workflows. But spamming someone over a temporary 5-minute API downtime is just as bad.

I usually prefer a quick retry loop behind the scenes first. If it s still broken after an hour, flag it in the app with a timestamp.

Though if it's a dead auth token that probably needs an instant heads-up since retries won't fix it anyway. How do you guys decide that threshold?

I have a pattern. I start things privately, work on them in secret, and abandon them quietly when they get hard or boring. Nobody ever knows, so there is no cost.

Last year I broke the pattern by accident. I mentioned a project to someone in passing, and they asked about it two weeks later. Just a casual question, how is it going. And it was going badly, but I did not want to say that, so I went

home and made it less bad.