There is a habit of treating price as the last thing that happens to software. The product gets built, then someone decides what to charge.
It works the other way around more often than not. Pricing is set early, and everything downstream bends toward it. The revenue model is not a label attached to a finished product. It is an instruction to the people building it — and once you can read that instruction, a lot of otherwise puzzling product behavior stops being puzzling.
Two instructions
A one-time purchase says: finish it.
Revenue arrives when the product ships. Everything after that — support, bug fixes, compatibility with next year’s operating system — is cost. The rational response is to make something complete, ship it, and move on. This produces software with a distinct shape: focused, finished, and eventually abandoned. Anyone who has watched a favorite application stop receiving updates has met this model’s failure mode.
A subscription says: make them come back.
Revenue arrives when someone chooses not to cancel, which means the product has to remain worth returning to. This funds the unglamorous work that a one-time purchase cannot justify: maintenance, security patches, servers, the slow improvements that only pay off across years. It also produces a different failure mode, which we will get to.
Same feature list, two different products. The instruction is not visible in the interface, but it is visible in the behavior over time.
Reading the behavior
Once the frame is in place, some familiar patterns resolve.
Why some tools keep adding things you never asked for. Under a subscription, a product that feels finished is a product that feels cancelable. There is constant pressure to demonstrate ongoing value, and new features are the most legible way to do that. This is how a focused tool becomes a suite over four years, usually without any single decision that seemed wrong at the time.
Why others quietly stop improving. Under a one-time purchase, every post-sale improvement is spending against revenue already collected. Teams do it out of craft and reputation, not economics, and craft is not always enough to survive a budget review.
Why "lifetime deal" software so often disappoints. A lifetime license is a bet that the buyer will stop caring before the seller stops paying. Sometimes that bet is fine. Often the maintenance obligation outlives the revenue, and the product decays in place — technically still yours, practically abandoned.
Why free tiers get worse in a specific direction. They rarely lose features outright. They lose limits — storage, seats, history, exports. The free tier is not the product; it is the on-ramp, and it is tuned to the moment you need it most.
Neither instruction is dishonest
It is tempting to write subscriptions as the villain here. That would be lazy, and wrong.
Some categories genuinely require ongoing revenue. Anything that runs servers, syncs across devices, or defends against an adversary that keeps evolving cannot be funded by a payment made in 2019. Security software sold as a one-time purchase is arguably the more dishonest arrangement, because it promises protection against threats that had not been invented yet.
Equally, some categories genuinely do not. A text editor, a file renamer, a calculator — tools that are conceptually finished and have no meaningful ongoing cost. Subscription pricing there is not funding maintenance. It is converting a solved problem into a recurring obligation.
The question is not which model is better. It is whether the model matches the actual shape of the product’s ongoing cost.
The dependency question
There is a second-order effect worth naming, because it does not show up on any pricing page.
A one-time purchase creates an asset. It may age badly, but it remains yours in a straightforward way. A subscription creates a dependency — one that is renewed monthly, on terms that can change, by a company whose plans you do not control.
This is not an argument against subscriptions. It is an argument for noticing which of your tools have become load-bearing. When something moves from convenient to the thing my work runs on, the pricing model stops being a billing detail and becomes a risk position. The question to ask at that point is not what it costs, but what happens if it goes away, gets repriced, or gets acquired.
That question has a practical answer, and it usually turns on how easily you could leave — which is the subject of The real cost of switching.
What to do with this
None of this resolves into a rule about which software to buy. It resolves into a better question to ask before buying.
Ask what this pricing rewards. Then ask whether that matches how you intend to use the product. If you want a tool that is finished and stable, a model that rewards constant change is working against you — even if the company is excellent. If you want something maintained and defended for years, a model that collected its revenue once is working against you just as much.
Notice when the pricing and the product disagree. A subscription on something with no ongoing cost is a signal. So is a one-time purchase on something that obviously requires continuous maintenance. Neither is proof of bad faith, but both are worth a second look.
Watch the direction of travel. A tool that started as a purchase and moved to a subscription has usually changed what it is optimizing for, whatever the announcement said. That change tends to show up in the roadmap before it shows up in the marketing.
This connects to something we have looked at from another angle: which tools actually last in a real workflow, and why the impressive ones so often are not the survivors. That is The tools that survive your workflow.
The short version
Price is not a number attached to software. It is a description of what the company is being paid to care about.
Read it that way and the pricing page becomes one of the more informative pages on the site — considerably more informative, usually, than the feature list it sits next to.