Build a recurring painkiller, not a nice-to-have
Before my current tool, I built "interesting" projects.
Cool looking side projects. Clever technical abstractions. Tools that made people say "that's neat."
None of them made consistent money.
Here's what changed with the one that actually worked:
1) "Interesting" doesn't convert to paying
Most indie hackers build tools that are fun to try but easy to forget.
Signs you've built a nice-to-have:
people sign up, poke around, and never come back
free users love it but won't pay
you can't explain the ROI in one sentence
I had all three with my earlier projects. People thought they were cool. Nobody needed them.
The tool that actually makes money? It solves a problem people already spend hours on every week. They don't use it because it's interesting. They use it because not using it costs them time and money.
2) Recurring problems = recurring revenue
If your tool solves a one-time problem, you need a constant stream of new customers just to stay flat.
But if you solve something that comes back every week, a workflow that's broken, a task that eats hours, a process that never goes away, people keep paying because the problem keeps existing.
Unless you already have massive distribution, it's really hard to bootstrap without recurring revenue. One-time purchases mean you're always starting from zero.
3) The ROI has to be obvious
The easiest sell is when the user can measure what your tool saves them.
"I used to spend 3 hours a week doing this manually. Now it takes 10 minutes."
That's not a feature. That's a reason to keep paying.
If your users can't articulate why they're paying in one sentence, your tool is probably a nice-to-have.
Before you think about marketing, distribution, or growth, ask yourself:
Am I solving a real, recurring problem where the ROI is obvious?
If yes, everything else gets easier.
If no, no amount of marketing will fix it.
This single insight mattered more than any tech, UI, or feature I ever built.
If you want to see my painkiller tool that solves a recurring problem, check it out here.
Happy to answer any questions or go deeper on this!
That’s great insight. Exactly what I’m trying to fo
Glad it was helpful!
something interesting about “painkiller products”:
they rarely replace another tool.
they usually replace a workaround people already have.
a spreadsheet, a manual process, something that sort of works until the pain becomes real.
once a product clearly replaces that workflow, positioning becomes much easier.
That's true
Strong advice. Products that solve recurring pain usually have the strongest retention.
💯
Does it solve a problem that people will keep paying for every month? Craft your offer, start sending DMs and see what what signals you get
This is such a good breakdown…
The “interesting vs needed” point hits hard. Tools that save people hours every week almost sell themselves.
Glad you liked the breakdown!
that's really true
Letting them experience value first seems much more effective.
💯
This is a really solid breakdown. The difference between a “nice-to-have” and a true painkiller is something a lot of founders only understand after building a few projects that people like but don’t actually need.
The point about recurring problems creating recurring revenue really resonates. If the problem only happens once, you’re constantly chasing new customers, but if it’s tied to an ongoing workflow, the product becomes part of the user’s routine.
I also like the ROI framing. When a user can clearly say “this saves me X hours per week,” the value becomes obvious and the product almost sells itself.
Out of curiosity, how did you initially identify the recurring problem your current tool solves? Was it something from your own workflow or something you observed from users?
There were competitor tools that were already making recurring revenue, and I knew I can compete with them so I started building one
This is a great point.
Many founders build things that are interesting but not painful enough for users to pay for.
In your experience, what's the best way to identify a real "recurring pain" before building?
See if there are competitor tools that are already make recurring revenue and you feel like you can compete with them
Love this article. Will definitely check out your product!
If you're on X, send me a DM and I'll give you tips for marketing on Reddit + would love to hear your feedback
This is such a crucial distinction. The "vitamin vs. painkiller" analogy is classic for a reason. I've personally seen how much easier it is to sell something when the ROI is immediate and obvious. For my recent $9 AI prompt vault, the 'pain' was the time spent engineering prompts from scratch, and the 'painkiller' was the instant access to proven templates. It's all about that time-saving value prop!
This hits home. I’ve been building 6 AI apps while working full-time, and the ones that stick are the ones solving a daily workflow pain — not the clever-sounding side projects. My content repurposing tool took off because creators were already copy-pasting between platforms every day. The “can you explain the ROI in one sentence” test is underrated. If you can’t, you’re probably building a vitamin.
Great outlook. Although not every tool is built to solve an everyday problem. Some problems are not as frequent. Should we not build for that user problem?
The interesting vs painful problem line is so true.
I think a lot of devs build stuff that’s fun to make instead of stuff people actually need every week.
Did you discover this problem from your own workflow or from talking to users?
This is true. Tools that solve real problems win.
It's why people decide to keep paying you
This is really interesting. What was the hardest part in building the first version?
Building the MVP was easy. It was fixing churn and making the tool more valuable that was harder because I had to pause marketing and delay growth, but it was the right decision because once my funnel was fixed my growth exploded
The 3 hours vs. 10 minutes point really resonates. Working inside a company, I see so many manual workflows that eat up half a day every week just because that's how we've always done it. There's a massive gap between what looks good in a portfolio and what actually solves the friction we feel during a Tuesday afternoon grind. Thanks for the reminder to focus on the pain, not the features.
I believe there's going to be an explosion of local AI workflows soon
Great insight. This really highlights a mistake a lot of creators make—building something cool instead of necessary.
As a digital creator, I’ve seen the same pattern with online tools and content products, especially on platforms like Id Portal. People might love trying something new, but they only pay for things that solve a real problem they face repeatedly. If a product saves time, reduces effort, or directly helps them earn or protect money, the value becomes obvious.
The point about recurring problems leading to recurring revenue is especially important. When a tool becomes part of someone’s weekly workflow, it stops being a “product” and starts becoming infrastructure for their work.
Really valuable reminder: before focusing on features or marketing, make sure the problem is painful enough that people actually need the solution.
Glad you liked it!
Great question. For me, the biggest signal was user behavior after the initial curiosity phase.
People would sign up, explore the tool for a few minutes, maybe say “this is cool,” but then usage would drop off quickly. When something actually solves a recurring pain, you don’t have to convince users to come back they return because the problem keeps showing up in their workflow.
Another big signal was willingness to pay. If users like the idea but hesitate when pricing is mentioned, it usually means the problem isn’t painful enough yet.
That realization is what made me focus more on tools that remove repeated friction in people’s workflows. When the time saved or effort reduced is obvious, the value becomes much easier to communicate.
This resonates a lot. I feel like a lot of builders (especially in AI right now) fall into the “interesting demo” trap.
There are tons of tools that are impressive technically, but when you step back and ask “what weekly pain does this remove?” the answer isn’t very clear.
The point about recurring problems = recurring revenue is especially important. If the problem shows up every week in someone’s workflow, the tool becomes part of their stack instead of something they try once and forget.
Curious about one thing: when you were building the earlier “interesting” projects, how did you eventually realize they were nice-to-haves? Was it user behavior, lack of willingness to pay, or something else?
When no one agrees to pay you monthly for your offer, that's a clear indicator that your tool doesn't solve a recurring problem
@filippanoski that's a key distinction worth making. Fraud-sourced failures (fake cards, never intended to pay) and genuine card failures (real customer, card expired or declined) need completely different responses. Dunning only helps the second case. RecoverKit is built for the second case: legitimate customers whose cards fail after they've been actively paying. For a B2C product with free trials, fraud-sourced failures can dominate. For B2B or products that require a card upfront, it flips — most failures are genuine. What's your current model — free trial with card, or pay upfront? That would tell you a lot about whether recovery emails would move the needle.
Free trial with a card
The ROI test is the one I always come back to. If a prospect can't clearly explain why they paid in one sentence, you either have a positioning problem or a nice-to-have product.
The best products I've seen get used because stopping would cost the person time, money, or a workflow that falls apart without it. Some questions I like to ask to assess how much value this potentially provides
1) how have you tried to solve this problem before
2) who else cares about this problem
If they haven’t tried or spent the time to solve this before, then it tells you that it's not that important. Also, typically if no one else cares about this problem, then it can be a difficult change to make, assuming this is a solution that applies to multiple people.
Love these questions!
There's a version of the recurring problem that's easy to miss: pain that's structural and social, not just operational.
I'm building for neurodivergent people who have to re-explain how they communicate to every new friend, coach, co-worker, or partner. The problem doesn't get easier over time. It just repeats every time their world changes. That's a different kind of painkiller than "saves you 3 hours a week."
One signal I've noticed in user interviews: if someone describes the problem in present tense with "every time" or "every new person," you've likely found something real. Past tense usually means they've adapted or given up.
Interesting perspective. The difference between a “nice-to-have” and a real painkiller is something I’m trying to understand better.
Sometimes a problem exists, but users still tolerate it for years instead of paying for a solution. In those cases the pain is real, but maybe not strong enough to trigger spending.
Have you found any signals early on that helped you tell the difference between a problem people complain about and one they will actually pay to solve?
See if there are competitors where people are paying monthly
Most ideas start out in our minds as painkillers but are simply nice-to-haves in disguise. The self-deception is almost built in. You feel the pain yourself so you assume others feel it the same way. I've struggled with this too.
I'm building Flanq AI right now, competitive intelligence briefs for bootstrapped SaaS founders. When I first conceived it I told myself it was a painkiller because founders need to know what competitors are doing. But your third point hit hard. Can my users articulate why they're paying in one sentence?
The painkiller version is: 'Your competitor just hired an ad engineer, and you won't find out for three months. Flanq finds it for you every Monday, so you don't have to.' The nice-to-have version is: 'Stay informed about your competitive landscape.' Same product. Completely different pain level.
The other painkiller angle is time. Founders who do this manually spend hours every week or month on research and analysis they never quite finish. Flanq gives them that time back with the synthesis already done.
The one-sentence ROI test is the cold water. If you can't say it cleanly, you probably haven't found the real pain yet. Still figuring out which version actually resonates when I talk to real founders.
Love the positioning shift
The "recurring painkiller" framing is one of those things that sounds obvious but most builders still miss. I'm exploring a tool for digital nomads right now and the initial instinct was to build a "destination guide" — basically a nice-to-have. But every conversation I have with actual nomads reveals the same recurring pain: they keep showing up to places at the wrong time. Wrong season, peak crowds, overpriced. It happens every single move, not just once. That pattern is what made me realize there might be something worth building. Your framework would've saved me weeks of going down the wrong path.
Recurring painkiller ideas are harder to come by!
I had a conversation today with my co-founder and you literally 1:1 quoted the things I said.
Love your article! Will deffinetely check your product.
plot twist: I am your co-founder
This really hits home. I'm building a travel eSIM store that accepts crypto payments and the "recurring painkiller" framing is spot on. Travelers don't need eSIMs once — they need them every single trip. That's what made me confident in the idea early on.
The ROI point is huge too. When someone lands in a new country and needs data NOW, the value prop is painfully obvious. No explaining needed. That's when you know you've got something.
Curious how you think about the balance between solving a clear pain vs. building for a niche that's too small? I wrestle with that sometimes — crypto + travel is growing fast but it's still pretty specific.
Easier to start making money in a small growing niche because you can position yourself uniquely and solve a very specific problem without competing with big companies
Very interesting take.
For me, your third point that the ROI has to be obvious is probably the strongest and a great way to iterate on ideas. No chance you can sell anything if you can't explain in a few words why anyone would buy it. I really like that it forces you to have an actionnable pass or fail test component to it and that it can help you throw away ideas that seemed interesting but are just abstract.
Thanks for sharing
Hope it was helpful!
This framework of "recurring painkiller vs nice-to-have" really resonates.
When I started building my own tool, I thought I knew what the recurring pain was. But it wasn't until I became my own first user for 30 days that I saw the gap.
I used my own MVP daily, logged every decision, and watched my own behavior. What I found:
- The "pain" I initially built for was real, but it was a symptom of a deeper recurring friction I hadn't noticed.
- The features I thought were essential? ~40% turned out to be noise once I actually used the tool in my real workflow.
- The ROI became obvious only after I experienced the time saved myself—not from guessing, but from tracking it.
Dogfooding first turned my nice-to-have assumptions into a painkiller I could actually defend. If you're unsure whether your tool solves a recurring problem, becoming your own lab rat for 30 days will tell you faster than any survey.
Appreciate you sharing this—it's the kind of lens every builder needs early on.
Using your own product daily really helps you understand it better
This resonates a lot. A lot of builders fall into the trap of optimizing for interesting instead of necessary. If a tool isn’t tied to a recurring workflow or a clear cost of not using it, it’s very hard to turn it into a sustainable business. The ROI framing you mentioned is especially important—when users can clearly see the time or money saved, the decision to pay becomes much easier.
This will either make or break your business
You’re spot on. I’ve seen plenty of "cool" products gather dust because, at the end of the day, people don't buy cool—they buy value. To build something that actually sells, you have to nail that specific "it" factor that makes someone reach for their wallet.
100%
This is the 'cold shower' every solo engineer needs. I’ve recently shipped my first SaaS, and the biggest lesson hasn't been the code.. it’s the onboarding.
Non-technical users don't care about our clean API or modular architecture; they care about 'How do I get my result in 3 clicks?' I’ve spent more time writing simple documentation and stripping away 'cool' features than I did building the core engine.
If a 'painkiller' is too hard to swallow (bad UX/onboarding), the customer will just live with the pain. Simple always beats powerful for the first 30 seconds of a user's experience
As developers, it's hard to shift the mindset from code to people
Totally agree.
This is exactly the kind of product story that works really well in a short launch video. Showing the recurring pain, the manual workflow, and then the “10 minutes instead of 3 hours” moment visually can make the value click immediately for new users. I help SaaS builders turn their product into clear launch/demo videos that drive signups, so if you ever plan to push this harder I'd be happy to help with that.
Totally agree. Products that solve real pain points naturally create recurring demand. The challenge is identifying the right problem early.
Yeah, it's harder to find painkillers that you can compete it, but it's what will make or break your business
Exactly. The real challenge isn’t building the product, it’s identifying a painful enough problem that people are willing to pay to solve. How do you usually validate that early?
To validate idea: see if there are competitors that are already making recurring revenue and you feel like you can compete with them
To validate distribution: build a LP with a waitlist, and start sending your offer to people
The churn investigation section is the most underrated part of this post. Most founders at 100 MRR immediately think 'I need more users' — but pausing to understand why people leave is almost always higher leverage.
One thing worth checking: how much of that churn was involuntary? Failed payments are responsible for 20-40% of subscription churn on average — customers who intended to stay, their card just expired or got declined. It's invisible because there's no 'I want to cancel' signal, just silence.
Mentioning because Bazzly fits your own framework perfectly: recurring problem, obvious ROI, measurable dollar amount saved. Curious if you've dug into the payment failure side of your churn numbers.
Almost all of my failed payments are from fake cards that were never charged in the first place
Great point. A lot of tools are interesting but not essential.
I'm currently building a small tool for editing static websites, and this is exactly the question I'm trying to answer: does it actually solve a recurring problem or is it just convenient?
Thanks for sharing this insight.
Good luck with your tool!
This is gold. The part about solving recurring problems rather than one-off ‘nice-to-have’ tools really hit home. Also, your emphasis on talking directly with users instead of just looking at analytics is super valuable
Glad it was valuable!
Building something users want. Thanks for sharing this
This is the core
I think it depends what you are selling. If you are solving a problem that is event driven, like looking for an apartment or also dating, a one time payment could also bring good money.
Not everything has to be a subscription..
I'm talking about bootstrapping a SaaS business.
One time payments can work if you have large distribution, but if you don't it's going to be extremely hard to bootstrap without recurring revenue
This comment was deleted a month ago