SaaS ideas your next customers are already looking for
100 SaaS startup ideas for the people who said they'd pay, from agency owners to dentists. Micro SaaS ideas, AI SaaS ideas and B2B SaaS ideas: find yours, build it, sign them up.
Popular:
| # | Idea |
|---|
No idea matches this filter.
Pain points in business: what people struggle with
Search the problems to solve, as people described them on Reddit and other platforms, in their own words.
Popular:
| # | Pain point |
|---|
No pain point matches this filter.
Duplicate Actions on Retry
Retries and duplicate webhooks re-execute non-idempotent actions, causing duplicate charges, emails, writes, and other irreversible side effects.
In their words
i was treating accepted as sent and only finding out from the reply rate days later.
Another developer suggested submitting the exact same financial records in two separate requests at the same time. Our requests were 3 milliseconds apart.
there's a payments bug where users are getting charged twice on some screen transition
by the time something looked wrong the transaction was already done even though everything we had was reactive, alerts and monitoring after the fact
when a subscriber pod is preempted mid-processing, Pub/Sub redelivers the message ... and re-runs the pipeline
order accepted → socket drops → order fills while disconnected → socket reconnects → local db still says OPEN
Time and time again, they'd have a brief outage where their CDN provider would interrupt my call and return a 404. Soon my copy of my catalog would be empty!
treat every action node as if it might run twice, because in production it will
If a marker was already read and committed on a partition before the rebalance, the new consumer instance will never see it, and the system will hang forever.
I cannot find a native approach or non-patchy workaround to only retry on certain conditions (like based on exit codes).
my agent crashed mid-run, restarted, and sent the same email twice to a customer
Retrying might repeat the action. Skipping it might leave the workflow in the wrong state.
these details usually live in one paragraph of prose in the docs, not in the OpenAPI spec, so client generators and retry middleware have no way to know about them
The chunked one checked whether the exact file had already been processed... The direct route never got that check. They had drifted apart
automation and backend developers
Where they talk
- r/AI_Agents
- r/n8n
- r/automation
- r/LLMDevs
- r/mcp
- r/ethdev
- r/indiehackers
- r/LangChain
Tools they use today
- n8n
- PostgreSQL
- Stripe
- Redis
- Kafka
- Make
- SQS
- Zapier
Why those fall short
- validation runs too late, after the first request has already passed checks
- audits are snapshots; monitoring only reports after state already changed
- no built-in protection against duplicate processing on preemption
- polling wasteful, race conditions when events arrive after snapshot
- no enforced reply, no timeout or give-up event, no public/private api separation
Map of ideas
Drawing the map…