How to Find a Product Idea as a Solo Builder Without an Audience or Domain Edge

19th March 2026. It's probably the most defining moment of my professional career. That is the day I left my comfy corporate job to build a one person business. I feel everyone who leaves corporate for their own thing must feel a sense of hope as well as a touch of delusion. Hope that world is a fair place and people who work hard get what they want, and delusion that there is something which they can do better than others, which will make them earn their place as a founder. Both these thoughts are outright wrong! But both these factors are needed to make this decision work!

Now, this is not a post about the sad reality of this world (may be later?), so we'll not delve into why the world is not a fair place. But the factor of delusion is something that I'll try to address because it can help you in your own journey in building a tech business or some passive income through digital products.

I set out on the mission of building a one person tech business, where I wanted to build a portfolio of small apps/micro saas. I come from a non-technical corporate background, so not much aware about software engineering work. But I'd done some product management stints so I knew the process of it, and with the AI coding enhancements it was easy to think that I can make this solopreneurship dream come true, because, hey - now anyone can pretty much build anything, right? That was the big barrier to us non-engineers in an engineering world - the technical capability to build. So with that entry barrier significantly reduced, there's no stopping me. Or at least that's what I believed, and decided to quit my job!

It's not a failure story too (not yet at least), so I'm not saying I was completely wrong. But here's what I saw when I jumped in - in 2026, everyone with a laptop and wifi CAN build a digital product, so, in 2026, everyone with a laptop and wifi IS building a digital product. But believing that just because you CAN build a successful product, you will build a successful product is the delusion we need to stay away from.

People are spending their time playing with AI tools, companies are spending their time adding AI features. Y Combinator's 2025 batches were running on roughly 95% AI-generated code. Building had become the easy part. There's a rush of AI generated apps in appstore and playstore. The biggest market setback is on microsaas, because anyone can write a few prompts to help AI write a few prompts to help another AI develop a feature they think is needed. So what does that mean to a microsaas, independent builder? The big question is no longer what products can I build? The big question for independent creators is - what is the right problem for me to solve!

So I tried to do some research on what exactly are my options as a solo builder. I realized there are 3 paths people follow:

Path 1 - Live inside the problem

Danielle taught English online, 12-hour days, kids on the other side of a screen in China. At the end of every shift came the part nobody paid her for - the feedback of students. Two, three hours of writing the same kinds of sentences, slightly different each time, for every student. Repetitive enough to feel mechanical. Personal enough that you couldn't just copy-paste. Arvid Kahl watched this. Built a templating engine. Nothing technically complex — the insight wasn't in the code. It was in knowing exactly which person, in exactly which niche, had a problem that repeated itself every single day and had no solution yet. Two years later, seven figures. The software was the easy part.

Not just them - research tracking US startups found roughly 47% of the ones that survived were founded by people who were themselves the user.

This is probably the most common path - it doesn't take a genius to say 'build what you know,' so you'll hear this quite repeatedly. Typical internet wisdom says 'scratch your own itch' and if you're inside a problem then you can act the fastest so build for the problems you have access to or have discovered in your journey. That's great. But I think we're going towards a world where people will value personalization to the extent that they will build their own solution for the problems they face and know - not take someone else's built solution.

This approach to finding problems to solve is the best approach for someone starting out - don't spend time on problem discovery, be closest to the problem and focus on business building more than product validation. This is also an excellent choice if you're in a niche & complex domain, or where people don't build solutions often. Think factory setups, domains like real estate where it's not easy to build a product and it's a closed setup so your discovery = your edge.

However, if the entry barrier to your domain is low then your domain is already crowded, so if you don't have any additional edge (distribution/privileged access/funds), being in a crowded builder market signals taking a different path. I consider my domain - tech solopreneur - to lie here. These are people who can build things quickly, distribute if they've been doing this long enough, so for someone who doesn't have an additional edge, being in a crowded builder market signals taking a different path. Also watch out if your problem is immensely unique to you - which is a real possibility if your journey & experiences have been immensely unique.

Path 2 — Own the audience before picking the product

Marc Lou started with two years of building things in public - shipping, failing, writing about it, doing it again. By the time he built ShipFast, he had 95,000 people watching. The product was almost secondary. A Next.js boilerplate, something any developer could have built. The moat wasn't the code. It was the audience that already trusted him before he wrote a line of it.

Cameron Adams did the same thing differently. He and his co-founders had LinkedIn audiences of 180,000 and 300,000 - all LinkedIn creators. So they built Kleo, a LinkedIn content tool. He was explicit about it later: "We achieved this growth through distribution and trust." They didn't find a problem and then build an audience around it. They had the audience. Then they chose the product.

This is a path which is immensely tough to gain, but leads to the kind of unfair advantage that all businesses crave for. In today's age - if you have distribution, you are the product that can get:

• ideas fast - new discussions happen around you since you're in the right spaces

• validation fast - you have an audience to test products with

• launch velocity - you never launch into a void

If you have a day job and are only considering entrepreneurship on the side / in future, don't start with product building, start with distribution building, the right product will eventually come. If you have an audience, then use them to find your product ideas. If you don't have an audience then start building one - and while you do that, read path no 3.

Path 3 — Go deeper than the insider will

It's a big possibility that both path 1 & 2 are not for you. They were not for me. I had a crowded domain, low entry barrier and lacked distribution power. I'm building it step by step. But I need a way to still survive, so I take the third path which is the corollary of the first path - not living inside the problem.

The simple economics of business is to build something which has strong demand, and low supply. But strong demand and low supply is already built, so we look at the next best thing - growing demand and bad supply. The key is to be faster than others in watching a domain and finding what's gaining traction, but has a bad supply of products. You'll be surprised by how many outdated solutions still exist and people are forced to use them, because people don't pay attention to them.

Now, we did mention that the person fastest to get to a problem will be the one living inside it. So no matter how good you get, you'll never be faster than that person. So how do you beat that?

The sad reality of a person living inside the problem is that it's not their mission in life to build a solution to that problem. With Vibe coding and simplified building, they can build quickly, but only if they know what to build. If the problem at hand is conceptual, requires cross platform thinking, iteration to build, then it's likely that this person will miss out, or create something very basic, and that's where you win.

When I started building Notion products and embarked on this journey of entrepreneurship, I did not know enough about entrepreneurship to come up with a product idea from my experiences, but I knew a bit of entrepreneurship and a bit of Notion. So I listened to public forums, reddit groups, search trends to find the concept that entrepreneurs were interested in, researched about what are the pillars of that concept and built that through Notion. The cross platform connection and the layer of conceptual understanding needed for anyone to build an EOS template worked pretty well for me.

This too takes time, and you've got to be a bit lucky to land on the emerging concept at the right time. But the truth is people are always looking for newer ways to do things, and it's just the right path for someone listening to those signals.

How I'm building my listening system

1. Growing demand signals

   • What: These are coming from user forums - dedicated subreddits, platform's community pages, Google search trends, Facebook groups (if relevant), and Youtube searches for things like "How to….", "<Platform name> apps for ….", "Guide for", "tutorial for …"

   • How: Using .rss feed for subreddits and community pages is quite reliable and sufficient - a make.com scenario or zapier/n8n automation from .rss feed to an LLM (filter and draw insight) to Notion (storage) has been working well. For google search trends it's a bit more complex - platforms like Ahrefs are quite effective, but also costly. So I've built https get requests scenario in make.com with relevant search queries to see what is the popular autofill as a proxy of it.

All this information goes into a Notion database, with insights such as "possible solution", "app idea", "idea score". Logic for each of these is defined in the LLM layer and a run happens every 12 hours to read signals from the last 12 hours.

I used this method to find my next Shopify app. I saw that there were questions related to agentic storefront, and whether their products are ready for the change. How is this different from SEO preparation, why are my apps not showing in chatgpt/gemini searches while my competitors do.

2. Bad supply signals

Ideally, the outcome of growing demand signals in 15 days leads to me filtering out 5 app ideas. And then asking a one time prompt to get me the existing solutions available for those ideas (not exact, but close competitors too). These then become input to track bad supply signals for:

• What: These are coming from app store reviews, G2/Capterra SAAS reviews, Community forum complaints about a specific feature/app from the platform, automation subreddits - which build a functionality by stitching together different platforms

• How: The appstore reviews and G2/Capterra reviews do not change drastically, so I get a Claude Chrome extension to surf and read the reviews and put them in a Notion database once a fortnight (for the specific solutions we shortlisted). The community discussions, and automation subreddit information is generated similar to #1, but the prompt to the intermediate LLM layer has to be different since the outcome has to be from reading failed solutions perspective - this is ongoing and I pull out the relevant discussions for the shortlisted solutions basis a prompt to Notion AI.

For my Shopify app scenario, I realized that there are relatively fewer apps for GEO/AEO (although in Shopify there's a bunch of apps for just about everything, so fewer is good). And the existing apps do cover store level analysis and readiness, but they do not cover the use case of product level analysis.

The work after this is straightforward. The shortlisted 5 app ideas are then mapped against their solutions, what kind of apps are available, how much of the problem is solved from it, and market sentiment for it. I only eliminate the apps that have stellar numbers of competing apps or stellar app reviews from users - which means the gaps will close sooner than I'll ship. But this is rare, because otherwise why would people be complaining about the problems and it won't become a growing demand signal. I rate the apps on supply signals and don't eliminate much.

The growing problem signals + what current solutions cover well + review of what's left is my minimal PRD for the app. This is then fed into a Claude skill which gives me the MVP feature list, and the complexity of building them - this is an important step since without the review of solutions and what's not covered you can never reliably say why that gap exists. Once you see the MVP feature list, user signals, market competition - it's your human knowledge, skill and experience to figure out whether this is a conceptual problem, one that takes real testing with users, or just a plug and play feature. If it's a plug and play, I keep that as a standby for an add on to something I might be developing later (these are gems for marketing by engineering where you give free apps to build traffic). If it's a conceptual problem then I go ahead with research and start building the product.

For the Shopify app - I researched the most relevant metrics which impact AEO/GEO results, the overall ecosystem of LLM searches and what really makes a difference and what is a good to have for your products to appear in searches. For e.g having LLMs.txt does not impact the results as much as you thought. But there are about 10 metrics that do, so I created Visibl - AI visibility score app which helps merchants get to the real cause of what is stopping their products from appearing in search results.

The system will only get better the more you time-test it. But the honest truth is I've just started. The paths are clearer now than they were in March. Whether this one leads somewhere — that's still being found out.

Follow me on X if you want to watch it unfold.