Connect with the Product Hunt community

I keep relearning the same lesson: the first version I am proud of is usually two or three weeks later than the version I should have shown people. What works for me now is a short checklist. Can a new user finish the one core task without me explaining it? Does it fail gracefully when they do something unexpected? Can I see what they did afterwards? If those three are true, I ship it to a small group even if the design is rough. Where do you draw the line between too early and too late?

Before vibe coding I would spend a lot of time just getting started

Now I can test an idea build a small prototype and see if it actually works much faster

The biggest change for me is not writing less code

It s being able to experiment with more ideas

For two years I forced myself to publish a brand new article every single Tuesday. I was exhausted. My organic traffic was completely flat despite having over a hundred posts on the site.

I looked at our analytics. Noticed that almost all our search traffic came from just five old articles. The rest of the content was sitting on page four of Google entirely ignored because it was outdated and lacked depth. I realized publishing volume was hurting my quality.

I stopped writing content for an entire month and focused only on those underperforming posts. I combined articles into massive guides updated old statistics from 2022 and added fresh screenshots from our current software version.

That simple cleanup effort boosted our site traffic by sixty percent in just forty days. Google clearly prefers an updated highly relevant page over a brand new post with zero domain authority.

I m currently working on a consumer mobile product aimed at a very specific blue-collar audience in the U.S.

One thing I m finding difficult is figuring out which acquisition channels are actually worth testing first.

For niche audiences like trucking, construction, logistics, field services, etc., do you think it s better to start with:

• short-form organic content

• niche communities

• creators/influencers

• referrals

• paid social

• search

Apple is now nudging people still on iOS 26 to move to iOS 27, and the 27.2 betas are already out. Every cycle like this makes me rethink the minimum OS question for a first release. I've found that supporting only the last two major versions keeps testing sane and lets you use newer APIs without workarounds. On Android it's messier, since a lot of real users sit on older devices for years, especially outside the US. If you're shipping a v1 on both platforms soon, where are you drawing the line? Do you check your target audience's device data first, or just pick a floor and adjust after launch?

When I first started thinking about building a SaaS, support wasn't really on my list.

I was thinking about the obvious stuff:

• What features should I build?

• How should the UI look?

• How do I make it fast?

• How do I get the first users?

But the closer you get to actually putting a product in people's hands, the more you realize that users don't always experience your product the way you expect them to.

We once added a new permission to our extension and saw a massive drop in user count afterward. It could have been optional, but we made it required. That s something I d do differently now.

It got me thinking about what people check before giving an extension access to their browser. A useful feature might get your attention, but how much do permissions influence the decision?

Have you ever been ready to install an extension, then changed your mind? What put you off?

We've been debating our pricing model for a while now. Monthly sub plans make our sales funnel flow smoothly but our churn resets every 30 days and we have to keep winning the same users back. On the flip side upfront yearly billing gives us great cash flow but the friction at checkout is much higher for new visitors who don't know us yet.

How did you balance your monthly versus annual options when starting out and did yearly plans actually make buyers stay longer?

I built a quick weekend tool with AI and used it with my partner for days with zero issues. Everything was working smoothly until I invited a third user, and instant sync conflicts started wiping out data.

The AI picked the easiest, single-user setup because I didn't explicitly tell it to plan for concurrent edits. Now I never start a build without reminding the prompt that multiple people will be using it at the same time.

What default rule or constraint do you always add to your prompts to keep AI from making bad structural assumptions?

In the course of six weeks of the launch i handled all support communications for an invoicing application i developed for freelance photographers personally. No automation, not templates. I was expecting bug reports. Instead I was provided with a blueprint where my product confuses its customers.
Three emails deserve mentioning. One of them was asking about the location of the "send reminder" button it was on a page where users never logged in.Another email made assumptions that deposits and the final payment were interchangeable as my label system had the word to describe these notions.. Finally there was a brief "thank you note" from the wedding photographer, from Cebu stating that the PDF document he received looks exactly like it was generated by his studio. This one was immediately. Hanged to my desk.
The analytical tools showed that users were leaving the dashboard. The emails explained the reasons of doing. As a result I ve repositioned the "reminder" button. Separated these two labels. Repeat questions disappeared within a week.

Now I am curious how far this signal goes. When did you stop answering every communication and what replaced it?

Getting a working app out of a few prompts is the easy part now. What I keep running into is the day after: the app works, but I don't really know what's inside it.

A few things that bit me after the "wow, it runs" moment:

• Realizing I couldn't explain how auth or data storage was actually set up

• Fixing one bug and breaking something unrelated because I never saw the structure

• Coming back a week later and not recognizing my own project

So I've started doing a short "day 2 pass" before I build anything new on top: skim the structure, check where secrets and user data live, and write a few lines about what the app does and how.

When I started I thought every problem needed an immediate fix. If users complained about something I d jump on it. If growth slowed down I d try something new. If a process felt messy I d try to rebuild it. But sometimes the better move was to leave it alone for a while. A few problems fixed themselves as the product changed while others turned out to be problems I was creating by overthinking them. How do you decide when a problem actually needs your attention and when it s better to just leave it alone?

When we started, our app was super simple. People logged in did what they came for in seconds and signups were high.

Then we tried to make everyone happy by adding tons of settings and custom options. instead of making the app better it just confused new users and brought in endless bugs.

I went through my credit card statement last weekend and finally canceled a software I ve been paying for over a year. I felt bad doing it because the product was great, but I only used it a few times all year.

It was a good reminder that churn isn't always caused by bugs or bad features sometimes people just outgrow the need for the tool.

If you run a SaaS how do you learn from users who leave politely without filling out cancellation surveys?

When I started there were only a few things to worry about so decisions were pretty quick. Talk to users fix the product ship the next thing. Then the business started growing and suddenly every decision affected something else. More customers meant more support more features meant more maintenance and more people meant more opinions. How do you keep things simple as the business gets bigger?

In the early days, our product had a single, crystal-clear value proposition. Users logged in, knew exactly what to click, and achieved their goal in seconds. Because the core experience was focused, conversion rates were high and onboarding was practically effortless.

Then came the desire to expand. We started building every feature users requested, adding customizable settings, and creating multiple workflow options. Instead of delighting people, the experience deteriorated. More options split user attention, clutter ruined the clean interface, and new features introduced unexpected edge-case bugs. We added value on paper, but in reality, we just added friction.

How do you strategically say "no" to feature requests so your product stays lean, intuitive, and effective as it scales?

It s easy to focus most of the attention on getting someone to pay but that s usually when you start learning whether the product is actually useful. Someone can convert and still stop using it a few weeks later because they never built a habit around it. I m curious how other teams handle this part. Do you regularly talk to existing customers to understand why they stay or do you mostly rely on usage and churn data?

I pay much more attention to the changelogs of Linear and Raycast than to their landing pages. The landing page tells me what the team thinks should be true. The changelog tells me what was delivered on Tuesday and whom the company listens to.

A small team often skips its changelog, as it seems to be just administrative stuff. I believe that an organized changelog with simple sentences and a date adds more to trustworthiness than yet another row of testimonials.

Meta and Sierra just announced Personal Agent Protocol, an open standard for how personal agents talk to businesses. Shopify, Stripe and Walmart are listed as partners and the first spec is supposed to land later this month.

I build small web apps and my first reaction was mixed. Fewer abandoned checkouts sounds nice. But I'd want to know when it's an agent and not a person, and who sorts it out when it orders the wrong thing. Is anyone already seeing agent traffic on their product? Would you support something like this early or wait and see?

When we first started we had a really specific user in mind.

But once we went live the people actually buying and using the app were completely different. They had different problems but they were the ones actually paying us money.

I ve been looking at different smart-home setups and one thing I keep coming back to is how much of the system should depend on the cloud.

Cloud-based platforms are convenient because they make remote access and setup relatively simple, but local control seems appealing for reliability and response time. If the internet connection goes down, I d still want basic things such as lights, switches and sensors to work normally.

We kept thinking lower pricing would make it easier to get more users but it also seemed to attract people who were much more price-sensitive and quicker to leave. Getting more signups looked good on paper but the customers weren t always the best fit. Raising the price feels risky because you can lose some conversions at the top of the funnel especially when people are still discovering the product. For those who changed their pricing after launching did a higher price actually bring better customers and retention or did it mostly reduce new signups?

Right now my name is everywhere the About page, the footer, the blog bylines, the support emails, the invoices. It feels honest, and early on it was my biggest advantage: people bought because they trusted me, not because they trusted a logo.

But I keep wondering if I'm accidentally capping the ceiling. A faceless brand can scale past me, hire a team, get acquired, survive my vacation, and eventually run without my face on it. A personal brand can't it is me, and the day I stop showing up, it stops working.

When I started I thought the answer to being overwhelmed was simple bring someone in and hand things off.

But then I realized that delegation takes time too. You have to explain the work answer questions review things and sometimes fix mistakes you wouldn t have made yourself. The real benefit only comes when you trust someone enough to let them own the work. How do you know when you re ready to stop doing something yourself and actually hand it over?

Last month, I developed a grocery list app in Bolt over the weekend. It was beautiful. We used it with my partner for three days and then I invited my sister to use it.

She kept overwriting our changes because the model was storing the entire list in one record for each account, and every save would overwrite everything else. Since I never specified any conflict resolution, there was none.