What a buy-once desktop product costs to run

What a buy-once desktop product costs to run

Selling software once and letting the customer keep it removes recurring revenue. It does not remove recurring cost. The honest way to price a buy-once product is to list what keeps billing after the sale, then design so that the list gets shorter.

The parts that never stop billing

1. Payment processing. Every sale costs a percentage plus a fixed fee.
2. Tax handling. Selling to consumers in the EU (and many other places) means VAT, invoicing rules and thresholds. Most small teams hand this to a merchant of record rather than doing it themselves.
3. Downloads. Installers and model weights are large files, and they get downloaded far more often than they get updated.
4. Transactional email. Licence keys, receipts, sign-in links and refund notices are not marketing mail, but they still have to arrive.
5. Support time. Not a bill you receive, but the most variable cost of all.

Items 1 and 2 scale with revenue and are effectively unavoidable — they are the price of being able to take money at all. Paddle and Lemon Squeezy both publish their fee structures, and reading them is worth an hour before you pick one, because it decides how many small sales you can afford to make.

The two bills you can actually make small

Bandwidth. The good news is that serving static files is close to free at this scale. Object storage with no egress charge, fronted by a CDN with a generous free tier, removes almost the whole line item: Cloudflare R2's pricing page documents the no-egress model, and Workers' free tier with its published request limits covers a surprising amount of traffic. The thing to watch is not the per-gigabyte rate but your update strategy: if every release re-downloads gigabytes from every existing customer, bandwidth becomes a real number.

Email. Sending a receipt and a licence key is a handful of messages per sale. Providers with per-day free tiers cover it. What does not get covered is marketing: if you start sending newsletters through the same channel, deliverability (and often the price) changes.

Design decisions that shrink the list

• Static-first hosting. A content site that prerenders to static files needs no application server to be up at 3 a.m. If your storefront only talks to a database when someone checks out, most of your traffic never touches a database.
• Offline licence validation. A desktop tool that verifies a signed licence locally does not need to call home on every launch. That removes a service you would otherwise have to keep alive for years, and it makes the product work without internet.
• Separate weights from the installer. Shipping models inside the installer makes every release enormous; downloading them once from a mirror keeps releases small and lets you offer a second download source.
• Cache aggressively, invalidate precisely. A stale product page for ten minutes costs nothing. A stale price at checkout costs trust, so the price should be read again when the order is created rather than trusted from the cached page.

A rule of thumb

Add up the per-sale costs you cannot remove (payment + tax + email) and treat that as the floor under your price. Then look at the costs that depend on behaviour — bandwidth and support — and assume they grow with success, not with revenue. A product priced so that its tenth sale is as profitable as its first one is a product that can still be sold in three years.

That is the whole argument for one-time pricing done properly: you are not promising that running the thing is free. You are promising that the customer will not be billed again for something they already own.