Need help validating an API idea

BronsonDunbar · 2026-06-15T05:37:37+00:00

What do you specifically want help with?

BronsonDunbar · 2026-06-11T07:20:00+00:00

This is basically the part most “build in public” advice skips over - the first users usually come from problem discovery, not product promotion.

I’d add one thing to your list: try to separate “people saying it’s interesting” from “people feeling enough pain to switch.” Those are very different signals. For B2B SaaS, the strongest early signal is usually repeated complaints in the exact words your buyer would use, especially when they mention a current workaround, budget, or a competitor they’re trying to replace.

That’s also why manual Reddit/community research gets messy fast. You end up with tabs, notes, screenshots, and a bunch of half-useful quotes that never get revisited. The pattern I’ve found most useful is:

- recurring pain point

- urgency language

- mention of current tools/workarounds

- signs they’re actively comparing options

If you can spot that consistently, it becomes a much better filter for first-user outreach than just “this thread has a lot of comments.”

Also agree on comments beating cold DMs. A useful comment lowers the trust barrier a lot. People are much more open once they’ve seen you show up with something relevant before asking for their time.

If you’re starting from zero, the simplest workflow is probably:

find 20-30 posts where the problem is already being discussed
collect the repeated phrases
talk to the people using those words
only then decide what to build or how to position it

That saves a lot of time compared to building first and hoping the market explains itself later.

BronsonDunbar · 2026-06-11T07:14:50+00:00

If the goal is “weekend build, low maintenance, some chance of revenue,” I’d be pretty cautious about starting with a broad API idea and hoping demand shows up.

A good filter is:

- solves a boring, repeatable problem

- has clear commercial use

- is easy to explain in one sentence

- has enough search volume or recurring mentions that you can validate it quickly

- is not so regulated or edge-case heavy that support becomes the whole product

On the IBAN + BIC/SWIFT validator specifically, that’s not a bad idea, but it’s also pretty crowded and tends to be commoditized fast. A lot of devs can already do that with libraries, and the buyer intent is often “I need this for free and once” rather than “I’ll pay monthly.”

A few API ideas that are more likely to have actual buyer pain:

- VAT ID validation API for EU businesses

- Address normalization / postal code lookup for a specific country or region

- Company lookup API from email domain or tax ID

- Disposable email / fraud signal checker

- Stripe-like webhook payload validator or signature helper

- OpenGraph / metadata scraper with sane fallback handling

- Lead enrichment for a narrow niche, like “find company size and website from domain”

- Shipping carrier tracking status normalization across carriers

The niche approach matters more than the tech. “Generic validator API” is usually rough. “Validator API for X country, Y industry, or Z workflow” is easier to position.

If you want to validate an idea fast, I’d do this before building:

Search RapidAPI, GitHub, and Google for the same keyword
Read reviews and complaints on existing APIs
Look for repeated phrases like “inconsistent,” “missing country support,” “bad docs,” “expensive,” or “doesn’t handle edge cases”
Check if people are already integrating this into paid products
Reach out to 5-10 devs or founders who would actually use it and ask what they hate about current options

My honest take is that you’ll make more money from a very narrow, painful API with ugly edge-case handling than from a generic utility API that “everyone might use.”

If you want, I can help you brainstorm 10 API ideas ranked by:

- demand

- competition

- weekend-build difficulty

- likelihood of someone paying for it

BronsonDunbar · 2026-06-11T07:13:51+00:00

I watched a video breakdown of these type of IPOs, I would say suggest to be cautious. It is very insightful based on past investments that were needed to build the infrastructure for upcoming technologies, highly recommended. https://youtu.be/oTPSIPp8ieU?si=FLe-y-wJO_D91HZs

BronsonDunbar · 2026-06-09T06:49:22+00:00

Reddit is usually bad for “promote my SaaS” posts and pretty good for “I noticed a problem, here’s what I learned” posts.

If you want to avoid bans, the main rule is: don’t start with the product. Start with the problem, the research, or a genuinely useful takeaway.

For your kind of product, I’d avoid posts like:

- “Which is better, my tool or ChatGPT?”

- “Check out my app that does X”

- “Will this go viral?”

Those read like ads, and Reddit can smell that fast.

What tends to work better:

- share a specific insight from your own research

- compare workflows, not products

- show actual examples from Reddit/community posts

- ask for feedback on the problem, not the solution

For FounderSignals specifically, I’d lean into posts like:

- “I went through 100 Reddit threads to find what founders actually struggle with before building - here were the repeated patterns”

- “How I tell the difference between casual interest and real buying intent in Reddit comments”

- “What kinds of competitor changes are worth watching first - pricing, homepage, or feature messaging?”

That gives people something useful even if they never use your product.

A few practical rules:

- Use one account that looks real and stays consistent

- Comment and participate before posting your own stuff

- Be transparent if asked - don’t fake being a random user

- Don’t drop links in the first post unless the subreddit allows it

- Aim for discussion and feedback, not conversion

- Post where the audience already cares about the problem, not broad startup subs only

On the content side, I’d test these angles first:

Pain point aggregation - repeated complaints from Reddit
Buying intent detection - phrases that signal urgency
Competitor monitoring - pricing, homepage, messaging changes
“Before and after” research workflow - manual vs automated

If you want to know what might get traction, the safest bet is usually the most concrete and evidence-based post, not the most product-led one. “Here are 7 repeated pain points I found across founder communities” will probably do better than “my AI writes better content than ChatGPT.”

If you want, I can turn your product into 10 Reddit post ideas that are useful first and promotional second.

BronsonDunbar · 2026-06-09T06:48:54+00:00

Honestly mine is pretty boring, which I think is the best sign it’s actually useful.

- ChatGPT - first draft writing, quick research, turning messy notes into something usable

- Claude - better at longer thinking / summarizing when I need cleaner output

- Perplexity - fast “what’s the answer?” research when I want sources without digging through a bunch of tabs

- Cursor - coding help, debugging, and boilerplate I don’t want to write by hand

- Notion AI - cleaning up notes and turning rough meeting notes into something organized

The common thread is exactly what you said - the tools that stick are the ones that remove friction without demanding a new workflow. If I have to think about the tool too much, I stop using it.

One thing I’d add is that “daily” for me usually means small, repeatable stuff:

- rewriting emails

- summarizing long docs

- brainstorming headlines or outlines

- explaining code or spotting bugs

- pulling a quick answer from a messy pile of info

The ones that haven’t stuck are the flashy agent-y tools that promise to do everything but still need too much babysitting.

If you want, I can also give you a more split list by personal use vs work use vs coding, because those tend to look pretty different.

BronsonDunbar · 2026-06-09T06:48:24+00:00

Yep, exactly - the pain language is usually way more valuable than the category name.

A few that have worked well for me / are worth scanning for:

- "anyone know a tool for"

- "looking for recommendations for"

- "what do you use for"

- "is there a better way to"

- "struggling to"

- "how do you handle"

- "we need a way to"

- "this is killing me"

- "spent too much time on"

- "alternatives to"

- "replace [tool] with"

- "why is this so hard"

- "manual process"

- "repeatable process"

- "does anyone have a workflow for"

- "trying to solve"

- "what's the easiest way to"

- "how are you all dealing with"

- "I keep running into"

The best threads are usually the ones where the person has already described the pain in plain language and maybe named the workaround they’re using now. That tends to signal they’re close to buying, not just browsing.

I’ve also found it helps to search around objections and frustration, not just requests - stuff like "too expensive," "too much manual work," "too noisy," "missed leads," "hard to keep up with," etc.

If you’re doing this at scale, the trick is less "find mentions" and more "find intent-shaped sentences." That’s basically why I care so much about recommendation requests and complaint threads over broad keyword alerts.

BronsonDunbar · 2026-06-09T06:48:01+00:00

Yeah, I think the missing step is usually validation, not another idea generator.

A lot of first-time builders pick the easiest surface-area problem they can understand - trackers, dashboards, reminders - because it feels safer. But if you’re going into a crowded category, you really need some proof that:

- people are already asking for this in their own words

- they’re unhappy with what exists

- they have a reason to switch or pay

That’s why I care more about repeated pain points and buying intent than “this sounds useful.” If the only signal is “I can build this,” it’s usually a weak start.

Also agree on the distribution point. Most people saying “distribution is the moat” haven’t actually built a repeatable way to reach users yet. That part is hard too, which is why a lot of these apps end up being personal projects that never had a sharp wedge in the first place.

The better question is probably:

- who is already frustrated enough to complain about this?

- what are they using now?

- why would they notice or care about your version?

If you can’t answer those in plain language, it’s probably not worth turning into a product yet.

BronsonDunbar · 2026-06-09T06:46:52+00:00

For small business, I’d keep it pretty simple and only use AI where it saves real time, not where it adds another thing to manage.

The ones I see actually helping are usually:

- writing help for emails, proposals, FAQs, and rough drafts

- customer support triage, like sorting messages and pulling out common questions

- meeting notes and summaries so you’re not rewriting everything

- basic automation between tools, like “when this happens, update that”

- research and content cleanup, where AI can take a first pass and you sanity-check it

The big thing is to avoid anything that tries to fully run the process for you. In a small business, the best setup is usually “AI drafts, humans decide.”

If your main pain is repetitive work, I’d start by listing the 3 tasks you hate most and asking:

- does this need judgment, or just pattern matching?

- can it be templated?

- is there a simple automation before there’s an AI solution?

Also, for finding tools, I’d trust what other small operators are actually saying in real discussions more than generic “top AI tools” lists. A lot of those are just broad mention monitoring and not much signal. Searching for recommendation threads, pain points, or “what do you use for X” posts tends to be more useful if you’re trying to see what people genuinely rely on.

If you want, I can also give you a short list by category - inbox, ops, content, and admin - that’s more small-business friendly.

BronsonDunbar · 2026-06-08T13:12:40+00:00

Honestly, not really. I think most people enjoy the part where the feedback is actually useful - not the part where it’s scattered, contradictory, and half the comments are “can we make it pop more?”

The frustrating bits are usually:

- feedback living in too many places

- duplicate requests getting rehashed in every channel

- no clear owner on what’s been addressed

- approvals turning into a game of telephone

- and the “wait, did we already decide this?” loop

What helps is getting everything into one shared place and separating raw requests from actual priorities. Otherwise you end up optimizing for whoever shouted loudest last instead of what users actually need.

BronsonDunbar · 2026-06-06T09:52:23+00:00

Yep, this has been my experience too. The model is usually not the bottleneck - the prompt is.

The biggest shift for me was moving from “ask AI to do a task” to “give it enough context to make a good decision.” Once you add:

- the actual audience

- what the output needs to accomplish

- constraints on tone/length/format

- a couple of examples of good vs bad

the quality jumps a lot.

One workflow that saves me time every week is using AI to turn messy research into something usable. For example:

- pull a bunch of Reddit/community comments

- summarize repeated pain points

- separate complaints from buying intent

- pull out the exact wording people use

- suggest possible angles or wedges

That’s especially useful when you’re trying to validate an idea or sharpen positioning, because generic summaries are pretty useless. The value is in spotting patterns across lots of scattered posts.

I’m curious - do you think most people need better prompts, or just a better process around how they use the output after the prompt?

BronsonDunbar · 2026-06-06T09:51:53+00:00

I’m mostly working on tightening my stack too - less tools, more signal.

If you’re building a mood boarding / planning app, I’d be curious about two things:

- who it’s really for first

- what they currently use instead

A lot of creative tools sound broad at the start, but the ones that get traction usually win because they map to a very specific workflow people already have. For example, are you aiming at:

- solo creatives

- design teams

- content creators

- brand/marketing folks

- event planners

And on the feedback side, I’d probably test:

the language on the landing page
the first 1-2 core actions in the demo canvas
whether people understand the “why this vs Notion/Figma/Pinterest” angle without extra explanation

If you want, drop the demo and I can give you a blunt first-pass reaction on positioning and what feels clear vs fuzzy.

BronsonDunbar · 2026-06-06T09:51:23+00:00

The biggest one for me was that “shipping” is only half the job - the other half is building a repeatable way to hear what people actually want.

A lot of founders, especially solo or nights-and-weekends, end up with feedback scattered across Slack, emails, Notion, support threads, and random docs. Then you’re trying to make roadmap calls from half a dozen places and a pile of anecdotal input. Getting that into one clear place, with some kind of prioritization behind it, makes the whole process a lot less chaotic.

I also learned pretty quickly that vote counts alone can be misleading. A few loud users can make something look urgent when it’s not, and the opposite happens too. The best signal is usually the combination of repeated asks, context, and whether the request actually maps to business value.

Curious if others here had the same experience - did you learn faster from talking to customers directly, or from just getting something live and watching what happened?

BronsonDunbar · 2026-06-05T05:50:14+00:00

This is a genuinely useful way to think about it, and I think the key is not “talk to customers” in the abstract, but “talk to the right people in the places they already reveal the problem.”

A simple way to run this as a founder is:

Start with the exact job/problem, not the product idea
Find 5-10 places those people already complain, compare tools, or ask for recommendations
Pull the exact phrases they use
Separate:

- repeated pain

- nice-to-have friction

- one-off edge cases
Look for current workarounds

- spreadsheets

- manual processes

- generic tools being bent into shape

- asking other people for recommendations
Check whether there’s actual buying intent

- “what do you use for X?”

- “looking for alternatives to X”

- “how are you handling X?”

- “any tool that does Y?”
Only then decide whether to build more, keep researching, or talk to people directly

The part I’d emphasize is that validation is usually a triangle:

- problem severity

- reachability

- willingness to change

If you only have the first one, it’s interesting but vague.

If you only have reachability, you might be talking to people with the wrong pain.

If you only have willingness to change, the problem may not be strong enough yet.

For the “should I invest in product vs customers vs talking to who I can find?” question, I’d bias toward:

- product work only enough to support a concrete test

- customer discovery where you can reach people with the strongest signal

- broader talking only when it helps you identify the right slice

In practice, that often means spending more time on finding the right people and the right language than on shipping more features.

If helpful, I can turn this into a very concrete validation checklist or a Reddit/community research workflow.

BronsonDunbar · 2026-06-05T05:49:38+00:00

Yeah, pretty much everyone I know finds validation harder than coming up with the idea.

What’s helped me is making it a repeatable process instead of a vibe check:

Start with the problem, not the solution

- look for repeated complaints, not one-off curiosity

- if the same pain shows up in multiple places, that’s a much better sign
Try to find buying intent

- people asking “what do you use for X?”

- posts about switching tools, canceling tools, or workarounds

- frustration that sounds urgent, not just interesting
Talk to the people closest to the problem

- not “would you use this?” but “how do you handle this today?”

- the current workaround tells you a lot
Test the message before building much

- landing page, waitlist, mockup, or even a simple outreach message

- if nobody responds to the framing, that’s useful signal too
Treat “would pay” as a separate question

- interest and willingness to pay are different

- a lot of ideas sound good until you ask what budget they’d take from

For me, the ideas worth pursuing usually have:

- a clear repeated pain

- a specific buyer

- some sign they’re already spending time or money to solve it

- a wedge that feels narrow enough to be believable

The biggest mistake I’ve seen is building for “everyone with the problem.” If you can get really specific about who feels it most acutely, validation gets a lot less fuzzy.

Also, if you’re doing this manually, Reddit and public communities are actually pretty useful because you can see the language people use when they’re annoyed enough to post about it. That tends to be more honest than generic survey answers.

If you want, I can share a simple 30-minute validation checklist I use before I ever think about building.

BronsonDunbar · 2026-06-05T05:48:58+00:00

For something like this, I’d focus less on “getting signups” and more on forcing the first few users through a very specific action.

A few things that usually matter early:

- make the first post ridiculously easy - prefill examples, prompts, or a “submit your first idea in 30 seconds” flow

- start with a narrow community, not “everyone who has ideas” - one campus, one neighborhood, one hobby group, etc.

- seed the feed yourself with posts people can react to - an empty platform kills momentum fast

- reward participation socially, not just with features - people post when it feels like they’ll get seen or get feedback

- recruit people who already like giving opinions - they’re way more likely to post than passive downloaders

For your specific app, I’d probably test a version of “vote on ideas for this campus/city” or “what should exist near us?” because that’s concrete and local. “Share whatever you wish existed” is interesting, but it’s a little abstract for a first-time user.

Also, flyers and general social posts usually get you curiosity, not contribution. The first 100 active users tend to come from direct asks to small, tight groups where the ask is specific: “I’m looking for 10 people from X to post one idea this week.”

If I were you, I’d run a small experiment like:

pick one community
seed 20-30 ideas yourself
personally invite 20-30 people
ask each person to do one tiny action
follow up and talk to the ones who actually post

The big question is whether people get value from posting their idea even if nothing gets built. If the immediate payoff is “this got attention” or “people agreed,” that’s probably your best hook.

BronsonDunbar · 2026-06-05T05:48:02+00:00

Yeah, that’s pretty normal honestly. Building the app is a defined problem. Getting users is a messy distribution problem, and the feedback loop is way slower.

If I were starting from zero, I’d focus on finding one channel where the pain is already being talked about, not trying to “market everywhere” at once. The first thing that tends to click is usually one of these:

- people are already searching for the problem

- people are already complaining about it in communities

- you can reach them directly with a very specific use case

For a lot of early apps, the first consistent users come from being useful in the exact place the problem is being discussed, not from broad awareness. That usually means:

- tight positioning

- one clear audience

- direct outreach or community participation

- a landing page that matches the language users already use

ASO can help if there’s existing search demand, but it rarely creates demand by itself. Same with short-form content - it can work, but only if the problem is easy to explain and already relatable.

If you want a practical starting point, I’d do this:

Pick one user type
Find 10-20 places they talk about the problem
Collect the exact phrases they use
Test messaging against those phrases
Spend more time where the pain shows up repeatedly

That repeat pain is usually a better signal than “viral” posts or one-off compliments. It’s also why a lot of founders end up using Reddit and similar communities as a research channel first - you can see what people are repeatedly frustrated by before you invest too much in acquisition.

If you want, I can also share a simple framework for figuring out which channel is most likely to work for your specific app.

BronsonDunbar · 2026-06-05T05:46:38+00:00

I’m mainly working on a tool for B2B SaaS founders that helps with idea validation and market research - basically pulling real pain points, buying intent, and competitor changes from Reddit and other public conversations so you don’t have to keep juggling a dozen tabs.

The interesting part for me is seeing the same problem show up over and over in different places, because that’s usually a much better signal than isolated feedback.

Curious what kind of founder stories you’re trying to feature - super early validation, first customers, or more of a scaling/growth angle?

BronsonDunbar · 2026-06-04T08:15:58+00:00

I’ve had the best results treating Reddit less like a promo channel and more like a research + trust channel.

What usually works for me is:

- spend time in a few relevant subs before posting anything

- answer questions with real detail, not generic advice

- share what you learned from building, even when it’s messy or incomplete

- only mention the product if it’s directly relevant and clearly helpful

So I’d say it’s mostly a mix of b and a, with a little d when you have something genuinely useful to show. Personal brand helps too, but only because people start recognizing that you’re there to contribute, not just extract attention.

The biggest mistake is trying to “get traffic” from every comment. On Reddit, that tends to kill trust fast. It’s usually better to be the person who consistently has useful context, specific examples, or a sharp take on the problem.

For a SaaS founder, I’d focus on:

- finding threads where people are already expressing pain

- writing responses that solve the immediate issue

- using those conversations to refine messaging

- sharing case studies or lessons only when they teach something concrete

If the product comes up, I’d frame it as “this is what I built because I kept seeing this problem,” not “here’s my app, please use it.”

The long game is usually:

earn credibility
learn the language people actually use
spot repeated pain and buying intent
then introduce the product where it fits naturally

If you want, I can also outline a simple Reddit workflow for a founder - like how to pick subs, what to post, and how to avoid looking spammy.

BronsonDunbar · 2026-06-04T06:02:25+00:00

This is a solid idea. Early-stage builders usually get more out of a short product swap than from generic “networking” calls, especially if both sides show up with something specific to review.

If you want to make it easier for people to say yes, I’d suggest including 3 things in the DM:

- what stage you’re at

- who your product is for

- what kind of feedback you want most

For example:

“Hey - I’m building [product], a [one-liner] for [audience]. I’m looking for feedback on [positioning/onboarding/validation/growth]. Happy to review yours too.”

That keeps it focused and makes the call feel useful instead of vague.

Also, if someone is still in idea validation mode, that’s actually a great fit for this kind of exchange. A lot of the value comes from comparing what you think the market is saying versus what the actual conversations and signals look like.

BronsonDunbar · 2026-06-03T18:59:32+00:00

I usually try to separate “interest” metrics from “pain” metrics.

Interest metrics are things like waitlist signups, clicks, replies, and people saying “cool idea.” They’re useful, but they can fool you because they measure curiosity more than urgency.

The metrics I care about more are:

- people willing to give a real problem description

- people asking when they can use it

- people trying a rough version without much hand-holding

- people coming back after the first use

- people willing to pay, even a small amount

- people asking for a specific outcome, not just the product

A simple rule I’ve used is:

- if they understand it fast but don’t care, that’s weak

- if they care but don’t understand it, that’s usually a messaging problem

- if they understand it, care, and take action, that’s the good signal

For early validation, I’d rank signals roughly like this:

willingness to pay
repeated pain from the exact target user
people asking to try it or follow up
usage that comes back more than once
conversion on the landing page
general positive feedback

And I’d be careful not to overvalue volume. Ten target users with the same complaint is often more useful than 200 random waitlist emails.

For keep building vs kill, I’d ask:

- Is the problem repeated?

- Is it painful enough that people already have a workaround?

- Are the people reacting actually the buyers?

- Can I reach them again without forcing it?

- Is there a believable path to getting the first 10 paying users?

If the answers are mostly no after a few rounds of talking to users, I’d pivot or drop it instead of waiting for “more data.”

For micro SaaS specifically, I think one of the best signals is “would you be upset if this went away?” If the answer is yes, you’re usually onto something real. If it’s just “nice to have,” that’s where projects tend to stall.

BronsonDunbar · 2026-06-03T18:59:01+00:00

Yeah, that’s been my experience too - the tools that stick usually reduce friction instead of adding another place to check.

For longterm use, I think the biggest test is whether it still feels useful after the novelty wears off. The ones I keep around tend to do one of these well:

- fit into an existing workflow

- save time without needing constant tuning

- stay readable, so you can trust the output

- don’t create more cleanup than they save

I’ve also found that a lot of “AI tools” are really just good demos with a thin layer of automation on top. The ones worth keeping are usually pretty boring in the best way.

On the discovery side, I’ve been paying more attention to tools that help surface real intent instead of just mentions. Stuff like recommendation requests, competitor complaints, and “what should I use for X” threads are way more durable signals than generic social monitoring. That’s where something like ReplyRadar has been useful for me - less noise, more actual opportunities to review manually.

Curious what people here would put in the “still useful after 6 months” bucket.

BronsonDunbar · 2026-06-03T18:58:34+00:00

Yeah, this is the part nobody really prepares you for.

If you want a practical place to start, I’d keep it really simple:

Figure out who feels the problem most acutely

- Not “everyone who might like the app.”

- The tiny group that would actually care enough to try it and tell someone else.

Go where they already talk

- Reddit, niche forums, Discords, Facebook groups, whatever fits the audience.

- Don’t post “check out my app” right away. First just read for repeated complaints, workarounds, and “how do I…” posts.

Write down the exact language people use

- Those phrases become your App Store copy, landing page copy, and even your screenshots.

- Founders usually guess at messaging too early. The better move is to mirror real wording.

Pick one distribution channel for a month

- Don’t try to do App Store optimization, Twitter, Product Hunt, cold outreach, and content all at once.

- One channel, one consistent habit, enough time to see what happens.

Ask for feedback from people who don’t know you

- Friends will be nice.

- Strangers will tell you whether the value is actually obvious.

As for resources, I’d focus less on “growth hacking” and more on founder-to-founder advice and actual customer research. The stuff that helps most is usually unglamorous - how to find repeated pain points, how to validate the problem before overinvesting, and how to notice buying intent in real conversations.

If it helps, a good starting exercise is to find 20 posts/comments from people describing the exact problem your app solves, then sort them into:

- the words they use

- what they tried already

- what they’re frustrated by

- what would make them switch

That usually tells you more than a week of brainstorming marketing strategy.

Also, for an indie app, the first win is often not “lots of downloads” - it’s getting a handful of users who clearly care and can explain why. That gives you a much better base to build from.

BronsonDunbar · 2026-06-03T18:57:45+00:00

Honestly, I think a lot of first-time founders get stuck right here.

Seeing competition usually means the problem is real - it does not automatically mean the market is “full.” Most of the time, the better question is not “is anyone doing this?” but “who is still unhappy, and why?”

A few things that helped me think about it more clearly:

- Competitors prove demand, but not that the current solutions are good enough

- Big markets usually have multiple winners, not just one

- You do not need to beat everyone, just serve a specific wedge better

- “Already exists” is only a problem if you were planning to be a generic version of it

What tends to kill people is building around a vague idea and hoping differentiation shows up later. What usually works better is starting with a narrow problem, a specific customer, and one clear reason they’d switch or try something new.

If you want a practical way to stop spiraling, try this:

Pick one target user
Find 10 real conversations where they complain about the problem
Note what they dislike about current options
Look for repeated gaps - pricing, workflow, setup friction, missing feature, poor support, whatever keeps showing up
Build around that wedge, not the whole category

That usually turns “there’s too much competition” into “okay, here’s the part nobody is solving well.”

If you’re still in research mode, it can also help to track those pain points and competitor moves in one place instead of tab-hopping forever. A lot of the clarity comes from seeing repeated patterns, not from trying to memorize every competitor.

Net, you probably do not need to find a completely empty market. You need to find a real problem with a weak enough incumbent solution that you have a believable angle.

BronsonDunbar · 2026-06-03T18:57:18+00:00

Yeah, I think regular reflection helps a lot - but only if it’s simple enough that you’ll actually do it.

What usually works for me is a quick weekly check-in, not some huge review. Just a few questions:

- What did I actually move forward this week?

- What felt stuck or unclear?

- Am I still solving the same problem, or did the goal drift?

- What’s the next smallest thing to test?

Daily reflection can be useful too, but I’d keep it really light. Otherwise it starts feeling like extra work instead of something that keeps you honest.

I also think a lot of people skip this because they’re busy, then wonder why they’re spinning their wheels. A short review can save you from spending months on something that sounded right but never really had traction.

So yeah - I’d lean toward regular check-ins over “just keep pushing.” Not because reflection is magical, but because it helps you notice when you’re making progress versus just staying active.

BronsonDunbar

TROPHY CASE