How to license...
How to license your software to other companies (and price it without losing money)
You built a platform to run your own business. It works so well that a partner saw it and asked the question you weren't ready for: "Could we use that too?"
This is how a lot of companies end up licensing software without ever planning to. A logistics firm builds a dispatch and document-processing tool for its own depots. A recruiting agency automates candidate screening. A clinic network builds its own intake and scheduling system. Then someone in the same industry wants in, and overnight you are a software vendor. Sort of.
If you are the operator who now has to answer "what does it cost?" and "how do we make sure we don't lose money on the first deal?", this guide is for you. It covers the three questions people in your position actually google: how to license your software to another company, how much to charge for a software license, and how to stop one customer from running up your cloud bill.
Janu Lingeswaran
Updated
Guide
Best practices
Why licensing your software is different from selling SaaS
Most articles on software pricing are written for SaaS startups with a pricing page, a sales team and a finance function. You have none of that, and you don't need it yet.
What you have instead is a working product, real usage data from your own operation, and one or two warm partners who already trust you. That is a better starting position than most startups, as long as you avoid the one mistake that sinks first-time licensors: quoting a flat price for a product whose costs scale with usage.
The risk you should be worried about
Every operator we have walked through this describes a version of the same fear.
Inside your own company, nobody overuses the platform. You have a fixed number of teams, a known volume of work, and an intuitive sense of what "normal" looks like. A licensing partner has none of that. If you sell them a flat monthly fee and they turn out to be five times your size, they will use the platform five times as hard, and every unit of that usage lands on your infrastructure bill. They are not doing anything wrong. They are using what they bought.
That instinct is correct. Licensing a usage-driven product at a flat price is handing someone a blank cheque drawn on your cloud account.
The good news: this is one of the most solved problems in software. You need three things, in this order.
Step 1: Map your cost per customer before you price anything
Before any pricing conversation, get a one-page map of every vendor underneath your platform and how each one bills. Not a rough idea. The actual numbers.
For a typical modern stack it looks like this:
Layer | What it does | How it typically bills | Scales with |
|---|---|---|---|
Hosting | Runs the application | Flat monthly plus usage | Traffic |
Database | Stores accounts and records | Flat monthly plus usage | Users, records |
AI processing | Extracts, classifies, generates | Per token, page or request | Documents × complexity |
Background compute | Batch jobs, exports, renders | Per hour while running | Job volume |
File storage | Keeps uploads and outputs | Per GB per month | Files retained |
Transactional and campaign mail | Free tier, then per volume | List size × frequency | |
SMS | Notifications and verification | Per message | Recipients × campaigns |
Maps, payments, other APIs | Whatever your product calls | Per request | Feature usage |
Most of those lines are cheap or free at the volume you run today. That is exactly the trap. The free tiers that made your own usage invisible evaporate with your very first licensing partner. If you have never paid for AI processing because your team handles a few hundred documents a month, a partner pushing ten thousand through costs real money from day one.
So the question for each line is not "what do we pay now?" It is "which of these explodes first when a partner shows up, and at what rate?" In AI-heavy products it is usually model calls. In communication products it is messages. In data products it is storage or API requests. Find your equivalent. That single line becomes the backbone of your software licensing pricing model.
If your development partner cannot hand you this table within a day, push harder. They should also tell you which costs are fixed regardless of usage and which only accrue while something is actually running.
Step 2: Build a usage-based pricing calculator (four inputs, one output)
This is where people overthink it. You do not need a pricing consultant. You need a spreadsheet with four inputs and one output.
Inputs:
Number of active users or teams at the partner
Volume of the primary cost driver per user per month (documents, messages, jobs, requests)
Average cost per unit of that driver, from your vendor map
Number of partners
Output: estimated monthly cost to you.
Plug in the partner you are actually talking to. Plug in the partner you are afraid of. Plug in five partners at once. Within an hour you will have a feel for the shape of your costs that no abstract pricing theory can give you.
Two things become obvious fast:
One cost driver dominates everything else. Price around that one.
The gap between a reasonable partner and a heavy one is not 2x. It is 20x or 50x. Flat pricing cannot survive that range.
Step 3: How much to charge for a software license
Three honest options, from simplest to most precise.
Option A: Cost-plus (estimate and add a margin)
Model the partner's stated usage in your calculator, add 30–50%, quote a flat monthly fee. Simple to sell, simple to invoice. Fatal if they grow past your estimate and you have no clause to reprice. Only do this with a hard usage cap in the contract and the software.
Option B: Platform fee plus included allowance plus overage
A monthly fee per organisation that includes a defined bundle (say, 5,000 processed documents and 2,000 messages). Beyond that, a published per-unit overage rate.
This is the model most of our clients land on. The partner gets a predictable number. You get upside if they grow. And the runaway-partner scenario becomes self-limiting, because heavy usage pays for itself.
Option C: Pure usage-based
Pass through your costs with a multiplier. Most accurate, hardest to sell, because nobody likes a bill they cannot predict.
Our recommendation for a first deal is almost always B. Keep the allowance generous enough that a normal partner never hits it, and the overage rate high enough that an abnormal one is profitable rather than painful.
Per seat vs usage-based: which fits a licensed platform?
Per-seat pricing is easy to explain and easy to invoice, but it only works when cost and value actually track the number of users. For platforms where one user can trigger a lot of infrastructure (AI generation, batch processing, bulk messaging, media rendering), per seat is dangerous: a single seat can cost you more than the whole contract. Use seats as a secondary dimension at most, and put your primary price on the metric that actually drives your cloud bill. We go deeper in per seat vs usage-based pricing.
Step 4: Enforce SaaS usage limits in the software, not the contract
This is the step most first-time licensors skip, and it separates a sustainable side business from a slow leak.
A contract clause that says "maximum 5,000 documents per month" is worth very little. You would have to notice the breach, document it, and have an awkward conversation with a paying partner.
The same rule built into the platform is worth everything. If your system is multi-tenant (each partner is an isolated organisation with its own admins, branding, data and domain), it can also carry per-organisation limits: number of seats, monthly processing volume, messages, storage. When a partner crosses a threshold, the platform tells them and offers the upgrade. No awkward call, no surprise invoice on your side.
Multi-tenant SaaS pricing and multi-tenant architecture are the same decision. Usage limits are cheap to build when designed in early and painful to retrofit later. If you are already talking to a prospective partner, tell your engineering team now. The implementation is covered in multi-tenant SaaS usage limits.
What to tell your CEO
If you need to explain this upstairs in three sentences:
Our costs are usage-based, so our pricing has to be too, at least partially.
We charge a platform fee that covers a normal partner's usage with room to spare, plus a per-unit rate above that.
The limits are enforced by the software itself, so we cannot be surprised by the bill.
That is the whole strategy. It does not need to be more sophisticated until you have your fifth partner.
You are not the first
We build multi-tenant products for a living, and a surprising share of them started exactly this way: a company builds something for itself, a peer asks to use it, and a product business grows out of an operations budget.
None of them planned to become software companies. All of them got there by doing the steps above in order, and by refusing to get clever before they had to.
If you are standing at that fork, we are happy to walk through your own numbers. Bring your vendor list. We will bring the calculator.
FeatherFlow is a product development agency that designs, builds and ships AI-first and SaaS products for companies that want to move fast without growing their team.
Frequently Asked Questions
Can I license software I built for my own company?
Do I need to become a SaaS company to license my platform?
Should I white-label the platform for partners?
How do I calculate the cost per customer for my platform?
