Every productivity tool seems to cost $10–15 per month now. Password managers, bookmark apps, budget trackers, note-taking tools — the category doesn't matter. The pricing model does. If your tool costs $120 a year and a user keeps it for three years, they've paid $360. For software they might use daily, that's defensible. But for tools where the feature set is stable and the server cost is near zero, it's hard to justify.
We build our products as one-time purchases. Here's the thinking behind that, and the tradeoffs we accept.
When one-time pricing makes sense
One-time pricing is the right model when all of these are true:
The core feature set is stable. If you're shipping major new features every month, a subscription gives users a reason to stay. If the product does one thing well and does it reliably, there's no ongoing "subscription value" to point to.
Your running costs don't scale with users. If you're paying for API calls, storage, or compute per user, subscriptions fund those costs. If your app runs entirely in the browser and your only server cost is a Cloudflare Worker that gets called once a month per user, a subscription would be collecting rent on infrastructure that barely exists.
Your users are privacy-conscious or subscription-fatigued. A significant segment of users actively avoids subscription software. They're often willing to pay more upfront to avoid a monthly obligation — and they're loyal once they've paid.
You're building a tool, not a service. A project management tool with real-time collaboration is a service — there's ongoing infrastructure and support behind it. A bookmark manager or a budgeting app is closer to software you ship. The distinction matters for pricing.
What you give up
One-time pricing has real costs. Be honest about them.
No MRR. Monthly recurring revenue is the lifeblood of SaaS. Without it, your revenue is lumpy — high when you're getting attention, near zero when you're not. You'll need a bigger cash cushion than a subscription business at the same revenue level.
Upgrades are awkward. If you want to charge for a v2, existing customers feel entitled to a discount (or free access entirely). Subscription users are already paying; one-time users have "paid forever" mentally.
Support economics are harder. A user who paid $9 three years ago is still a user, and they'll email you with questions. You've collected nothing from them since year one.
These are real. They're also manageable, especially for a solo developer or small team with no investor pressure to show MRR growth.
Structuring the free tier
A free tier exists to get users into the product and demonstrate value before asking for money. Getting the line between free and paid wrong is expensive — too much free and people never convert; too little and people don't bother installing.
The free tier should be genuinely useful. A free tier that's so limited it's useless just trains users to look elsewhere. If someone can't get real value from the free version, they won't pay to unlock more.
The paid upgrade should feel obviously worth it — to the right user. The free-to-paid line should sit where power users naturally hit it. Casual users will stay free forever, and that's fine. You're not trying to convert everyone — you're trying to make the upgrade a no-brainer for the people who are getting the most value.
Feature gating beats usage caps for productivity tools. Limiting users to 25 items creates artificial frustration. Gating a specific capability (auto-backup, sync, advanced import) creates a clear value proposition — you know exactly what you're paying for.
For a budgeting app: unlimited manual use is free; encrypted cloud sync and auto-backup are paid. For a bookmark manager: unlimited bookmarks are free; auto-backup and vault sync are paid. The free tier is fully functional. The paid tier solves problems you develop as a power user.
Purchasing power parity
If you're building for a global audience, flat pricing disadvantages users in lower-income markets. A $49 app is a trivial purchase in the US; it's a week's salary for many buyers in India or Southeast Asia.
Gumroad has built-in PPP support — it automatically adjusts the checkout price based on the buyer's location. Turn it on. You'll get more sales and more users in markets you'd otherwise miss entirely, without doing any additional work.
The honest case
We charge once because our apps don't have ongoing costs that justify a subscription, because our users have already demonstrated they're allergic to subscriptions by seeking out privacy-first tools, and because we'd rather have a smaller number of users who paid fairly than a large number of users who feel trapped.
It's not the right model for every product. But it's the right model for ours.
Both of our products — Squirrel and Allot — use one-time pricing with a free tier. If you're working out the right model for your product, we're happy to think through it with you.