Every pricing thread on Indie Hackers eventually devolves into the same debate: subscriptions vs. one-time payments. I've shipped three products as a solo dev, and I went with lifetime pricing on all of them. Here's why — and what actually happened.
The Subscription Trap for Small Tools
Subscriptions make sense when you're delivering ongoing value that costs you money to provide — cloud storage, streaming content, server-side compute. But most developer utilities don't work that way.
If I build a menu bar app that runs entirely on your machine, what exactly am I charging you monthly for? The privilege of continued use? That feels wrong, and users know it.
I watched indie devs launch $5/month utilities and spend more time fighting churn than building features. The math doesn't lie: a 5% monthly churn rate means you're replacing half your user base every year. For a solo dev, that's a treadmill.
What Lifetime Actually Looks Like
Here's my real setup:
- TokenBar — $5 lifetime. It's a macOS menu bar app that tracks LLM token usage in real time. No server. No account. It runs locally. Charging monthly for this would be absurd.
- Monk Mode — $15 lifetime. A focus tool that blocks feeds (not entire apps). Again, fully local.
The moment someone pays, they're done. No renewal anxiety. No cancellation flow. No "is this still worth $5/month?" internal debate every billing cycle.
The Numbers Nobody Talks About
Subscription apps have higher theoretical LTV. But theory assumes retention. In practice:
- A $5/month app with 8-month average retention = $40 LTV
- A $15 one-time purchase = $15 LTV but with zero churn infrastructure
The second model means I don't need Stripe webhooks for failed payments, dunning emails, grace periods, or a "win-back" campaign. I don't need a customer success function. I build the thing, people buy it, done.
For a solo dev, that operational simplicity is worth more than the theoretical revenue gap.
When Lifetime Pricing Breaks
I'm not naive about the downsides:
- No recurring revenue — You need a constant stream of new customers
- Feature expectations — Some users expect lifetime updates forever
- Scaling costs — If your app has server costs, lifetime pricing can destroy you
The fix for #1 is simple: build things people search for. SEO and word-of-mouth do the work over time.
For #2, I set clear expectations: major version upgrades may be separate purchases. Most users are fine with this.
And #3 is why I only use lifetime pricing for local-first apps. If it runs on their machine, there's no marginal cost per user.
The Real Reason I Prefer It
Honestly? Alignment.
With subscriptions, my incentive is to make you dependent. With lifetime pricing, my incentive is to make something good enough that you tell your friends. The first model optimizes for lock-in. The second optimizes for quality.
As a developer who uses tools daily, I know which kind I prefer buying. So that's what I build.
Try It Yourself
If you're building a local-first dev tool or utility, seriously consider lifetime pricing. Start low, raise the price as you add features, and let the product speak for itself.
The indie dev community has been conditioned to think subscriptions are the only "real" business model. They're not. Sometimes the simplest model is the best one.
What's your take — lifetime or subscription for small dev tools? I'd love to hear from both builders and buyers in the comments.
Top comments (0)