Connect with the Product Hunt community

I work on several client projects plus my own products, and most of the work now goes through AI agents (Claude Code, Codex) in the terminal. A lot of what the agent needs isn't code, it's documents: specs, meeting notes, spreadsheets that live in Box, Google Drive or a local folder.

The friction: every time a task touches a document, I leave the terminal, click through Finder subfolders or open Box in the browser, find the file, download it, then hand it to the agent. It's slow and it breaks my focus on the actual task.

What I do today: I built a small picker for myself, so I type @ plus the first letters of the file name in the terminal and the path goes straight to the agent. (Disclosure: I'm the maker of PMDesk, so I'm biased. This is only my own impression, I haven't timed it.)

I'm curious whether that's actually the best approach or just my habit. Two things I'm unsure about: do you keep project documents inside the repo or outside it, and how do you make sure the agent is reading the right, current file?

Lowering prices because of exit survey data is a classic trap.

If a tool saves someone hours of work they won't care about a twenty dollar price tag, but if it lacks a key integration, no discount will keep them around.

The hardest part is getting them to reply once they've already canceled and moved on to another tool.

Did offering a small gift card or discount help increase your exit interview response rate?

The users who email you angry or leave detailed feedback are actually doing you a favor even if it hurts. You can learn from them.

The real ghosts are the ones who quietly downgrade, cancel via the billing portal, and ignore every single automated exit survey you send. You're left staring at a dashboard with zero qualitative context on why they left.

For SaaS builders: what creative strategies or prompts actually get silent churners to tell you what went wrong?

There's this weird pressure in tech where being available 24/7 is treated like the ultimate badge of honor. I tried stepping back from answering every random comment and non-urgent email right away, and honestly, half the people just went ahead and figured the solution out on their own. It made me realize how much time I was wasting babysitting threads that didn't need me.
Have you ever tried going radio silent for a few hours, and did anything actually break when you did?

There's this weird pressure in tech where being available 24/7 is treated like the ultimate badge of honor. I tried stepping back from answering every random comment and non-urgent email right away, and honestly, half the people just went ahead and figured the solution out on their own. It made me realize how much time I was wasting babysitting threads that didn't need me.
Have you ever tried going radio silent for a few hours, and did anything actually break when you did?

We designed our product to solve a specific enterprise problem, but our early adopters ended up using it for a completely different lightweight use case. While it brought in users our revenue model and positioning didn't align with how they were actually using it.

Pivoting your messaging to match user behavior can be tricky when it changes your entire ideal customer profile.

For founders who have faced a mismatch in product vision versus user reality: did you double down on the unexpected use case or re position to target your original vision?

A confirmation dialog seems like an easy way to prevent mistakes.

But think about deleting something in a product you use every day.

You click delete, get a warning, confirm, and move on. After seeing that dialog enough times, you probably stop reading it.

I ve been looking at this more as a recovery problem than a prevention problem.

We launched with simple predictable flat-fee pricing model to make onboarding as frictionless as possible for early customers. It helped us secure our initial user base quickly, but now a small percentage of power users are consuming 90% of our cloud infrastructure and customer support time. Moving them to a usage-based tier feels necessary for our unit economics, but we are terrified of sparking a massive backlash from the very people who championed our product from day one.
What is the best playbook for shifting heavy users to consumption pricing without looking greedy?

A while back, I threw together a tiny script in a couple of hours just to fix a small personal annoyance. No long-term plan, no roadmap. Years later, it s still running, and I still get occasional emails from strangers using it. Meanwhile, the bigger startup ideas I spent months planning with actual business models ended up going nowhere. It taught me that you really can't guess what will resonate until you just put stuff out there. Have you ever had a tiny weekend build outlive your actual planned projects?

A while back I noticed a steady stream of bug reports coming in every week. My first instinct was to blame tech debt and start rewriting logic. But when I took a step back and walked through the exact screens users were complaining about I realized they were just guessing how the feature worked because our error messages were useless. We spent a few days fixing the empty states and making the onboarding clearer and the complaints instantly dropped. It made me realize how easy it is to blame the code when the real issue is just poor design communication.

Do you track why users get stuck or do you jump straight into code fixes?

There is something strange about how we build things. Whenever I spend weeks sketching out features, setting up fancy task boards, and thinking about growth strategies, the project usually dies within a few months. But when I just spend a Saturday night messing around with a fun code idea without worrying about the final outcome, it somehow finds a real audience.

I think when we stop overthinking and just create things for the pure fun of it, we end up solving real problems more naturally. How do you decide which random side ideas are worth shipping versus the ones you carefully plan on your roadmap?

Early on, I thought customer support requests were basically my product roadmap. Whenever a few users asked for a custom toggle or a specific export option, I d rush to build it thinking it would boost retention.

Fast forward a few months, and the UI felt bloated, new users were confused, and nobody was even using those extra features we spent weeks coding. It turned out the initial request was just a surface-level fix for a deeper problem they couldn't clearly explain. Now, before adding anything new, I force myself to ask "why" three times until we find the actual gap.

For those managing an active user base, what's your personal rule of thumb for deciding if a request is a real product gap or just a one-off request from a noisy user?

I spent an entire weekend tweaking border radiuses, shifting buttons two pixels to the left, and changing color palettes on our site. It felt super productive. But if I'm being honest with myself, I was just hiding behind CSS because I was terrified of doing customer discovery calls. Changing a font won't fix a product that nobody actually needs. Have you ever caught yourself doing "fake work" on your app just to avoid facing the uncomfortable stuff?

With how fast code changes now especially with speedier refactoring tools our setup guides get outdated almost the next day.

A new teammate steps in follows the docs and immediately hits errors because the code moved on while the README stayed frozen. Making people update docs during PRs sounds nice in theory but it usually gets ignored when everyone is moving fast. How does your team force or encourage docs to stay accurate without slowing down shipping speed?

Hi Buddies,

I am trying to create a framework that can rollback Agent workflow when it is getting diverted from the actual workflow.
So, this framework detects any deviations and immediately it will rollback the changes done in last iteration.

Building fast feels great until something breaks and you realize you don't actually know how the underlying system works.

Asking if you could rebuild it yourself is a solid sanity check before sinking more time into a feature.

I usually treat AI code as a quick proof of concept and then re-read every generated line before moving it into a core branch.

Have you ever had to completely throw away a working AI prototype just because the code was too messy to scale?

I had a point where automated memory started dragging old context or weird habits from past sessions into brand new chats and half my time went into correcting it. Turning off automatic memory and just keeping a simple local file for important project notes felt like a huge relief. It s way easier to clean up a text file than trying to untangle what an algorithm remembered for you.

How do you manage your project notes across different sessions do you let the tool remember everything or do you keep a manual log?

It's so easy to get high on the dopamine of seeing signup numbers tick up every Monday morning, even when most of those users never log back in after day three. We hit a wall when we realized our massive growth spike was just filling a bucket with a hole in the bottom. Getting the team to stop caring about vanity metrics and actually fix the onboarding friction took a real mindset shift. If you've been through this, what metrics finally forced your team to wake up and focus on actual usage instead of just new signups?

I spent all morning crafting the "perfect" thread about productivity, watching the likes roll in. It felt amazing. But zero people signed up for our product. I was hiding behind keyboard validation because sending cold DMs or jumping on sales calls gives me instant anxiety. Likes don't pay the server bills. Have you ever caught yourself confusing social media applause with actual business traction?

I spent the last week migrating our stack to a trendy new tech stack, convincing myself it was for "scalability." Truth? Our current database handles our 10 users just fine. I was just scared to look at our feedback churn logs and ask people why they canceled. Clean code doesn't matter if nobody wants the product.
Have you ever refactored working code just to avoid difficult customer conversations?

Our product was originally built for individual creators who loved the instant sign-up and self-serve checkout process. Lately, though, larger enterprises are reaching out asking for custom security reviews, SSO, and dedicated account management. We want to move upmarket to capture that revenue, but building out these enterprise-only gates is starting to clutter our lightweight product roadmap.
How do you pivot toward enterprise sales without neglecting the solo users who made your brand cool in the first place?

It s easy to get trapped into doing free work when small client requests trickle in after a project is done. The real pain is trying to reset boundaries with someone who is already used to getting small tweaks for free.

If you've been in this spot how did you bring up billing for extra work without making it awkward?

Did batching requests work better for you or did you just start billing an hourly rate for every single small change?

During our year-long private beta, we promised our first wave of users free access in exchange for their honest bug reports and feedback. That partnership was invaluable for shaping the product, but now that we are officially launching commercially, those same beta users expect their accounts to stay free forever. Introducing a paid billing wall to our day-one supporters feels like a betrayal of trust.
How do you successfully introduce pricing to a community that has known your product as completely free since its inception?

Customer feedback is essential for us building a B2B SaaS product, but not every requested feature belongs on the roadmap.

We currently evaluate requests based on:

• Whether several customers have the same problem

• Whether the request supports the product s core use case

• How much value it would create

• The ongoing cost of maintaining it

The difficult case is when an important customer requests something valuable that only applies to their particular workflow.