Connect with the Product Hunt community

We keep tweaking our signup steps to make it frictionless, but I'm starting to think a smoother form doesn't solve the core issue. People breeze through the steps and then never touch the core feature.

It feels like we're optimizing for the wrong metric if they aren't reaching that first "aha!" moment quickly enough.

For other builders: where did your biggest drop-off happen, and what specific change finally got them past it?

The initial spark of an idea usually starts with a grand purpose and a wave of high motivation. However, over time, this process can turn into a cycle of professional and psychological exhaustion. As the project progresses, the idea hits walls relative to its purpose and fails to align with the real world. Sometimes, you have to give up right in the middle of building it; other times, as time passes and the idea keeps coming back to you, you begin to think it was just a nonsense idea in your mind all along. Watching a concept you once cherished slowly disintegrate like this is a process that pushes you to your psychological limits. As a founder or product leader, how do you prevent your mind from manipulating you with these ideas?
When and how do you realize that an idea will actually work and that it isn't just a mental trap?

I run several coding agents on the same repo at once. Each change looks fine on its own. The trouble shows up at merge time: one agent replaces something another is extending, and Git has nothing to say because the lines don't overlap.

What do others do. One agent per repo? Strict file ownership? A human merging everything? Something else?

As a software engineer, I love how fast AI tools are advancing. But lately, keeping up with constant API updates, shifting model outputs, and breaking changes in frameworks feels overwhelming.

Are you finding that the rapid pace of AI releases is making your codebase less stable, or have you found a good way to manage it?

"I saw @busmark_w_nika mention in another thread that LinkedIn now scans AI-generated posts and may reduce reach for content that 'sounds the same.'

This got me curious I use AI for drafting but always rewrite the hook myself. Have any of you actually seen a drop in reach when using AI drafts vs. writing from scratch?

Over the last six months, we kept adding small features to cater to different user requests. Now, the navigation feels cluttered, and new signups are taking longer to reach their "aha" moment because there are too many options on the screen.

It feels counterintuitive to remove code you spent time building but streamlining seems necessary for long term growth.

How do you decide which features to sunset without frustrating your existing power users?

I've been double-checking app permissions lately and it's surprising how many basic utilities demand access to personal contacts or background tracking.

When a product explains why it needs certain info and lets you opt out without breaking core features, it builds way more trust. Sharing sensitive data by default just to try a new tool creates unnecessary friction during onboarding.

How do you decide if a software product actually needs your personal details, and what data do you strictly refuse to share?

This question has sat in the back of my head for months and I still don't have a clean answer.

For internal work the bar is forgiving. A draft brief with rough edges, a slightly off tone in a Slack summary, a CRM note that's 80% right. You fix it and move on.

I keep rewriting the same awkward email friendly at first, firmer two weeks later and I hate every minute of it.

The tools I've looked at want me to move my books into Xero or QuickBooks first, which is a much bigger change than I'm willing to make for this.

Curious how others handle it: do you chase manually, use a tool, or just let smaller invoices slide? And does what you do actually work?

Coding agents now run commands, read files and call tools with our own permissions, and most of us review the final diff rather than every step. For a while that felt fine to me.

Then I started recording every tool call my own agents made. Some of what it flagged in my own sessions was things I hadn't noticed at all, like a credential read followed by a call to a cloud API in the same session. Each turned out to have a reason, but I only knew because I looked. The transcript alone wouldn't have told me.

I'm curious how others approach this:

- Do you review what your agent ran, or only the result? Why?

Yesterday I checked a month worth of conversation with one of my AI (yes it was claude).
This month alone i shared with Anthropic my blood test results to figure em out and some legal contracts (back and forth) that I wanted to revise both manually and thru mr claude to double check. Those were the most sensitive ones among other information i sent within conversations. Search engines already knew a lot about me, i see that from ADs tailored to my preferences. Companies like this go beyond knowing your liking, with context, including private things.
I don t necessarily think that makes anyone a villain, as this is roughly the same trade we made with email and maps and photos, and most of us took it (I did at least) without much hesitation. What I notice is that I never actually decided how I feel about it, as it is me who decides what to share with them (more or less). So my question to you is where s your line? Do you think about what goes in, or is this a trade you ve already made? If none of it left your machine, what would you ask that you don t ask now? (you don t have to be specific haha)

Google Research released Harness2, and I think it reiterates an important direction for AI-native applications.

The idea is that the model isn't necessarily what needs to improve. It's the harness around it: prompts, tools, memory, skills, and orchestration.

Harness experiments with automatically improving that harness based on how agents perform on tasks, without retraining the underlying model.

A production error pointed to a null value. I asked the agent to fix it. It added a guard clause. Tests passed. Deployed.

Error came back because the guard was in the wrong layer.

Cleaning up technical debt feels satisfying until you realize that mysterious piece of ugly code was actually holding the whole feature together.

I used to delete anything I didn't immediately understand during a refactor thinking I was being efficient. Now I've learned the hard way that messy code doing vital work looks identical to code doing nothing at all if you don't check git blame first.

What's your current routine before you hit delete on a large block of legacy code?

When we launched our software year we set the price at nine dollars a month because we were afraid that nobody would pay more for an early stage tool. Signups came in fast. Our support costs soon grew faster, than our revenue and working late nights became unsustainable.

Of raising the price on the entire public landing page we ran a quiet experiment with new visitors. We added a forty nine dollar tier that included priority setup support. We expected the conversion rate to fall to zero. Surprisingly twenty percent of new users chose the higher tier.

The higher price attracted serious users who needed less hand holding and who valued the software s core utility. Our monthly recurring revenue tripled, even though the customer volume was cut in half proving that underpricing was our bottleneck.

How did you find the courage to raise your price. How did your early users react?

Each strategic initiative has its own goals and KPIs, but the data is spread across different teams and tools.

Before every leadership review, someone has to chase updates by email, wait for responses, reconcile numbers, and piece everything together.

The leaders I interviewed described reporting cycles that consumed 20 60 hours of manual effort. And by the time the information reached leadership, some of it was already outdated.

But what interested me most wasn't just the time being lost.

We route across a handful of models and on a spreadsheet the savings look obvious. The small model gets it right most of the time. The problem isn't the hit rate, it's the shape of the misses.

When a frontier model is unsure you can usually see it. The output hedges, goes vague, asks a question. When a small model is unsure it produces something clean, confident and wrong, and that sails straight past any eval checking format instead of truth. Nobody catches it until a user does.

Dragging a dead project along for months just because you've already put so much time into it is a terrible feeling. I've been there you know deep down after month two that the idea has no traction but you keep writing code every night just to avoid admitting it failed.

Deleting that repository hits hard because it feels like throwing away all those late nights.

Looking back what was the exact sign that made you finally kill your project instead of pushing through?

I m trying to understand what makes someone try a SaaS product and then stop using it after a few days.

Analytics can show where people drop off, but it doesn t always explain why. I think a short conversation with those users could help, though I m not sure what to ask without leading them toward an answer.

When a user is flagged by my safety layer, the app goes quiet for a while. I kept the whole rule in one pure function: it takes the user s recent flags and the current time, and returns whether they re paused, until when, and why. No database, no clock reads inside, and the lengths live in named constants (pause length, repeat window, minimum gap between two flags that count as a repeat).

The rule itself is small, but time rules go wrong at the edges: exactly at a boundary, two flags a minute apart, a timestamp with microseconds and a +00:00 offset. So I wrote 61 tests, then did something I now do for every rule like this: I broke the code on purpose, seven different ways, and checked that a test failed each time. I removed the minimum gap, counted flags I shouldn t count, measured a repeat from the wrong flag, made the pause read fail closed, and so on. All seven were caught. A test that has never failed proves nothing.

Two things the design review found before users did:

1. I first started the soft period (gentler messaging after a pause) at the flag time. That meant it ended the moment the longest pause ended, which is the worst time to switch back to normal. I moved the start to the pause end. That quietly broke something else: the database query only looked back as far as the old rule needed, so a repeat flag would have fallen outside it while the soft period was still running. The look-back had to grow to cover pause plus soft period plus repeat window. A test now fails if I shrink it.

2. Contact-form flags must not count as repeats. The table holds only a user ID, a level, and a time, and I didn t want a text column, so I added a single yes/no column instead.

For a long time we looked at total daily page views and the number of registered accounts as our main signs of growth. Those easy to see numbers made us feel good each morning. Did not tell us if people were getting real value from the software.

We stopped looking at of-funnel traffic completely and started focusing on one retention measure: whether a new user finished our main setup process within their first ten minutes. If they completed that step their thirty-day retention rate went above sixty percent.

That single measure became our guide for every product change and every engineering project. If a new design caused fewer people to finish the setup process we changed it back away even if it looked nice.

What one user action do you follow to check involvement, with the product instead of just simple activity?

I pasted a stack trace to the agent. It asked for the file. I pasted the file. It asked for the config. I pasted the config.

Forty minutes and 12,000 tokens later, it found a missing comma in a dependency injection string.

I asked Claude Code to rename a function across the codebase. It found 12 files, made the change confidently, and reported success.

What it missed: a thirteenth file in a directory outside its initial search scope. No warning. The app kept working because that file only ran on a rare edge case. I caught it three days later during an unrelated test.

I used to judge an AI prompt by reading its first response. If the result looked good I assumed the prompt was ready to use.

That approach missed a problem. The same prompt could produce different results with different inputs. A prompt that worked for a support question might fail when a customer described three problems at once.

Now I collect, around 10 examples before changing a prompt. I include cases, unusual requests, incomplete information and examples that previously produced poor answers.

For each example I write down what a good result should contain. A support reply might need the policy, a clear next step and a calm tone without promising something the company cannot provide.

I stopped sending automated churn surveys last month. Instead, I sent a plain-text email from my personal address to a customer who canceled their plan: "No pitch, no discount. Just curious where did we fail you?"

They replied with a 400-word breakdown of a UI flaw that had been subtle enough for us to miss, but annoying enough for them to leave.

It took us three weeks to fix it. The customer is long gone and won't see the fix, but our retention rate for new signups went up by 12% this month.

Do you actively hunt down brutal feedback from people who left, or do you prefer to focus only on active users?