Connect with the Product Hunt community

My aunt has the task of organizing volunteers at a local food pantry, using a spreadsheet that was filled in by phone. There would be overlapping shifts, people would disappear, and my aunt spent Sunday evenings trying to fix everything by hand. I offered to create a simple solution, not having any experience in programming.

I used Replit's assistant at the start but then switched to Lovable to have a clearer interface. The initial app allowed one to choose a shift and type their name into it, and it was done within an hour. Another hour of coding was spent solving problems I did not think of earlier: What to do when two people try to book the last shift at once? How can my aunt cancel a certain shift without contacting me?

As I work toward getting more people to use my product I've been building.

We spend so much time testing whether our software works. We check functionality, fix bugs, improve the interface, and make sure everything behaves as expected.

But I've started questioning whether we're always testing with the right people.

Last month we checked our internal collection of prompt examples and found instructions going past two thousand words. We thought more details meant results but our tests showed the opposite effect.

When directions get long models start missing important formatting rules hidden in the middle sections. Our output became more consistent only after we made those big sections shorter and used bullet points instead.

We learned to see prompts as code functions not as assignments. Keep the focus small explain input values clearly. Take out all the friendly conversation words.

A short instruction set makes the model use its knowledge instead of getting lost in different style rules. Fewer words often mean thinking.

Every time I ask for a simple bug patch the agent feels the need to reorganize half the directory and refactor utilities that weren't even broken.

It s like giving an over-enthusiastic intern a screwdriver and coming back to find they took apart the engine.

For those using Cursor or local agents daily, what s your go-to way to lock down scope and keep them strictly on task?

Early on whenever a paying user asked for a specific feature, my immediate reaction was to build it to keep them happy. Our roadmap became a messy patchwork quilt of random requests.

Eventually, I realized those feature requests were often band-aids covering up a confusing core UX or a deeper workflow mismatch. Building what they asked for didn't even stop them from churning later.

For founders managing small teams: how do you filter out the noise of individual feature requests and stick to your core product vision?

Me? Oh, for me it was definitely never a number. When I got my first job, I made my own lunch and used to eat it all by myself on the office rooftop. Partly because I didn't much like all the baseball talk at lunch, but mainly, of course, to save money. Then, about a year and a half later, I opened my own company. It has already been 22 years since then, and I still run the company myself.

So my conclusion is: it was about having enough money set aside to get me through the low seasons, rather than reaching a certain level of profit.

I was reading up on API spend limits for a post, and one detail stuck with me.

On Anthropic s standard tiers there s a monthly spend cap ($500 on the lowest). When you hit it, requests come back as a 429 that looks like a rate limit, but with no retry-after header. Automatic retries just keep failing until the 1st. OpenAI s hard spend limits return 429s too.

Run it on an ordinary month: $280 spent by day 10, about $32 a day. That crosses a $500 cap on day 17. The invoice would have said around $920, but the app stops working almost two weeks before anyone opens it.

Do you know which day your app would hit its limit, or do you find out when users start reporting errors?

It's way too easy to get stuck in an endless loop of polishing your product because perfection feels safe. You keep telling yourself that the next UI update or feature tweak is what's going to make the difference, while the actual core problem sits untouched. I delayed a simple launch for a month just because I wanted the onboarding screens to look like a big tech company's. How do you force yourself to ship the messy version instead of waiting for it to be completely spotless?

I ve been working on permission and role management for a B2B AI product.

One thing that makes this tricky is that a user s role doesn t always tell you what they should be able to do.

For example, someone might manage a project without managing the entire workspace. They need control over their project s settings and members, but that doesn t necessarily mean they should have access to organization-wide settings.

This creates an interesting UX problem.

I have realized that AI code generators make it extremely simple to take my ideas and bring them to life. However, the issue with this approach is that having functioning software does not guarantee that the software is actually useful.

The more features we add to our products just because it is easier to do so, the more complex our products will become.

I try to ask myself one question every time I want to create something new: what exact problem would this solve for users that the current product does not?

How do you know whether or not a feature should be created?

I have a multi-step onboarding wizard in Next.js that ends on a generated result page. All my checks passed. Then I finished the flow by hand, pressed the browser Back button on the result page, and landed in onboarding again, not on the main screen a finished user should return to.

The cause was one word. Each navigation in the wizard used router.push, which adds a new entry to the browser s history. So the whole wizard stayed in the history stack, and Back walked straight into it. It happened in three places in one component.

The fix: router. replace instead of router.push at those three places. replace overwrites the current history entry instead of adding one, so finished steps don t pile up behind the result page. I kept router.refresh() so the server data still reloads. I merged it and confirmed it by pressing Back on a real finished flow.

Why I missed it: unit tests check what a screen renders and what a function returns. History is browser state, and no test of mine pressed Back. I found it by hand.

As an engineer, it always hurts seeing teammates not use a product you built to make their lives easier.

But I started looking at it from their side.

UI, dashboards, tables, filters, workflows, interfaces all of it can feel intimidating. Even if your product is objectively better, switching from a workflow they re comfortable with feels like a drag.

And managers forcing them to use the product usually makes it worse.

When users cancel right after their trial ends, it's easy to panic and think "We're charging too much." So the instinct is to offer discounts or lower the price barrier.

But whenever we dug into exit surveys, price wasn't even the top complainti t was usually that they didn't reach the "aha!" moment fast enough to justify any price tag. Lowering the price wouldn't have saved them if they weren't getting value.

For founders who went through early monetization: how do you diagnose whether churn stems from pricing structure or a failure to communicate core value quickly?

Spent a whole sprint making our app interface look super clean by removing all text labels and just leaving icons.

Looked great for a portfolio but actual users got totally stuck on basic buttons during testing.

As soon as we put a couple of simple words back under each icon, everyone figured it out instantly and stopped making mistakes.

I used to wake up and immediately refresh my analytics dashboard. Signups traffic churn I watched those numbers like a hawk every 24 hours thinking it was "good management."

After doing it for a whole year I realized it literally led to zero meaningful changes in how I built my product. All it did was ruin my focus for the first hour of the day and spike my anxiety. Switched to a once a week review with a clear goal in mind and my deep work time improved instantly.

What is one habit or metric you track daily that actually deserves to be checked just once a week?

I keep getting pitched on lifetime deals pay once, get access forever as a way to raise fast cash, build a customer base, and create a wave of early evangelists who feel invested in my success.

The appeal is obvious. One big lump of money now, no churn on those customers ever, and a group of people who will defend the product because they own a piece of it forever. For a small product, that cash can be the difference between continuing and quitting.

For the longest time, I measured success by how many new people clicked signup every week. It felt like winning, even though my overall user count stayed completely flat because of churn. I finally paused all outbound efforts for a week and just emailed the people who had been sticking around for a while. Their feedback wasn't about needing flashy new features; they just pointed out basic friction points that made them want to pull their hair out. Fixing those three small things did more for my retention than months of acquisition campaigns ever did. When you hit a plateau, do you double down on marketing, or do you go talk to your existing users?

We had this weird situation where power users got so attached to an old workaround that when we built a real, automated version to fix it, people got annoyed instead of happy. Turns out, when someone builds a routine around a specific glitch or manual export, taking it away feels like you're breaking their daily workflow, even if the new way saves time. We had to realize that "better" doesn't always feel better if it shows up without warning. How do you handle shipping big updates to core features without pissing off the people who use your product every day?

Tracking logged in users made our numbers look great on paper but when we checked actual usage people were just clicking around and leaving.

Logins don't mean much if no one is getting value.

We started tracking how many users complete one core action every week instead. It was a slap in the face at first but it saved our product.

For anyone building a SaaS what is the single metric that tells you people actually care about your tool?

It s crazy how taking away a messy workaround can backfire. Early adopters spend months setting up spreadsheets and manual routines around your product's gaps. The second you replace those hacks with a slick native feature, their whole rhythm gets thrown off, and the immediate reaction is resistance rather than excitement.

If you've managed a major UI or workflow overhaul, what actually worked to ease that transition? Do you keep the old way running side-by-side for a bit, or just force the cut and help them adapt?

The scariest form of churn isn't when someone cancels their account it's when they slowly stop opening your app over three months while still paying. By the time the cancellation comes it's already too late to fix things. We used to rely heavily on monthly active users until we realized half of them were passive.

Now we look at feature usage depth and response time to key workflows.

I'm curious how other founders measure this what early warning signs tell you a customer is losing interest before they actually leave?

I keep hearing people say founders should constantly post and build a personal audience before launching anything. Honestly if you're building a simple daily tool like a budget manager or habit tracker most users just want something that solves their issue fast. They don't check who built it or care about the founder's story before hitting download. Product quality and word of mouth seem to do all the heavy lifting.

Are there any actual examples where a founder's active social media directly drove steady app downloads?

For the longest time my weekly dopamine hit was watching the signups counter tick up. I thought traction meant volume.

Then we started tracking 7-day and 30-day active usage and the reality check was brutal. We were pouring water into a leaky bucket, celebrating every new registration while users slipped away silently within 48 hours.

For founders who survived this transition: what specific metrics or milestones forced you to stop celebrating signups and actually fix your activation loop?

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?

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?