What Pain-Point are you Solving and How did you discover it?
We’re all builders here, which usually means at some point we looked at something clunky, slow, or frustrating and thought, “there has to be a better way.” Most products don’t start with a grand vision; they start with irritation, curiosity, or firsthand pain.
I’d love to learn more about how others here have navigated that journey:
• How did you uncover the problem you decided to work on?
• What signals told you this problem was worth solving?
• How did you validate (if at all) whether people would actually pay for a solution?
• Has your product stayed true to the original problem, or did it evolve into something different?
• What surprised you the most along the way?
If there’s anything else you’ve learned, good or bad, feel free to share. The honest stories are usually the most helpful.
And of course, feel free to plug what you’re building as well as you may have the solution to a problem somebody else is looking for!
Replies
mine came from watching UK renters and leaseholders get stonewalled on repair complaints, damp, mould, that kind of thing. the actual bottleneck wasnt writing the complaint, most people can explain whats wrong in a paragraph. its knowing which legal framework and escalation route actually applies and citing it properly, thats the bit that makes a housing association or letting agent take a letter seriously instead of filing it.
i built complaintforge.com around that. free analysis first so someone can see if they actually have a case before paying anything, then a flat fee per letter rather than a subscription, because nobody wants a recurring charge for what should be a one off problem. its live but young, no real idea yet whether the pricing survives contact with volume.
the surprise so far is how much of the work is picking the right escalation path rather than the writing itself. the letter is almost the easy part once you know which ombudsman or regulator has jurisdiction
Disclosure, I built this. ComplaintForge came from watching how much friction sits between someone having a legitimate complaint and actually writing one that a company or an Ombudsman has to take seriously. UK consumer and tenant complaints have a specific shape, there is usually a real legal right underneath the frustration, but most people either give up or write something too emotional to be actionable.
The signal that it was worth building was not a survey, it was watching how many people search for template complaint letters and get generic boilerplate that ignores the specific regulation that applies to their situation. That is a narrow, structural gap rather than a vague one, which made it easier to validate than most SaaS ideas I have looked at.
Where it evolved from the original idea: I assumed the hard part would be the letter itself. It turned out the harder part is what happens after the first letter gets ignored, which is why it now also handles the escalation stage rather than stopping at send. People do not pay for a letter, they pay for not having to figure out the next step alone. It is live if anyone wants to see how the escalation pack is structured, happy to share the link if useful.
For ReviewCook, the problem came from seeing how much friction there is between a happy customer and an actual Google review.
We validated it by talking to local businesses and testing whether simplifying that journey made sense to them.
The biggest surprise has been how much product direction evolves once you start hearing real customers describe the problem in their own words.
I kept seeing the same thing in client projects: the actual project was scattered everywhere.
A requirement changed in email, a decision happened on Slack, feedback lived in Figma — and eventually someone had to reconstruct what actually happened.
I originally built Bracket to turn messy client conversations into structured scope and decisions. But after people started using it, I realised the bigger problem wasn’t starting a project clearly - it was keeping that context accurate as the project changed.
That’s what we’ve rebuilt Bracket around now: connecting to the tools people already use and maintaining the project memory over time.
The biggest surprise was that people cared less about “AI” and much more about simply not losing context.
Pain point: health is scattered. Lab reports sit in one place, steps in another, cycle tracking in a third, calories somewhere else. And when a report lands, most people can't tell what's elevated, what's normal, or what it means, and the appointment is days away.
How we found it: firsthand frustration. We wanted one app that covers everything about health, so nothing gets missed, and couldn't find one.
Signals: people already juggle several apps and screenshots to piece their health together, and almost everyone has a report they never fully understood.
Validation: people react strongly to the idea of uploading a report and getting it explained in plain language. That's where the response has been strongest.
How it evolved: it started around understanding reports, then grew into a full picture with cycles, diet, workouts and steps, and now connects and correlates all of it in one question.
What surprised me: building was the easier part. Distribution is the hard one.