Connect with the Product Hunt community

Working on side projects in secret makes it way too easy to just walk away when things get frustrating. Having even one person ask for a quick progress check gives you that gentle push to keep going.

My only issue with telling people early is that sometimes getting positive reactions too soon gives you fake satisfaction and then the actual motivation to code drops.

When I started I thought I knew exactly what people would care about. I had the features planned out and a pretty clear idea of what the product should become. Then actual users started asking for things I never expected and some of the things I thought were important barely mattered to them. It was a little frustrating at first but it also made me question how much of the original plan was based on assumptions. How much do you let user feedback change the direction before it stops feeling like your original idea?

I spent almost a year preparing. Reading, planning, sketching, learning. I told myself I was building the foundation for what would come next.

The thing I was actually doing was avoiding the start. Every week of preparation was a week I did not have to fail at something real. And preparation looks exactly like work from the outside, so nobody questioned it, and I did not have to either.

When we started doing link outreach we expected radio silence. Instead site owners replied surprisingly fast, and pitch prices were a fraction of what middleman marketplaces charge.

The unexpected issue was operational handling hundreds of active email conversations, confirming live mentions and tracking terms completely overwhelmed our workflow. The hard part wasn't getting the reply it was managing the inbox traffic afterwards.

Someone asked me for help with a problem last month. I gave them a solution. A good one. Thoughtful, detailed, exactly what they had described.

They did not use it. I could tell because the problem was still there weeks later.

I cancelled something last week and I could not explain to the founder why. Not because the reason was complicated. Because it was embarrassing. The product worked fine. I just stopped opening it.

That is the most common kind of churn and almost none of it gets reported honestly. People say price or features or a competitor. The real answer is usually that a habit never formed. The product was fine and it was not quite the shape of my day.

There is a feature in my product that exactly one customer uses. It costs me infrastructure, maintenance, and a little attention every month. The numbers say I should have killed it two years ago.

I keep it because I remember the conversation when they asked for it. They were at a company with a real problem, and I was small enough to actually solve it for them. It was one of the first times I felt like I was building something that mattered to a specific human being.

I have started asking one thing before I give anyone advice about their product. Do you want me to help you think, or do you want me to tell you what I would do?

They are completely different conversations and most of the time people want one and receive the other.

I set a rule for myself last month. No new features. No new projects. No starting anything.

Just finish what was already open. Close the loops I had been leaving open for months. Answer the emails I had been avoiding. Fix the small things that had become background noise.

A person bought my product a year and a half ago, paid once, never upgraded, never asked for anything.

Then they emailed me out of nowhere with a detailed explanation of a problem they had solved with it. Something I had never thought it could do. They had built a whole process around it and wanted to tell me.

My first major product launch was an absolute mental roller coaster. I was so paranoid about things breaking that I stayed up all night checking the listing page then spent the entire morning glued to live visitor stats.

It realized pretty quickly that obsessing over every single view is totally unsustainable.

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.

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?

It's so easy to panic when a competitor launches a flashy update but half the time their own users don't even end up using it.

I usually ignore rival product moves unless our sales calls start repeatedly bringing up the exact same gap in our tool. Paying too much attention to others makes you build a reactive product instead of a distinct one.

Do you set up formal criteria for your team or is it more of a manual judgment call each time?

Deciding what to build next gets confusing real fast when every user asks for something different.

Feedback is super helpful but if you listen to everyone your product turns into a messy kitchen sink.

I usually prioritize tasks that directly fix existing user drop offs rather than adding brand new features.

How do you balance fixing what's already broken versus building new ideas from your roadmap?

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?

Building something for days only to realize nobody wants it is the worst feeling.

I used to jump straight into coding every cool idea but now I try to test demand first with a quick landing page or simple mockup.

Talking to users directly helps but people often say they want a feature and then never actually use it.

Do you look for active complaints from current users or do you pre-sell ideas before starting development?

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?

Our old knowledge base was packed with massive articles trying to explain every single detail. Customers rarely read them and jumped straight to emailing support instead.

We revamped the entire center by keeping each page focused on just one simple action and adding short video clips for common issues.

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?

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?