Connect with the Product Hunt community

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?

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?

Spent weeks coding a feature I personally thought looked super cool only to check analytics later and see almost zero usage. Meanwhile actual user requests were sitting ignored in my notes.

Now I force myself to stick to a strict rule where I only build something if multiple users explicitly ask for it first.

Was there a specific moment or failed launch that made you stop building for yourself and start listening to users?

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?

When I started I had a very clear picture of who I wanted to build for. I spent a lot of time thinking about that ideal user and what they would want. Then real customers started showing up and some of them were completely different from the people I had in mind. Their problems were different too and honestly they were the ones paying the bills. At what point do you stop trying to find the audience you imagined and start building for the one that actually showed up?

Our team was losing hours every week on repetitive tasks so automating the whole flow felt like an easy win.

The initial run was fast and clean, but edge cases quickly threw everything off.

We ended up spending just as much time auditing the automated results as we used to spend doing the work manually.

Shifting the bottleneck to quality checking wasn't the efficiency boost we planned for.

Concept illustration for the CRM idea I m researching.

I m a beginner SaaS builder currently working on a unified chat CRM. The idea is to bring customer conversations from different channels into one place and help businesses keep track of contacts and follow-ups.

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 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?

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 looked at our conversion rates last month and panicked sign ups were high, but upgrades to our pro tier were almost flat. Our first instinct was to add more features to justify the price tag.

Then we jumped on calls with a few power users who were still on the free plan. Their response caught us off guard: We don't need more features; we just hit the paywall to early before we could prove the ROI to our team.

It made me realize that sometimes a low conversion rate isn't a feature gap; it's a pricing tier architecture problem.

How did you figure out the sweet spot for your first paid tier did you rely on usage data, customer budget feedback, or just trial and error?

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?

Last time I wrote about why one line of code needed an SDK. It ended on a small rule: a missing field comes back undefined, never 0, because a 0 looks like a real number. I'd love to say I came up with that rule by being clever. I came up with it after my own dashboard showed $0 on 176 requests that weren't free.

An integration sent its requests with the provider set to "gemini". My price table filed those models under "google". The lookup found nothing, so the cost was stored as $0 and the status as Success. Nothing logged an error, because as far as the code knew, nothing had gone wrong. Cost is calculated once, when a request lands, so adding the missing price afterwards didn't touch those rows either. They stayed at zero.

(Quick confession for anyone keeping score: before this, I'd have told you the scary bug in a cost tool is overcharging. I had it the wrong way round.)

An overcharge is loud. Someone sees a number that's too high and asks why. A zero is quiet. Your total comes out lower than reality, a feature looks cheaper than it is, and you find out when the provider's invoice disagrees with your dashboard.

Hi everyone!

I built a travel journal app with Lovable, inspired by my own experience of having trip memories scattered across photos, notes and WhatsApp.

It brings trip stages, photos and personal impressions together into a story that can be revisited and shared with loved ones.

I came across DeepSeek's new Search & Fetch APIs and thought they might be useful for something I'm building.

I'm working on a tool to find competitors and discover discussions about similar products on Reddit. Right now, I'm exploring ways to make that research less manual.

The APIs seem promising, but I'm wondering how well they'd work for this use case.

Has anyone tried them in a real project? Would they cover most of what I need or would I still need to build a separate crawler.

Product tours are almost always a trap because everyone just looks for the skip button immediately.

We noticed the same thing with our setup asking users to fill out empty forms right after sign-up killed our conversion rate.

Switching to dummy data and pre-built templates made a huge difference because users could instantly see what the end result looks like without spending ten minutes configuring settings.

Do you give new sign-ups sample project data right out of the box?

Scrolling through today's launches, noticed a solo dev with under 500 followers sitting right next to a product backed by a known team with thousands of followers ready to vote within the first hour. Same leaderboard, very different starting lines.

Makes me wonder if Product Hunt's ranking genuinely rewards the product, or mostly rewards whoever can mobilize the most people fastest on launch day. A great solo product without a network behind it seems to need a lot more luck, timing, or a lucky external traffic source like YouTube or Reddit picking it up.

how others think about this. Should newer makers avoid launching against bigger funded teams if possible, or does timing not really matter since quality eventually finds its audience anyway?

Our dev cycle has turned into a endless loop of patching one bug only to watch another feature break right after.

It feels like we spend more time re-testing existing features than actually building new ones.

We re trying to set up a lighter workflow so every update doesn't trigger a full manual check of the entire app.

What basic QA routines or lightweight tools keep your builds stable without slowing down your weekly ship date?

Been working as a solo dev for a while and the lack of feedback on code quality is definitely the hardest part.

You never really know if your architecture is solid or just holding together by luck.

Started writing down brief notes on why i pick certain tech choices just to double check my own thinking.

It helps a bit with clarity before pushing changes.