On charging for software you can run locally

Last year I shipped a small tool — a local-first security scanner that runs entirely on the user’s machine. No cloud dependency, no telemetry, no account required. The kind of software I wish more people built.

The hard part wasn’t building it. The hard part was figuring out how to charge for it. Here are the three models I tried, and what each one actually rewarded:

Model 1: One-time purchase

$49 for a license key. Simple, honest, easy to understand. Customers liked it. I liked it. Revenue was lumpy — good months after a launch or a mention, nothing in between. The problem: no incentive for me to keep improving the tool after the sale. And no revenue to fund those improvements with.

What it rewarded: The initial sale. Not the ongoing relationship.

Model 2: Annual subscription

$29/year. Steady revenue. Customers had mixed feelings — “why am I paying annually for something that runs on my machine?” Fair question. The update cadence wasn’t fast enough to justify it. Felt extractive even though the math was reasonable.

What it rewarded: Retention theater. I was incentivized to ship visible updates, not useful ones.

Model 3: Pay-what-you-want with a suggested price

$0+ with a suggested $39. Average payment: $31. Total revenue: roughly the same as the subscription model, with fewer support tickets and higher satisfaction scores. The people who paid nothing mostly couldn’t afford it. The people who paid more than the suggested price did so because they found it genuinely useful.

What it rewarded: Actual value delivered. The model aligned my incentives with the user’s experience.

What I learned

There is no clean answer. But for a small, local-first tool built by one person, the pay-what-you-want model was the least wrong. It treated customers like adults, reduced friction, and produced enough revenue to keep the project alive without turning me into a retention optimizer.

The next tool I ship will use the same model. Unless I find a better one first.