What made me stop building sooner than I used to
I used to think the hardest part was deciding what to build. Turns out the harder part is knowing when to stop. Lately I’ve noticed that weak ideas don’t crash they fade. People are polite. Feedback is vague. There’s nothing clearly wrong, but nothing pulling you forward either.
I used to treat that as a signal to improve execution. Add features. Explain it better.
Now I’m experimenting with a different filter:
- Do people come back on their own?
- Do they reframe the problem in their own words?
- Do they disagree or challenge the idea?
If none of that happens early, I’m starting to pause instead of pushing. Not sure yet if this is the right approach.
I’m still figuring this out how do you usually make that call?
Trending on Indie Hackers
What's the point of AI generated comments?
The exact prompt that creates a clear, convincing sales deck
Why can't your target customers always find your product? - Experience sharing
The thought that weak ideas don’t fail loudly but just fade feels uncomfortably true.
I’ve probablly mistaken polite feedback for progress more than once.
In hindsight, the silence and vagueness were already the signal.
Yeah, same here. Polite feedback is comforting in the moment, but it’s rarely a signal to keep pushing. Silence is uncomfortable, but it’s usually more honest. I’ve started paying more attention to who leans in, not who’s just being nice.
This is a really insightful shift in perspective. That second filter - how people reframe the problem - is something we've been watching closely while building our mental wellness app. We're using AI agents to provide personalized support, and noticing when a user describes their need in a way we hadn't considered is often more valuable than a 'polite' feature request. It's much better to fail fast than to over-engineer a solution looking for a problem!
That’s interesting. The way users explain the problem often ends up being more useful than what they ask for directly. We’ve seen that too it’s usually where the real insight shows up.
Failing fast there makes way more sense than building around assumptions.