Connect with the Product Hunt community

I recently finished building my first product and realized that building was only half the challenge.

Now I m trying to figure out distribution from zero, no existing audience, no customer base, and no big launch community.

For founders who have been through this stage, what actually helped you get your first 10 paying customers?

Was it:

Free user growth creates hype, but paid churn brings reality.

When revenue is on the line, you realize most users leave because the product failed to anchor into their daily stack not because a minor feature was missing.

How do you analyze cancellation feedback without letting every churned customer redirect your product roadmap?

I m trying to understand the key information that architects, contractors, and fabricators should review before approving a

.

High sign up volume feels like momentum, but revenue brings churn into sharp focus.

Often, cancellation reasons aren't about missing features they come down to daily integration friction. Making your product fit seamlessly into someone s existing workflow is far harder than shipping another shiny update.

For founders who ve transitioned: Do you eventually get used to churn, or do you focus on building faster loops to analyze and fix integration friction?

Feels like every time we launch a small bug fix two other random features break immediately after.

We end up trapped in this annoying cycle of testing fixing and re-testing all over again.

It's eating up way too much of our development time each week.

Do you guys use simple automated checks for this or are you still testing everything manually before going live?

I ve been paying closer attention to onboarding flows lately. A pattern I keep noticing is that products often try to explain everything before the user has done anything. Feature tours, tooltips, welcome screens, setup questions all before the user has experienced the core value. I used to assume more explanation meant less confusion. Now I m not so sure. The products I remember most clearly tend to get me to one useful action first, then explain things when they become relevant. I d be interested in how other makers think about this: At what point does helpful onboarding become friction?

Hey makers

RevenueCat's Shipaton (their mobile hackathon) ended on September 30 with 3,336 projects on Devpost and 2,139 published apps. I went through all the public pages to see what people built. Some of what I found:

We spent weeks optimizing canned responses and automation just to drop our initial reply time down.

The numbers looked awesome on paper.

The catch? users kept replying back with follow-up questions because the fast answer didn't actually solve their issue. Taking an extra minute to send a complete answer up front saves way more back and forth in the end.

What main metric do you actually care about when measuring support success?

I was blown away by how fast I built my initial dashboard using AI assistants.

But after asking for a tiny logic tweak a week later the model secretly changed date handling across multiple files.

Nothing crashed which made it even worse the bug was completely silent until numbers stopped matching up. Now I inspect every single git diff before moving to the next prompt.

What habits or checks do you use to keep AI coders from introducing silent bugs into existing features?

When I started I wanted the product to stay focused. Every new request felt like something I could probably add without causing much trouble. Then a few small requests turned into a longer roadmap more settings and a product that started trying to do too many things. The hard part is that some of those requests were coming from paying users, so saying no didn t always feel easy. How do you decide when customer feedback should shape the product and when you need to protect the original idea?

I'm not a developer. I came up writing HTML, CSS and Sass, and now I build by directing AI agents.

With AI, adding a feature is cheap. That makes scope creep really easy.

One thing that helps me: my project's README has a "what it doesn't do" section. Things I decided on purpose not to build, each one because it would add legal risk, security risk, or a number I couldn't defend.

Since I don't write the code, my control lives in decisions like those.

Hello friends , I am trying to figure out the actual mechanics here instead of just going by assumption. Product Hunt's day resets at 12:01 AM so a product launched late at night technically gets less exposure time than one launched right at midnight.

What I'm unclear on is whether an upvote's weight changes based on when it happens during that window, like early votes counting more toward momentum and ranking algorithms, or if a vote at 11 PM counts exactly the same as one at 12:05 AM

Also curious whether voting from a brand new or inactive account actually gets counted the same as voting from an established, active one, or if that affects ranking behind the scenes.

For people who've tracked this closely across multiple launches, have you noticed real patterns in when votes seem to matter most, or is it mostly guesswork and anecdote at this point?

I supported GitScrum early on by purchasing their $299 Lifetime Deal (which is a massive investment here in Vietnam, equal to 2 months of a worker's salary). Back then, the product was broken, incomplete, and barely usable. We bought it hoping to support them and grow together.

Fast forward to today: they have completely locked down the old platform so we can't even access it anymore. They rebranded to an "AI Agents" platform and told lifetime deal holders that our licenses do not transfer. If we want to use anything, we have to pay all over again.

Taking people's money for an unfinished product, promising lifetime access, and then completely locking us out to force a new paywall is pure scam behavior. Beware of their products and future deals!

Tried building a rag app to help people navigate confusing government paperwork like pension files and certificates.

The model handled plain text fine, but started making up entire steps whenever it hit messy or blurry scanned pages.

It s so easy to focus on parts of a product that are simple to measure. We recently celebrated a feature launch because our dashboard showed great engagement but user interviews told a completely different story.

People were using the new tool simply to work around an annoying bug earlier in their workflow.

The data made us feel good, but it masked the core issue users were actually facing daily.

What methods do you use to catch hidden workflow pain points before you mistake good analytics for true user satisfaction?

I m an independent developer based in France and I currently have a few SaaS products at different stages.

For one product, the brand is already decided and I ve filed a trademark application.

For two others, the products are not fully validated yet. My plan is to first reach out privately to potential business customers, get some early users or paying customers, and see whether there is real demand before investing more heavily in the brands.

The names would still be checked beforehand for obvious trademark conflicts, domain availability, and existing companies/products.

I spend a lot of time using video editing software and creating AI media for UGC style content. Lately I have studied engineering in depth to get the exact results I need.. I wonder: should a good AI tool someday remove the need, for complicated slash commands and wild prompt formulas? At the moment it feels as if you must take a course just to make a decent thumbnail or video asset. Do you think the future of AI media tools will depend on users becoming prompt engineers or will founders build invisible AI that simply knows what the user wants through a normal clickable interface?

Building an entire product solo means every midnight bug and silent design choice falls entirely on you.

Without a teammate to bounce ideas off shipping features can feel like guessing in the dark, even when everything runs smoothly.

Lately I ve had to slow down and write out my rationale for big updates before implementing them treating my past self like an auditor.

It gives me a bit more confidence but I still miss having a real code review process.

It's been about a month since I started posting as a founder in English. Blog posts go to Dev.to and Indie Hackers, and I post on X, Threads, Instagram and Facebook too. The one I'm stuck on is LinkedIn.

I've always posted there in Japanese, and I have around 5,000 followers, but almost no connections in the English-speaking world. LinkedIn isn't that big in Japan, and a lot of people here aren't comfortable with English. If I suddenly switched to English, I think a lot of my existing connections would just tune out.

I thought about a separate account just for English, but it looks like LinkedIn only allows one account per person. If they built in auto-translation the way X has, the language barrier would mostly go away.

Anyone else dealing with this? How did you handle it?

When I first started using agents I thought the answer was simple give them more tools and they can do more useful work. But the more access they get the more I start thinking about permissions costs data and what happens when something goes wrong. Having more capability also means having more things to keep an eye on. Where do you draw the line between making an agent powerful enough to be useful and giving it too much freedom?

Seeing people sign up share the product and talk about it felt like a huge win at first. But after the excitement settled down I realized attention and real usage were two very different things. The numbers looked good for a moment but they didn t tell me much about what happened afterward. How do you judge a launch once the initial excitement is gone?

There have been features I knew weren t doing much I but removing them felt wrong after all the time that went into building them. So instead of admitting they weren t useful I kept making small changes and hoping people would eventually care. How do you know when something needs another chance and when you re just trying to justify the work you already put into it?

Acquiring new users feels like momentum, but retaining them reveals whether you built a gimmick or a workflow.

Early on, we assumed cancellations happened because we lacked features X, Y, or Z. Once paid revenue was on the line, customer feedback shifted: users loved the concept, but it didn't naturally slot into their daily tools (Slack, Notion, or email).

Fixing how your software fits into someone's existing 9 to 5 workflow is exponentially harder than building a shiny new dashboard.

There seems to be a huge divide in micro-SaaS right now between:

1. Offering a generous free-forever tier to build word-of-mouth and top-of-funnel traffic.

2. Hard 7-to-14 day free trials with a strict paywall to weed out free-riders early.

I'm currently mapping out pricing for a utility-focused mobile/web app where the core daily actions cost almost nothing in compute, but predictive analytics and data exports add up.

The fear with freemium is supporting thousands of users who never convert, but the fear with hard paywalls is high bounce rates before users form a daily habit.

We built an automated setup to cut down on repetitive team tasks and speed things up. It handled basic cases fast, but the moment tiny exceptions popped up, it broke or got things wrong.

Instead of saving hours, our team now spends that time reviewing and fixing the automated outputs. It didn't solve the workload, it just moved the effort to a different step.

What rules do you follow to decide which processes stay manual versus which ones get automated?