Connect with the Product Hunt community

When we secured our first small angel round, we immediately expanded our developer team and tried to build three major features simultaneously. Having extra capital made us focus on scale before we had actually validated whether users really needed those features. On our next project, we operated strictly on a lean budget for six months. Because resources were tight, we were forced to talk to customers daily and refine a single core feature until it had real demand.

Does early funding distract teams from finding true customer needs, or is capital essential to compete in crowded markets?

On our first launch we rushed out a buggy build following the usual ship fast advice. The feedback was rough and we burned through early leads who lost trust right away.

For our next launch we took an extra month just fixing UI glitches and edge cases. The launch felt smaller but the retention and user response were way better because the core experience actually worked.

Has user expectation gotten too high for raw MVPs, or are founders just overthinking the initial release quality?

It feels as if every six months the tech world changes its focus driven by a new tech trend. A years ago every startup tried to figure out how to add blockchain or Web3 to their roadmap. Today if your product does not have an "AI Agent or an LLM wrapper, investors and users ask why.
It is very tempting to pause your core product development just to chase the tech trend hype and gain a quick marketing lift. I have also seen products become confusing and bloated because they keep AI in places where a simple algorithm would have worked better.
How do you stay disciplined. Focused on your original vision? Do you actively ignore industry hype. Do you set aside a small portion of your time to test new tech trends just in case they truly benefit your users?

We were super excited when a couple of large accounts joined us early, but it quickly turned into a trap. We ended up spending nearly all our engineering cycles building specific workflows tailored just for them.

It started feeling more like running an agency than building a true software product, and our main roadmap got put on pause.

If you ve dealt with demanding early clients, what rules did you set to protect your core product focus?

We recently simplified our onboarding app flow thinking it would lower customer tickets, but it backfired.

Users kept reaching out because they were hesitant to click buttons without knowing the exact outcome beforehand.

We stripped away all the fancy tooltips and simply focused on making the button copy describe the exact consequence of every action.

That single change cut our support inbox in half.

Early on, every time a prospect requested a feature, we built it to close the deal. Within six months, our dashboard was cluttered, and new signups kept getting confused during their first login.

We recently stripped away 40% of the minor features and refocused the entire workflow on solving just one core problem. Onboarding completion jumped almost overnight.

Do founders overcomplicate their products too early, or is a broad feature set necessary to compete today?

Sharing our daily metrics, design iterations, and code struggles on social media brought us an incredible community of early adopters and fellow builders. The engagement was high and every update received hundreds of likes.

However, when launch day arrived, we noticed that very few of our loudest supporters actually converted into paying users. Most were cheering us on as creators, not actively looking for a solution to buy.

Does building in public help validate real market demand, or does it mostly attract an audience of non-buying peers?

Our early onboarding made people fill out way too many forms before they even saw the main tool.

Session recordings showed users were just quitting halfway because it felt like work.

People want a quick win, not a 10-minute setup process on day one.

How do you give new users a quick "aha moment" before making them do the full setup?

AI made it possible for us to go from concept to prototype way quicker than ever before.

The issue arose weeks later after we began implementing changes to our existing code.

A simple change meant having to understand the reason behind multiple seemingly unrelated lines of code.

The code worked but the context didn't make sense.

In the beginning, I thought lower prices would naturally reduce our cancellation rate. But lowering the price tag didn't save a single customer.

The real issue wasn't what we charged; it was that users weren't realizing core value quickly enough during their first week. When people don't hit their "aha moment" fast, even a low monthly subscription feels like wasted money.

For founders who reworked their onboarding: what specific change helped users cross the value threshold fastest?

I've been using AI pretty heavily while building a production mobile app, and something surprised me.

Writing the code became much faster.

I was about to add a simple utility tool today, but stopped as soon as the browser warned it needed read/write access across every single website.

It makes sense for complex page tools, but for simple utilities giving up that much privacy just isn't worth it. I ended up uninstalling and doing the task manually instead.

What's your personal rule for trusting smaller, lesser-known extensions before giving them broad access?

I often see GTM work described as this automation saved 10 hours a week or this process became 80% faster.

I m curious how people calculate that in practice.

How does it go? You are looking for something, so you ask an AI assistant to find more info, but you are unconvinced by the findings.
Then you find a credible source, but it quotes the findings you weren't convinced by in the first place as its primary source.

The most dangerous type of churn isn't the angry customer leaving detailed feedback it's the silent user who just quietly slips away.

When users cancel with a complaint, at least they tell you why. But most of our churned accounts simply stopped opening the app three weeks before they actually hit the cancel button.

For founders tracking retention data: what early warning metrics or behavioral triggers do you use to step in before an account goes completely cold?

We replaced our standard canned responses with AI-written drafts to speed up support. It definitely cut down our initial response time, but it brought an unexpected problem: users are opening way more follow-up tickets.

Because the AI sounds so natural, customers treat it like a friendly conversation rather than a quick sign-off, which keeps our queue packed. Now we're re-tuning our prompts to focus on closing tickets instead of just being overly conversational.

Have you had to tweak your support AI to make sure it actually finishes conversations instead of extending them?

switched our basic support templates to AI-generated drafts that our team edits before sending.

first replies got faster, but now users reply back way more often because the messages sound so personal and
conversational. instead of a quick issue resolution, it turns into a whole back-and-forth discussion.

Anyone else notice their team getting busier after introducing AI drafts instead of standard templates?

I ve spent the last 4 years working mainly around Upwork bidding and business development for a company. Recently, my company decided not to continue focusing on Upwork. Interestingly, I recently generated a potential $20K opportunity through the platform, which the company is currently working on.

That has made me think seriously about what the next step should be. I understand Upwork well, but I m not sure how to translate that experience into a broader BD role. LinkedIn/outbound seems like a natural direction, but doing it independently requires investment in tools, data, and outreach infrastructure, while continuing Upwork independently also comes with its own costs.

Mine used to go into three places at once. The CRM, a Notion page and a random Google Doc.

A week later I couldn't find the one thing I needed before the next call.

Now I think the problem was never taking notes. It was that nothing connected them to the next step.

1/ Your payment env vars can silently break because of a type mismatch you'll never see in the UI mine sent every "Upgrade" click to a landing page instead of checkout for who knows how long

2/ You will not notice a broken checkout button. Nobody reports it. They just... leave

3/ Your service worker will cache the broken version even after you fix it. You'll think you shipped a fix, but you didn't

How you talk to customers when something breaks is not a support issue. It is a product issue, because it determines whether they trust you the next time.

We used to write support replies in a neutral, professional tone. "We apologize for the inconvenience. Our team is investigating. We will update you shortly." It was correct and completely useless. Customers could not tell whether we understood the problem or whether we had even read their message.

We changed to something closer to how a competent colleague would talk. "You are right, this is broken. Here is what happened, here is what we are doing, here is when you will hear from us again." Shorter. More specific. No apology theater.

Support satisfaction went up. More importantly, customers started reporting bugs earlier, because they expected a real response instead of a template.

When we did founder-led onboarding calls, our conversion and retention were amazing. Naturally, we automated everything to go full self-serve so we could scale.

The hardest part was watching new self-serve signups churn within the first week. Without us guiding them, people get stuck in setup, lose momentum, and walk away before ever experiencing the core value.

For founders operating self serve tiers: how do you build active guidance into the product to ensure users hit activation without needing a live demo?

In our early days, we spent almost three weeks building a custom internal dashboard to manage customer data and subscriptions. While it gave us complete control over our workflow, maintaining that custom code eventually took time away from improving our main product. For our recent launch, we integrated third-party platforms from day one. Although we pay monthly subscription fees, our engineering team spends 100% of their time delivering value to our end users.

At what point does building custom internal software make financial sense, or should growing teams always leverage existing solutions?

We launched on a deal platform offering a $99 lifetime access plan to build early traction and cash flow. We brought in $40,000 in two weeks, but ended up flooded with demanding, feature-heavy requests from users who would never pay us another dollar. Out of frustration, we closed the deal, refunded the top 10% most abusive users, and switched strictly to a $29/month subscription model. Sales slowed down drastically at first, but our user retention and product quality improved dramatically within three months.

Are lifetime deals a dangerous trap for early startups, or is the upfront cash flow worth the support overhead?

Japanese founder, 22 years selling software in Japan. Ask me anything about the Japanese market

I've been running my company in Japan for 22 years, mostly on my own. I keep seeing people here who are curious about Japan but never really try it, so I thought I'd just open it up.

So ask away. Pricing for Japanese customers, getting a Japanese team to use an English-only tool, how buying decisions get made here, whatever. I'll be answering in the comments.

Also curious, have you ever thought about selling in Japan? What stopped you?