Connect with the Product Hunt community

Unpopular opinion: AI coding tools are great at writing code and bad at leaving the rest alone.

Mine rewrote my config, renamed a folder, and changed how the app starts. The login page worked. The app didn t.

I shut down a project last month that I d been working on for about eight months. It had a handful of paying users, a few nice messages, and growth that basically flatlined after the first launch spike. The weird part is I probably knew it wasn t working around month four. I just kept telling myself one more feature would fix it.

Talking to other makers, I ve noticed two camps:

1. People who give something 90 days, check the numbers, and move on without much drama.

2. People (like me) who hang on way too long because quitting feels like admitting the idea was bad.

Would love to hear how you think about this:

When we landed our first big client paying $2,000/month, we were ecstatic. They were a massive logistics company, and they had one specific requirement: they needed a completely custom reporting dashboard that synced with their proprietary internal software.

We didn't want to lose the deal. So, my co-founder and I spent six weeks building this custom integration. It was a massive hack duct-taped together with webhooks and custom database queries. But it worked. The client was happy, and we had our first real revenue coming in.

Then the nightmare started.

Because we hardcoded this custom feature into our core app, every time we tried to push a new update, the custom dashboard broke. We spent the next three months firefighting bugs for this one client instead of improving the product for our other 150 users. Our overall churn rate ticked up by 5% because our standard features were falling behind, and the codebase became a mess to maintain.

Six months ago, we were desperate for cash flow to keep the lights on. We decided to run a Lifetime Deal (LTD) campaign. We thought it was a win-win: we get a quick cash injection, and we get hundreds of users to give us feedback.

It worked... at first. We made $5,000 in a single week. I felt like a genius.

But the reality check hit us hard over the next 90 days:

• Our support tickets exploded by 400%. LTD buyers were incredibly demanding, asking for custom features and 1-on-1 onboarding calls for a product they paid $49 for once.

• Our server costs tripled. Many of these users were uploading massive files and using our API heavily. We were now paying AWS $300/month to host users who would never give us another dime in recurring revenue.

• Our real MRR stalled. We got so bogged down supporting the LTD crowd that we completely stopped our outbound marketing and sales efforts.

At the very least, it was something I didn't need when I was doing a project alone. Most of my projects are just me. Only the client's team used such a tool, since there were 5 or more people working simultaneously and, starting from a free board tool, they had to track the hours of outside contractors too.

Later on, I found out that I do need it too. Now I have more than 30 projects going with AI agents and honestly can't keep track of where each one is, so all of it goes on a kanban board, the same way the client's team does it. My daughter's homework and class schedule are on a board as well.

How many people were on your team when you started using one?

I spent an hour reviewing a diff today where the agent decided my database schema needed a modern upgrade

even though I just wanted to add a simple validation check.

It s exhausting having to babysit the diff just to make sure it didn't touch background logic.

I build my app alone after my day job, with no ad budget. So far the only thing that really worked for me is writing short, personal posts on Threads. One story about my family got over 300k views and brought more signups than everything else combined. Posts that explain features barely get noticed.

But I can't tell if that was luck or something I can repeat.

Most vibe coding advice says to have the agent write the tests alongside the code. I think that's the most expensive habit in the whole loop.

The code and the test come out of the same reading of what you asked for. If that reading is wrong, both are wrong in the same direction and the suite goes green, which is worse than having no suite at all, because now you've got a receipt.

When you live inside your own product every single day, you forget what it's like to see it with fresh eyes. Every button, label, and navigation menu feels completely obvious to you.

Then we watched session recordings of our first few real signups. It was painful. Users were getting completely stuck on things we assumed were intuitive, dropping off before they even touched our primary feature.

For builders and indie hackers: what methods or tools finally opened your eyes to your own onboarding blind spots?

You ask an AI agent to research a competitor. You permit it to:

• Read public websites.

• Analyse information.

• Prepare a report.

It cannot contact anyone, send emails, or make external commitments. It delegates part of the research to another agent, which delegates again to a third agent. The third agent has access to email.

Issue: The agent hits an error and hides it so it can deliver the output the prompt asked for.

Example: An agent swallowed a failing database write and returned a 200 success payload. The UI told users their setup was complete while the database sat empty.

In the beginning, we focused heavily on smoothing out our signup flow, and activation rates looked great. But a few weeks in, we realized users were dropping off right after completing onboarding.

Getting users to see the initial value is one thing, but keeping them coming back to perform managing early retention: what onboarding or product changes made the biggest difference in turning initial activation into a daily or weekly habit?

We pull job posts from a few dozen boards and company career pages, and each one is keyed on its source plus that source's own id. That works inside one source and does nothing across them: the same opening can arrive from the company's own page, an aggregator and a recruiter repost, each with a slightly different title and location line. Matching on company plus title looks obvious until you meet one company with two genuinely separate Backend Developer openings in two cities, next to one opening titled three different ways. We still haven't found a rule we trust, so for now we let duplicates leak through rather than risk merging real jobs away. If you run anything that aggregates listings, products or events from many places, which signal ended up being the one you trust for deciding two records are the same?

We spent months building a loyal free user base who loved the core utility. But when we introduced paid tiers, conversion was much lower than we expected not because the value wasn't there but because users had already built daily habits around the free version.

Locking existing features behind a paywall creates friction, but keeping too much in the free tier slows down revenue growth.

For founders who have successfully monetized a free tier: how did you decide where to draw the line between free usage and paid conversion?

In most teams I talk to, the content exists: videos, docs, a Notion page. The problem is that half of it never gets finished, and nobody notices until something goes wrong. What s worked for you? Shorter formats, deadlines, nudges from managers, something else?

Over the past few days, I ve been following a heated discussion about how Marc Lou is selling parts of his body in some kind of simulation to promote products (ad placements in the form of virtual tattoos) and making a lot of money from it.

I swear, the whole thing has gone mainstream.

Since I started running Claude Code and Codex in parallel worktrees, my disk fills up much faster. Every worktree gets its own node_modules and build output, session logs pile up in ~/.claude and ~/.codex, and Xcode DerivedData does the rest.

I've seen people find 100GB+ of this stuff. How do you deal with it? Do you clean worktrees manually, script it, or just buy a bigger SSD?

It s funny how all our automated tests can pass with 100% green checks and yet a simple user action like hitting the browser's Back arrow completely breaks the app experience.

I spent hours debugging why an onboarding wizard kept dragging finished users backward because of how router pushes stack up in Next.js. Unit tests just don't catch browser level history states unless you're running heavy end-to-end browser tests.

For UI flows with multiple steps do you rely on tools like Playwright to test history behavior or is this just one of those things you catch manually by testing it yourself?

early on every request feels urgent because there are so few users. one person asks for something twice and it starts to feel like the roadmap. but a loud user and a common need look the same when you only have a handful of people talking to you. my view is the request matters less than the problem under it, and if three people describe the same problem in different words thats worth more than one person asking for the exact feature five times. curious how others draw the line. do you have a number, a rule, or is it mostly gut until you have enough users to see patterns?

When you're early post-launch, everyone has an opinion on what your product is missing. It's so easy to get pulled in five different directions trying to please the loudest voices.

I've caught myself almost rebuilding the roadmap just because two people asked for the same feature on the same day.

How do you filter out the noise and figure out which feature requests will actually move the needle for retention?

One thing I keep struggling with while building products is figuring out which features are actually worth spending time on.

I sometimes come up with ideas that sound great, but then I wonder whether anyone would really use them. I also don't want to spend days building something that people don't actually need.

I'm trying to get better at understanding user needs before jumping straight into coding.

For those who've built and launched products, how do you usually decide what to work on next? Do you talk to users, look at feedback, or just build your ideas and see what happens?

I feel like internal documentation has become a losing battle lately. Code changes endpoints move around, and setup configs tweak every few days but no one wants to pause momentum just to write static markdown files. Eventually onboarding becomes a game of "ask the lead dev on Slack" because the official docs are useless.

We're trying to figure out if there's a lightweight habit that actually sticks like auto generating API docs from code comments or keeping docs right inside the codebase itself.

If you work on a fast moving project what's one actual practical workflow that kept your docs from falling behind without feeling like a chore?

Something I keep running into: the work gets approved, everyone's happy, and then a week later comes "can we just tweak one small thing?" Then another. None of them are big on their own, but together they quietly eat the margin on the project.

I'm curious how others deal with it:

• Do you include a set number of revision rounds in the original scope, or handle each request as it comes?

• Is there a point where you start quoting post-approval changes as new work, and how do you say that without souring the relationship?

• Does writing down exactly what was approved (and when) actually help, or do clients just ignore it?

Would love to hear what's worked for you, and what backfired.

It took me a good while to figure this out. When my programming agent makes an error and I point out the wrong part, the correction doesn't vanish inside the chat log. It's saved as a file. So the next session never trips over the same issue twice.

So far the agent has written 100 incident notes. It also keeps memory notes in the project, one fact for each file. Each time a session starts, a one-line index of those notes gets loaded. If the same mistake happens again, it becomes more than a mere memory. It becomes a hook. And that hook runs on every tool call and every reply, regardless of whether the agent remembers it. I currently have 63 hooks.

A few of those hooks came from pretty ordinary situations. After long sessions in another language, the agent started replying in English. According to the note, the more English documents it had read recently, the higher the chance it would drift. So now, whenever a reply comes out in English, one of the hooks forces a rewrite.

Another time it claimed something was fixed without ever testing it. That led to a rule: it must write down exactly how it checked. Dash usage also got restricted.

Our earliest adopters built impressive custom habits around our product's initial limitations, using spreadsheets and manual exports to fill the gaps.

When we finally shipped the native automation to replace those hacks ,engagement actually dropped for a week because their familiar routine were disrupted.

For teams launching core updates: how do you introduce structural product changes without alienating users who rely on the old way?