Why I Priced My QR Code Tool $15 Lifetime, Not $5 a Month

I built a QR code tool, priced it at $15 one-time for life, and watched indie Twitter tell me for six months that I was leaving money on the table. Forty paying customers and roughly $600 in one-time revenue later, here is the unromantic answer to why I did it — and when I would tell you not to.

This is not a love letter to lifetime pricing. Half of why it worked was demographic, half was unit economics, and a non-trivial part was that I found subscription pricing for this specific product difficult to defend to customers.

The received wisdom I ignored

Anyone who has read two SaaS blog posts knows the received wisdom:

• Recurring revenue is the only revenue that matters.
• Lifetime deals cap your LTV and train customers to expect them.
• Subscription pricing funds growth; one-time pricing funds nothing.
• Real SaaS founders don't discuss this — they ladder price.

All of this is broadly true for most SaaS products. None of it is true for mine, and the honest analysis of when it isn't true is the part that goes unwritten.

The three conditions that made lifetime correct

Condition 1: Usage is bursty, not continuous. People do not use QR code generators on an ongoing basis. They use them intensely for an event, a campaign, a menu redesign, a packaging print run — and then they stop, sometimes forever. The natural rhythm of the product is bursty, not continuous. A subscription model charges users for the eleven months they don't use the product to fund the one month they do. Most of them know this. They tolerate it. They remember which vendors did it to them.

Condition 2: Unit economics are near-zero. My infrastructure cost per active customer is fractions of a cent per month on Cloudflare Workers plus a small Supabase tier. I can serve a generous cap on any single customer's scans without worrying about cost. If one user triples their traffic, my marginal cost is still rounding error. The math that justifies subscription pricing — that servers need to keep spinning and that costs scale linearly with usage — applies at ten-thousand-enterprise-customer scale. It does not apply at mine. I'd be charging a monthly fee that has no honest relationship to the cost I incur serving the customer.

Condition 3: The category has a vocal anti-subscription demand. The QR code generator category is dominated by subscription models that a meaningful portion of customers openly reject in Reddit threads and support interactions. I'm not going to characterise any specific vendor here — that's a legal minefield and also not the point. The point is that the market I was entering had an obvious demand for a vendor who wasn't doing that. "Different" is cheap positioning. "Different and correct on the unit economics" is rare positioning.

When the usage is bursty, the infrastructure is cheap, and the category has an overt rejection pattern for the dominant model, lifetime pricing stops being a meme and starts being strategy. Those are three specific conditions. Don't generalise from mine.

The math I actually ran

Before I priced it I did a plain comparison. I'm using my own hypothetical $5/month to model the subscription scenario — I'm not stating any real competitor's price here.

Scenario A — hypothetical $5/month subscription, 24-month expected life.

• Gross per customer if they stay: $120
• Realistic churn for a bursty-usage tool: high, particularly if the customer bought it for a single event
• Customer-acquisition cost at my DR via ads: higher than the LTV on any reasonable churn assumption
• Result: underwater before month 18 on realistic retention

Scenario B — $15 one-time, no recurring.

• Gross per customer: $15
• Churn: irrelevant
• Customer-acquisition cost at my DR via ads: still higher than CAC payback on one-time revenue
• Result: I have to win organically or die

Both scenarios require winning organically to be viable at DR 0. Scenario B has the virtue of being honest with the customer about what the product is worth to them. It also gives me a cleaner pricing page — no tier comparison table — and a conversion story ("you own it, no subscription") that removes objection.

The unflattering truth is that subscription pricing in my category wasn't carrying the business model; it was carrying the vendor's refusal to find a better acquisition channel. If I'm going to lose money on paid acquisition either way, I may as well lose it on a price point my customers thank me for rather than tolerate.

What actually happened

Six months in:

• Conversion rate on the pricing page: roughly 3-4x what I'd estimated for a subscription price point in the category. The single biggest driver was the absence of a comparison table.
• Support load: lower. Customers who bought a thing they own don't write in with "how do I cancel" messages.
• Refunds: two. Both on the 30-day guarantee. Both valid reasons. Both issued with no friction.
• Revenue shape: ~$600 of one-time receipts that would've been roughly $200-300 of subscription revenue over the same period, with churn starting to bite by month three. I'm objectively ahead.

What the lifetime model does not produce is the satisfying hockey-stick MRR chart that demo days are built on. My chart is cumulative receipts, which grows more slowly and doesn't compound. If my goal were venture scale, this would be the wrong model. My goal is a profitable single-founder business that still exists in five years, which is a different goal and deserves a different model.

When I'd tell you not to do this

I'd tell you not to do lifetime pricing if:

• Your infrastructure cost scales with active usage and can exceed the one-time revenue on heavy customers.
• Your product requires continuous vendor labour (support-heavy, content-heavy, feature-update-heavy) which lifetime pricing fails to fund.
• Your category has no vocal anti-subscription demand, and you'd be leaving positioning value on the table for no market reason.
• You're venture-funded and need the MRR line on your chart more than you need the cleanest unit economics.

I'd tell you to consider it if:

• Usage is bursty, not continuous.
• Marginal cost per customer is negligible.
• Your category is dominated by subscription models that customers publicly reject.
• You're bootstrapping and care more about cash in the bank than a growth chart.

That's four specific conditions. Tick three and run the math. Tick all four and the default assumption that recurring revenue is always correct is costing you customers.

The part I got wrong

The one thing I misjudged: I underpriced the lifetime anchor. Fifteen dollars was chosen because it felt fair and defensible. In hindsight, $19 or $24 would have been equally sellable — my conversion isn't that price-sensitive in this range, and the extra revenue compounds on customer count. I probably won't raise existing customers' price, but the next cohort likely sees $19.

This isn't a critique of lifetime pricing. It's a reminder that the model doesn't relieve you of doing the pricing work. Default psychological anchors for one-time software skew low because of App Store conditioning and bundled SaaS trials. Don't take that anchor at face value. Price the value, not the feel.

The honest summary

Lifetime pricing worked for OwnQR because three conditions all held at once: bursty usage, near-zero marginal cost, and a category demanding an alternative. I wouldn't guess which one mattered most. I know that removing any one of them would have made a subscription model more correct.

The received wisdom in SaaS pricing was written for categories that are not mine. It's correct for most of its audience and wrong for the specific case where customers resent the dominant model, use the product in bursts, and a small founder can serve them at a cost that has no resemblance to the cost structure the subscription model is designed around.

If those conditions describe your product, your default should not be $5 a month.

---

Max Liao runs OwnQR, a $15 lifetime dynamic QR code tool. He writes about indie SaaS architecture, AI content pipelines, and edge-deployed cost economics. Find more posts on the OwnQR blog.