How to Sell a .NET Library

You built a .NET library that solves a real problem. Maybe you are an independent developer, or maybe you run a small software company. Either way, other developers and teams need what you built. But how do you actually turn that into revenue?

This guide covers the practical steps to sell a .NET library commercially: choosing a licensing model, setting a price, packaging for distribution, and collecting payments. No theory, just what works.

1. Why sell instead of giving it away

The .NET ecosystem runs on NuGet packages. Most of them are free. This is great for adoption, but terrible for sustainability. Maintainers burn out. Security patches get delayed. Companies build critical infrastructure on top of libraries maintained by a single person in their spare time.

Selling your library is not greedy. It is a signal that you are committed to long-term maintenance. When a company pays for your library, they are buying more than code. They are buying:

• Guaranteed maintenance: someone is accountable for keeping it working
• Priority support: a direct line to the person who wrote it
• Security updates: fast patches when vulnerabilities are found
• Compatibility: tested against new .NET versions on release day

Plenty of successful .NET libraries are sold commercially: Telerik UI, DevExpress, Syncfusion, ImageSharp (dual licensed), and many others. The market exists. The question is how to enter it.

2. Choose a licensing model

Your license determines what customers can do with your code. Here are three popular models for commercial .NET libraries. There are more, and we will cover additional licensing strategies in a future blog post.

Proprietary license

The customer gets compiled binaries (DLLs) but not the source code. They can use the library in their projects but cannot redistribute, modify, or resell it. This is the simplest model and what most commercial component vendors use.

Best for: UI components, specialized algorithms, enterprise tooling.

Dual license

The library is available under a permissive open-source license (e.g. Apache 2.0) for open-source projects, and under a commercial license for proprietary use. This gives you community adoption and commercial revenue.

Best for: Libraries that benefit from community contributions and wide adoption (e.g. serializers, ORMs, image processing).

Source-available with commercial license

The source code is public (e.g. on GitHub) for transparency and auditing, but commercial use requires purchasing a license. Licenses like BSL (Business Source License) or PolyForm are increasingly common for this.

Best for: Libraries where customers need to audit the source for security or compliance reasons.

3. Set your price

Pricing a software library is uncomfortable because there is no marginal cost per copy. But your time has a cost, and so does the value your library provides to customers. Here are practical guidelines:

Subscription vs one-time

Subscriptions (monthly or yearly) work best for actively maintained libraries. The customer pays as long as they receive updates. When they stop paying, they keep the last version they downloaded but stop receiving new ones. This aligns incentives: you maintain, they pay.

One-time purchases work for stable, finished tools that do not require frequent updates. The risk is that you have no recurring revenue to fund ongoing work.

How to pick a number

Focus on three things:

• The value you deliver. Think about the complexity your library handles for the customer. If your library saves a team from building and maintaining something in-house, price it relative to that cost. A library that replaces weeks of custom development and ongoing maintenance is worth real money.
• What competitors charge. Research what existing libraries and services in your space cost. Look at Telerik, DevExpress, Syncfusion, or whoever competes in your category. You do not need to match their prices, but you should understand the range customers expect to pay.
• The complexity you absorb. Your customers are paying you to deal with the hard parts so they do not have to. The more edge cases, platform quirks, and integration work your library handles, the more it is worth. Make this clear on your product page.

4. Package for distribution

.NET developers expect to consume libraries via NuGet. Your commercial library should work the same way. No manual DLL downloads, no special installers. Just dotnet add package.

Create a proper .nupkg

Set up your .csproj with the right metadata:

<PropertyGroup>
  <PackageId>YourCompany.YourLibrary</PackageId>
  <Version>1.0.0</Version>
  <Authors>Your Name</Authors>
  <Description>A clear, one-line description.</Description>
  <PackageLicenseExpression>LicenseRef-Commercial</PackageLicenseExpression>
  <PackageReadmeFile>README.md</PackageReadmeFile>
  <PackageIcon>icon.png</PackageIcon>
</PropertyGroup>

Build and pack with dotnet pack --configuration Release. This produces a .nupkg file ready for distribution.

Target multiple frameworks

Your customers may be on .NET 6, 8, or 9. Use multi-targeting to maximize compatibility:

<TargetFrameworks>net6.0;net8.0;net9.0</TargetFrameworks>

5. Pick a distribution channel

One approach is to publish on nuget.org and use license keys with runtime checks to gate functionality. This works, but it means your binaries are publicly downloadable and you are relying on code-level enforcement. The alternative is a private NuGet feed that only paying customers can access. Here are the main options:

Self-host a NuGet server

Run BaGet, NuGet.Server, or similar on your own infrastructure. You control everything but you also maintain everything: uptime, backups, access control, scaling. This works if you already have ops infrastructure, but it is a distraction when you should be writing code.

Use a managed feed service

Services like Azure Artifacts, MyGet, or GitHub Packages host NuGet feeds for you. They handle the infrastructure but they are not built for selling. You still need to handle payments, access control, and credential provisioning yourself. Every new customer means manual work.

Use pkgstore.io

pkgstore is purpose-built for selling .NET libraries. You push your .nupkg, set a price, and customers buy access through Stripe. When they pay, they automatically get NuGet credentials for your private feed. When they cancel, access is revoked. No manual work.

Beyond distribution, pkgstore gives you visibility. Your product gets a public listing page that is indexed by search engines, helping potential customers discover your library. You also get analytics data on your subscribers and package downloads, so you can make informed decisions about what to build next.

The workflow looks like this:

1. Push your package: dotnet nuget push MyLib.nupkg --source https://www.pkgstore.io/api/nuget/yourname/yourlib --api-key YOUR_KEY
2. Customer subscribes on your product page and pays through Stripe
3. Customer receives NuGet credentials and adds your feed: dotnet nuget add source https://www.pkgstore.io/api/nuget/yourname/yourlib/index.json
4. Customer installs your package: dotnet add package YourCompany.YourLibrary

6. Set up payments

Stripe is the standard for software payments. It handles credit cards, invoicing, tax collection, and payouts to your bank account. Most developers already have a Stripe account or can set one up in minutes.

The key decision is whether to manage Stripe yourself or use a platform that integrates it for you. If you self-host, you need to build:

• A checkout page
• Webhook handlers for subscription events (created, cancelled, failed payment)
• Logic to provision and revoke NuGet credentials based on subscription status
• A customer portal for managing subscriptions

This is significant engineering work. Platforms like pkgstore handle this end-to-end: you connect your Stripe account, and the platform manages the entire checkout-to-credential flow automatically.

7. Find your first customers

Building a great library is necessary but not sufficient. You need to put it in front of people who have the problem it solves.

Start where developers hang out

• Reddit (r/dotnet, r/csharp): answer questions related to your library's domain. Be helpful first, mention your product when relevant.
• LinkedIn: post about the problems your library solves. Technical content performs well.
• .NET newsletters: reach out to curators of ASP.NET Weekly, The Morning Brew, or similar newsletters.

Offer a free tier or trial

Let developers try before they buy. A free tier with limited features, a time-limited trial, or a free community edition for open-source use reduces friction and builds trust.

Write documentation that sells

Your documentation is your most important marketing asset. A developer who reads your docs and thinks "this will save me a week of work" is already sold. Invest in clear getting-started guides, code samples, and API references.

8. Common mistakes to avoid

• Pricing too low. A library priced at $5/month attracts tire-kickers, not serious customers. Enterprise teams have budgets. Respect the value you provide.
• Building distribution infrastructure instead of features. Every hour spent building a custom license server or payment system is an hour not spent improving your library. Use existing tools.
• No trial or demo. Developers will not pay for something they cannot evaluate. A "contact us for a demo" button on a $49/month library is overkill. Just let people try it.
• Ignoring DX (developer experience). If installing your library requires downloading a zip, copying DLLs, and editing config files, you have already lost. It should be one NuGet command.
• Waiting for perfection. Ship v1 with a small feature set and a fair price. You can always add features and raise prices later. You cannot get back the months spent polishing in private.
• Not enough focus on marketing. A great library with no marketing is invisible. Plan to spend at least as much time promoting your library as you do building it, especially in the early days. Writing code is the comfortable part. Getting it in front of the right people is what actually drives sales.