Connect with the Product Hunt community

I built two things the same year. One got thousands of visitors in a week. The other got a slow trickle that never really stopped.

I spent all my time on the first one because that is where the attention was. Fed it, fixed it, promoted it. It peaked and faded and now it is a folder I do not open.

I fix WordPress and WooCommerce problems for a living, and AI has changed some of my routine. It's very good at reading an error log and explaining a stack trace in plain words. I still don't trust it to edit a live checkout or a plugin I don't know well.

The places it has sent me the wrong way are usually plugin-heavy sites, where it suggests a clean fix that ignores another plugin hooking into the same function.

This partner model was actually tried by a few earlier startups but it ran into massive operational friction.

Beyond inventory mismatches speed is the biggest bottleneck a kirana owner has to manage walk in customers cash payments and chit-chat while dark store staff exist solely to pack orders in under 90 seconds. Plus, quick-commerce platforms make better margins when they buy bulk inventory directly from brands instead of splitting profits with a middleman shop.

Have you seen any local apps successfully blend both models in Delhi?

I ve been a packaging designer in Vietnam for years, and the print-shop handoff is still the part I dread most.

My top 3:

1. Colors shift because the file wasn t really CMYK

2. Foil / UV layers get mixed into the color file

3. The box looks fine flat, but the artwork lands on the wrong panel once it s folded

What s yours? And how do you check before sending: physical sample, 3D mockup, or just hope?

I love how fast AI helps us ship features but I ve noticed a risky habit creeping into daily workflows. Because it takes two seconds to generate a fix for any error there s almost zero reason to step back and analyze structural design choices.

It feels like we're spending all our energy making code work in the short term, rather than learning how to architect scalable long-term software.

I run a small blog where I write wishes, messages and quotes for birthdays, anniversaries and festivals. Over the last few months I've learned that traffic doesn't come from writing more posts. It comes from writing the right ones.

Three things that worked for me:

1. Answering one exact search per post. "Birthday wishes for a sister" ranks much better than a general "birthday wishes" page.

2. Pinterest over other social platforms. For quote and wishes content, pins keep bringing visitors for months.

3. Updating old posts instead of always publishing new ones. Refreshing 10 older posts did more than writing 10 new ones.

I'm curious what's working for other makers and bloggers here. Is there a tool (SEO, writing, design or analytics) that made a real difference for you, especially a free one?

Feature creep happens so fast when you're trying to make every early customer happy. We made the exact same mistake and ended up with a cluttered product that confused new signups during onboarding.

When we finally decided to remove two unused features, a tiny group of vocal users complained, but our main activation rate shot up right after.

Sending a polite heads-up email with a simple alternative helped soften the blow.

Did you face any backlash when you started cleaning up your dashboard?

Saying no to customers is honestly one of the hardest parts of product design.

It feels good to keep adding things but every new button adds cognitive load for new users who just want to solve one core problem.

We started putting requests into a "nice to have" list and only building features if at least 10 different accounts asked for the exact same thing.

Do you hide complex features behind advanced settings or do you prefer removing them completely?

Saying no to customers is honestly one of the hardest parts of product design.

It feels good to keep adding things but every new button adds cognitive load for new users who just want to solve one core problem.

We started putting requests into a "nice to have" list and only building features if at least 10 different accounts asked for the exact same thing.

Do you hide complex features behind advanced settings or do you prefer removing them completely?

our help center grew to over 300 articles over time, but most of them were totally outdated. new team members just stopped reading them and started asking colleagues instead.

we archived most of the old stuff and kept only around 80 updated docs. response times improved almost immediately because the team could actually trust the info.

How often do you guys clean up your internal docs instead of just stacking new articles on top?

Building the requested feature directly usually leads to bloat and partial solutions.

Asking "What are you going to do with this file/data once you download it?" has saved us weeks of work before. A simple scheduled email or minor tweak often solves the pain point much faster.

How do you document these underlying workflows so the whole team understands the real user intent?

We had a profile completion meter and a nagging banner that followed users until they filled it out. Completion rate after 90 days: 26%.

We removed the meter and the banner for a test group. Completion rate in that group: 24%. Statistically unchanged.

I completely agree that badges and streaks lose their charm after two weeks.

For me sharing progress publicly on Twitter/X or a public build log creates a different kind of pressure because customers and followers are watching, not just friends. With private peer groups people often end up being too nice when you miss a deadline.

Do you think public accountability builds stronger habits or is a small private group still better?

Moving business logic and pricing rules to the backend is definitely the right move for mobile apps.

The biggest mistake we made early on was hardcoding feature flags inside the binary which meant a simple UI toggle required a full release cycle.

Shifting everything to remote config files changed our deployment speed completely.

Have you ever pushed a backend config change that accidentally broke the app layout on older screen sizes?

When vibe coding, asking AI to add a new feature can sometimes change code that was already working

Suddenly, a small update breaks another part of the app and you have to spend time fixing it

Using Git helps, but it doesn t always prevent these problems from happening

For developers building with AI, what workflow do you use to keep changes safe?

Moving a date is tough but doing it for financial flow or security is always the right move. I ve made the mistake before of rushing out a launch just to stick to an arbitrary deadline and we spent the next month putting out fires instead of getting feedback.

People forget a late launch but they don't forget a broken checkout experience.

How did your team and early waitlist users react when you broke the news about the delay?

I'm in an infinity loop of testing - fixing - testing again.

After fixing one thing, something else broken.

Just wonder how you perform the testing after every release without breaking the existing ones?

Do you have any QA framework, automated testing or AI assisted tools?

Focusing on three high impact tasks is super effective for daily output especially to avoid feeling overwhelmed. My main struggle with minimal task lists was always estimating task size sometimes one "high-impact item" turned out to be a three-day project in disguise.

Breaking bigger goals into daily sub deliverables really helped smooth that out. Do you plan these three priorities the night before or right when you start your workday?

We built dozens of custom options in our app over the years thinking users wanted full control. But after looking at the data over 80% of users never changed a single preference.

It made me realize that good default setups matter way more than giving people endless buttons and toggles to tweak.

When you notice a feature setting is rarely used, do you just leave it there or actively remove it to keep things clean?

I used to waste so much time polishing visual tweaks and extra tools that sounded great in my head while ignoring basic functional requests from actual paying users.

It took a pretty disappointing reality check with our usage metrics to realize I was just building for my own ego.

Now I keep a super simple backlog and refuse to write code for anything unless it comes up repeatedly in user feedback.

It's really frustrating when an AI assistant repeats a bug you fixed two days ago. Chat context clears between sessions so past corrections just vanish into thin air.

Saving issue notes directly in the repo helps but the AI can still ignore them unless forced. Setting up hard rules or custom scripts that run during every response ensures the model actually abides by past lessons instead of drifting back to bad habits.

Do you rely on custom system prompts to maintain rules or do you use external scripts to enforce constraints on your agent?

We built our entire launch strategy around the build it and they will come PLG playbook sleek landing page, Product Hunt drop, and automated email drips. We sat back waiting for the viral loops to kick in. Crickets.

It wasn't until we forced ourselves to manually DM and hop on calls with our first 50 signups that things clicked. They didn't find us organically; they needed a direct, personal nudge to realize how the tool fit into their daily routine.

It made me realize that early stage organic growth is often just brute-force founder hustle in disguise.

How did you get your very first wave of active users pure PLG magic or did you have to manually grind for every single one?

Whenever a customer cancels their subscription, our automated exit survey spits out the same reason: Too expensive or Just don't need it right now. For a long time, we took those answers at face value and tried discounting our plans.

It wasn't until a few former users casually admitted on Twitter (after we built a friendly rapport) that the real reason was a lack of a specific integration that we understood the truth. The price wasn't the issue; the missing utility was.

It made me realize that standard churn surveys rarely capture the real psychological barrier to staying.

We spent weeks obsessing over reducing our signup steps. We removed email verifications, cut down profile setup, and made everything a single click experience certain that drop offs wese happening due to friction.

Retention barely budged. But when we actually looked at the users who completed the quick signup, they churned within 48 hours because they had no idea how to set up their workspace. Adding a bit of purposeful friction (like a quick setup wizard) actually improved our long-term retention.

It made me realize that fast onboarding isn't always better onboarding if it skips user education.

How do you strike the balance between a frictionless signup and making sure users actually understand the product's value?