How developers actually make money from free Windows software

You built a Windows utility. It solves one problem properly, it has a real install base, and it earns nothing.

The reason is structural rather than personal. iOS and Android have a payments rail built into the operating system — a store, a card on file, a one-tap purchase. Windows has the Microsoft Store, which most desktop utilities are not distributed through and which most users do not open. So a Windows developer wanting revenue has to build the entire commercial apparatus themselves, and the options that remain are worse than the mobile equivalents in ways that are easy to underestimate.

Here they are, with the costs stated.

Paid tier

Make a version people pay for.

The problem is what it does to the free version. A paid tier only converts if the free tier is worse, which means deliberately withholding something from the people who made your tool popular. Every feature decision from then on carries a second question: does this go above or below the line?

Works when: there is a natural professional-versus-casual split — bulk operations, automation, commercial use. Costs: you are now maintaining two products and a licensing system, and every support request starts with working out which version they have.

Nag screens and trials

A timer, a delay, a reminder.

Nags convert, which is why they persist. They also train people to close your application faster, and on Windows they are strongly associated with the class of software people are trying to avoid. A nag screen in 2026 reads as a signal about the developer rather than about the product.

Works when: the tool is used deliberately and at length, so the interruption is annoying enough to pay to remove. Costs: goodwill, which for a free tool is most of the asset.

Donations

Ask.

Conversion is a fraction of a percent for almost everyone. Donation revenue correlates with how personally visible you are — a maintainer with a following does far better than an anonymous binary — and it is not a plan so much as a thank-you mechanism.

Works when: you have a public identity people want to support. Costs: nothing, which is why everyone should have a link. Just do not model on it.

Bundled offers

Ship someone else's software with yours.

This pays and it is the single fastest way to destroy a desktop tool's reputation. It is also where the entire "download the installer from anywhere but the official site" problem came from. We would not.

Bandwidth sharing

The user opts in, and a capped share of the bandwidth their machine is not using gets relayed for public web data collection. Nothing renders, nothing is withheld, no tier appears.

It pays up to $0.50 per user per month, at per-country rates. A user counts for a day once their device has been sharing for 60 minutes in that day, each qualifying day is worth one day's share of the monthly rate, and the month is the sum of its days. Devices on hosting, datacenter or VPN IPs are not counted.

For a widely-installed free utility this is often the only option that does not require making the product worse. It is also the one with the most to be suspicious about, so here is the part that is genuinely harder on Windows than anywhere else.

The antivirus problem

Bandwidth-sharing agents are classified as proxyware by several antivirus vendors. That classification is not unreasonable — the behaviour signature of a consented relay and an unconsented one is similar from the outside — but it is your problem to manage, and any vendor telling you otherwise has not shipped on Windows.

What actually makes it manageable:

• Sign your executable, with a certificate that has accumulated reputation. A brand-new certificate is better than none and worse than one that is two years old with downloads behind it.
• Ship the library alongside your signed binary rather than downloading it at runtime. A binary that fetches and executes code post-install is a much worse heuristic profile.
• Verify what you ship. Any vendor should publish checksums for every artifact. If they do not, you cannot prove what is in your installer.
• File false-positive reports. Every major vendor has a submission process and they do act on them. Budget for doing this once per vendor.

None of this makes the issue disappear. It makes it a known cost with known mitigations, which is the most that can be said, and it belongs in your decision rather than in a surprise a week after launch.

What the integration actually looks like

The Windows SDK is cr_sdk.dll plus a cr_sdk.h header, exposing a plain C ABI. That means C and C++ call it directly, and anything with C FFI binds to it — C# through P/Invoke, Go through cgo, Python through ctypes, Node through an FFI package. There is no runtime to install next to it.

The things worth asking any vendor, in order:

1. Can you see the consent screen before integrating?
2. Which limits can you change? The correct number is zero.
3. What happens under sustained load — throttle, or opt out entirely?
4. What is blocked, and who buys the traffic?
5. Can you get a device online today without a sales call?

Then ship it to a slice of your install base and watch your crash reports and your uninstall rate for a week. On desktop, uninstall rate is the number that matters most, because a desktop user who is unhappy does not churn quietly — they uninstall and post about it.

The eight questions in full goes deeper on evaluation, what apps make per download puts the revenue next to the mobile models, and the Windows page has our specifics.