Subscriptions make sense for a lot of software. If a tool is deeply embedded in your workflow, if it grows with your usage, if there's ongoing value being delivered — a recurring charge is fair. That's the model working as intended.
But somewhere along the way, the subscription became the default — not because it's always the right fit, but because it's the most convenient structure for the builder. Predictable revenue, lower churn anxiety, easier valuation math. The business case is obvious. The user case is often much weaker.
I noticed this when I audited my own software spend. Several tools I was paying for monthly had usage patterns that looked more like occasional purchases than ongoing dependencies. File sharing was the clearest example. I was on a paid WeTransfer plan. I used it maybe a few times a month. The charge came regardless.
That's not a subscription. That's a retainer for something I occasionally need.
The problem with low-frequency tools on subscription pricing
When usage is irregular, the subscription model quietly shifts value away from the user. You pay for months where you barely touch the product. The provider profits from inertia — the gap between what you use and what you forget to cancel.
This isn't a criticism of any specific company. It's a structural observation. Subscriptions work best when usage is consistent. For tools people reach for occasionally, the math rarely works in the user's favour.
The counterargument is usually: "but the free tier exists for that." And it does. But free tiers are increasingly restricted to the point where they function more as conversion funnels than genuine alternatives. The features you actually need tend to sit just above the free limit.
A different model: pay for what you actually use
When I built NetLoad — a file transfer tool on nesdzo — I made a deliberate choice to avoid subscriptions entirely.
The free tier is genuinely functional. Files up to 5 GB, 7-day links, no account required. That covers the majority of transfers most people need to make.
When someone needs more — larger files up to 50 GB, flexible link expiry, password protection, download notifications — they pay £1.99. Once. For that transfer. No recurring charge, no plan to manage, no cancellation to remember.
The revenue model is transactional rather than subscription-based. That's a harder sell to anyone thinking about LTV and MRR. But for a tool that solves a specific, occasional problem, I'd argue it's the more honest structure.
Why builders default to subscriptions anyway
It's worth being fair about why this happens. Subscriptions reduce revenue variance. They make planning easier. Investors understand them. If you're building a business around a tool, the subscription model offers stability that transactional pricing doesn't.
But not every tool is — or should be — a business in that sense. Some tools are utilities. They solve a defined problem, they do it well, and they don't need to grow into platforms. For those tools, the subscription model is often imported from a different context where it made more sense.
The question worth asking early: is this tool something people will use continuously, or something they'll reach for when a specific need arises? The answer should shape the pricing model, not the other way around.
The broader pattern
I suspect a lot of developer frustration with software costs right now comes from this mismatch — tools priced as if they're continuous dependencies when the actual usage pattern is occasional and task-specific.
The irony is that a well-priced transactional tool probably earns more trust, and more word-of-mouth, than one that quietly charges people through quiet months. Trust is harder to measure than MRR, but it compounds in similar ways.
There's space for more tools that charge honestly for what they deliver, when they deliver it. Not every problem needs a subscription to be a sustainable product.
Top comments (0)