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
After 15 years in bioinformatics, I've had the same conversation about 1,000 times: Biologist: 'I have count files for my RNA-seq data from the service center. Can you help me analyze them?' Me: 'Sure, just run DESeq2 after normalizing your counts' Biologist: 'Um... how do I do that?' Then I spend 2 hours writing a script they'd never be able to modify.
This pattern repeated across labs, institutions, continents. The bottleneck was never the biology. It was the code.
That's why I built Pipette.
I suck at picking lottery numbers, needed a computer.
What surprised you the most along the way?
It finally kinda worked. It doesn't find the jackpot but the extra free plays make the experience a little less painful and I'm fine with that as I am enjoying game making.
Pain point: "idea validation". Yup, that's a big one.
I researched expired Chrome Extensions (expired due to Manifest V3 non-compliance, developer left and no longer maintained, quality issues, etc.) and compiled a huge database of recently expired Chrome Extensions, fully researched (12 data points per extension), and for good measure I included some guides to rebuild, monetize, do SEO, etc.
This basically means that the user base (from a few hundred, to >100K) is still there, waiting for someone to rebuild the extension... If that isn't "idea validation", I don't know what is.
I'm launching next week on PH, but if you're curious, it's called Chrome Goldmine. ;)
great question 🙌 i build a few apps under studio.gold and each one came from a diffrent frustration:
speakeasy - i had 400+ articles saved in pocket that i never read. realized my eyes/hands are busy but my ears are free like 90% of the day. so i made an app where u paste any url and get audio back in seconds. the signal it was worth building? i was paying speechify $140/yr for basically this one feature buried in their bloated app.
astrologica - my gf checks her horoscope every morning but all the apps are either generic af or require like 10 mins of reading. built her a daily podcast version thats personalized to your actual birth chart. validated it by asking in r/astrology if ppl would want this - overwhelmingly yes.
wordplay - i got into cryptic crosswords and wanted to learn but theres no good beginner-friendly app. most ppl dont even know what a cryptic is. so i made a 1-clue-per-day app that teaches you how to solve them gradually. the surprise? retention is insane because its just 1 clue so ppl come back every day.
biggest learning: solve your own problems first, then check if others have them too 💡
Hey !
• How did you uncover the problem you decided to work on?
At previous job internal documents was always a mess. Even if updated and organized frequently. Chatbot trained on them would mitigate the mess.
• What signals told you this problem was worth solving?
The issues occurred in every company I've worked for. No solutions were or are out there to make so chatbot works within each departments needs without overpaying with per seat pricing or token markups. And should live in chats that company already uses - Google Chat or MS Teams.
• How did you validate (if at all) whether people would actually pay for a solution?
Validation basically came before the product was created as at first it was built for internal usage only. Currently there is no cheaper with the same capabilities option even after a year. The main validation came from building to resolve a real pain point most of the companies have.
• Has your product stayed true to the original problem, or did it evolve into something different?
Yes, the core has always stayed the same, Control and security over everything else. Recently it evolved from chatbot trained on companies knowledge to Chatbot trained on companies knowledge with option to trigger automation with guardrails. You can imagine it as personal assistant. "Hey I need a vacation" "Hey something is off with the report" - User interacts with AI then the interaction gets turning into an action and executed how ever client (NOT USER) wishes to via webhook. Why not User chooses what gets triggered? Because that is done by responsible people for the setup in each company. Another crucial guardrail in today's mess of AI automation.
• What surprised you the most along the way?
To be honest, the most recent was how versatile OpenAI API can be. Using the custom tool you can basically make anything. The hard part is the logic and system design. Which is the 2nd part which made me surprised : for some reason I got really good at designing the systems. How they interact, how to turn limitations into real product.
My first site actually came from the pain point of our main project. Non developers needed to be able to edit our copy without touching code. So we created Skyblobs, a lightweight copy editor for GitHub hosted websites.
I’ll be honest, my starting point was mostly irritation.
I was using disposable email services quite a lot while testing products and signing up for random tools. Most of them had the same problems: slow inbox loading, way too many ads everywhere, and some of the “good” ones were surprisingly expensive for what they offered. The UX was usually pretty bad too.
After dealing with that over and over, I just thought there has to be a cleaner way to do this.
That’s what pushed me to build @FCE - Temporary and disposable email — mainly focused on privacy, speed, and a cleaner UI without turning the inbox into an ad wall. Initially it was just something I built for myself and other developers who needed disposable inboxes while testing signups and workflows.
The signal that it might actually be useful was pretty simple: a few friends and developers started using it and asked if there was an API. That’s when I realized the problem wasn’t just mine — people wanted temporary email thats reliable and developer-friendly, not just spammy public inboxes.
What surprised me the most is how many services and platforms actively try to detect and block temp mail domains. That turned out to be a whole separate challenge I didn’t expect in the beginning.
Still evolving a lot, but it’s been fun learning along the way.