How I Decide Subscription or One-Time Pricing

I decide subscription vs one-time pricing by one question: what's the shape of the value? Not what's fashionable — everything defaults to SaaS now, which is exactly why it's the wrong starting point. If the product delivers ongoing value (continuous use, an evolving service, recurring cost on my side), a subscription fits. If it delivers a discrete, one-time outcome (a result the user gets once and keeps), a one-time price fits. The mistake almost everyone makes is picking the model by trend and then bending the product to justify it. Match the price to the value, and both the customer and the model stay honest.

The core question

Every pricing decision comes down to this: does the customer keep getting value, and do you keep incurring cost?

• If yes — the value is recurring, the product evolves, your costs are ongoing — then recurring payment is honest. That's a subscription.
• If no — the customer gets a discrete result once and keeps it, with little ongoing cost or change — then recurring payment is a trap. That's one-time.

Everything else is detail. Get this alignment right and the pricing feels fair to everyone; get it wrong and no amount of clever packaging fixes the mismatch.

When subscription fits

Subscription is right when the customer keeps getting something for the ongoing payment: a tool they use continuously, a service that stays current, data that keeps updating, a problem that recurs so the solution has to recur too. There's genuine ongoing value on their side and genuine ongoing cost on yours. The recurring charge maps to recurring value — so it feels like a fair exchange, not a leash.

When one-time fits

One-time is right when the product delivers a discrete outcome: a result, an artifact, a tool that solves a specific problem the user then owns. A template. A one-shot transformation. Something they get once and keep. Here, a subscription would ask them to keep paying for value they already received — which feels like exactly the trap people resent about modern software.

"

A subscription for one-time value is a churn machine and a trust tax. A one-time price for ongoing value is unsustainable. Both fail the same way — the payment and the value point in different directions.

The mistake in each direction

Both errors come from ignoring the shape of the value:

• Subscription on one-time value → the customer paid, got the result, and now the monthly charge feels like extortion. They churn, and they tell people why.
• One-time on ongoing value → you're carrying ongoing cost against a payment that already ended, and the model quietly bleeds until it can't sustain the service.

The fashionable error is the first one — forcing recurring pricing onto discrete value because "SaaS" — and it's why so many subscriptions feel wrong.

How I actually decide

I ask, honestly: after the customer gets the core value, is there a reason they keep needing me? If yes, subscription — and I make sure the ongoing value is real, not manufactured to justify the charge. If no, one-time — even though it gives up the predictable recurring revenue, because a mismatched model costs more in churn and trust than it earns. Sometimes the answer is a hybrid: one-time for the core outcome, subscription only for the genuinely ongoing part. But it always starts from the value, never from the trend.

What usually goes wrong

• Pricing by fashion. Defaulting to subscription because that's what everyone does, regardless of the value shape.
• Manufacturing fake recurring value. Bolting on "updates" to justify a subscription the product doesn't earn.
• One-time on a service. Undercharging for something with real ongoing cost, then watching it become unsustainable.
• Never revisiting. Value shapes change as a product grows; the pricing model should be allowed to change with it.

Read the shape of the value first — ongoing or discrete — and let that choose the model, not the trend. Honest pricing is just the payment and the value pointing the same direction. It's a product decision like any other: made from what's true about the thing you built, not from what's currently in style.

Part of Building AI Products. See also my product operating system and how I use AI without letting AI make product decisions. The newsletter sends one practical build lesson every two weeks.