
Ask HN: How to Price a Software Library? - rivo
More than once, I&#x27;ve built a software library - usually something required in specialized industries - which I&#x27;ve then gone on to sell to enterprise customers. Each time, however, I feel that I&#x27;m leaving money on the table by pricing it wrong.<p>It does not seem wise to charge a fixed one time fee of a few hundred bucks when the customer then uses the library for years in their own products. Is it still common to charge per installed CPU&#x2F;core? How do you then deal with cloud systems where that number always changes and may even be difficult to determine? What about charging &quot;per end user&quot;? In general, can libraries also be charged on an ongoing basis like a SaaS (x EUR per month or year), i.e. do customers accept that?<p>I&#x27;ve offered maintenance and support packages but when the software works beyond the initial warranty, customers usually don&#x27;t order them. I could turn the library into an API and charge for that but that&#x27;s not always what the customer wants.<p>Any ideas on how to maximize my revenues here?
======
JohnFen
I've developed and sold several libraries over the years. Here's how I
approached pricing. I'm not saying this is the best way, but it has worked for
me.

I don't really do ongoing payment (rental) schemes, out of pure personal
preference. (If a customer asks for one, I can do that, though -- it's just
not a default option). I don't like it when other software does this, so I'm
not going to do it myself. That's not an economic or business-based decision
and not a recommendation. I'm just mentioning it to explain why that's absent
here.

I take a look at what my development costs were to develop the library, and
use that to estimate what it would cost another shop to replicate the same
functionality. I try to subtract out the portion of the development costs that
are reflect the API design and other things that are unique to library
development (including documentation).

Then, once I have an estimate for what it would cost my potential customers to
develop the functionality, I cut that in half, and that becomes my asking
price.

I also sell libraries in two forms: with source code and without. For those
who want the source code (which is most of my customers), I charge double what
the asking price I computed above is.

~~~
rivo
Trying to figure out how much it would cost the customer to develop the same
functionality is probably the best strategy (and suggested by most posters in
this thread).

I would add that the customer may not come up with a detailed
estimate/calculation so it's more a question of how expensive they perceive
their development costs to be. (If their developer casually says, "I can do
this in two days", that's bad even if it's wrong.)

One probably has to factor in the (possible) inefficiency of the customer,
i.e. inexperienced devs and the usual overhead of working at a large company.

At first, I thought that by cutting the costs in half, you would end up with a
fairly low price. But giving them the option to receive the source code at
double the price is a nice touch, especially since you say most of your
customers want that anyway.

------
dsr_
My company buys a math library. It's normally licensed per-core, annually,
with a license key that expires and makes it stop working.

We eventually worked out a special deal where we would pay for 2 years at a
time in advance, and get a version without the stupid expiring key.

The library vendor trusts us to account for the number of CPUs we are running
it on and self-report. We don't abuse that trust.

The alternatives are:

1\. Writing our own math library. We estimated it would take a man-month to
get it usable, but we might spend years in corner cases.

2\. Paying someone to improve Octave. Probably similar to case 1, but we would
feel good about our contribution.

3\. Very expensive alternatives.

------
actionowl
> It does not seem wise to charge a fixed one time fee of a few hundred bucks

Maybe you could make the one-time price higher? I've seen some critical
libraries cost several thousand dollars, and it was worth it in time saved.

~~~
geoah
I would have to agree with this. In the days when .NET was top dog and GitHub
was not still a thing people spent insane amounts of money for libs that would
save them time. Per client, per developer, per "seat", per core, anything you
can think of someone charged for it. Telerik is the one that comes to mind,
but they mostly did dev-oriented stuff.

The pay-more-once scheme always seemed the most easy choice for companies I
worked for, as they wanted to be able to sell products that they couldn't
easily keep charging for after the sale.

------
cweagans
Your customers are going to ask if it's cheaper to buy your library or build
out the functionality on their own. If I were pricing this, I'd try to be at
the highest number possible where the answer to that question is a no-brainer.

Personally, I'd do a fixed one time fee for each major version of the library.

Another option is to scale your pricing based on your customers' revenue like
Unity does (minus the subscription part). Smaller companies can get a better
deal on your software, but when they cross a threshold of annual revenue, then
they pay more.

~~~
JohnFen
> Another option is to scale your pricing based on your customers' revenue

I don't scale the pricing in an overt way, but I have been known to reduce the
fee for small companies or individual developers if they ask.

Also, if I think a particular customer would give me additional benefits (such
as increased exposure or clout), I have sometimes cut the rate in exchange for
permission to advertise their use of my library.

------
DerekQ
Look into charging per developer, with a site license option. Libraries /
components, especially for enterprise development is big business. In the .Net
space you have $100m+ companies like DevExpress and Telerik, and smaller, more
specific and niche component providers (example: componentspace.com) selling
successfully at a few grand a copy.

A few hundred bucks is way too low for any library of substance that saves the
local developers a few weeks work.

------
happythought
Value-based pricing is an alternative to cost-based pricing. Try to quantify
the value that your library brings to the customer in terms of revenues
generated or costs saved. You and the customer should get to share this value,
so choose a price that divides that value between you equitably.

------
gremlinsinc
I think for a library an annual 'support license' on top of the purchase fee,
would keep your pockets padded - since it's niche say you charge $400 for the
library, then $80/year -- if you have enough clients that's some residual on-
going income just be sure to push out a few security updates per year which is
what the subscription aspect is for -no subscription --what's your motivation
to provide support/upgrades?

~~~
user5994461
This is the worst advice in this thread by far. $80 would barely cover one
hour of work.

If you charge any support, this should be similar or more than the price of
the library. Clients who ask for support are the most annoying ones who are
planning to use it and the bigger companies with deep pockets.

Better make the support crystal clear on what is covered because clients might
try to have you do the integration in their software, which is a whole
development project, not a support task.

~~~
gremlinsinc
Support mostly (to me) means maybe a forum/knowledgebase + on-going
updates/patches/fixes. In person/hands-on help would of course be an hourly
feature at $100+ per hour. But many use cases won't need that kind of support,
for most the docs and updates/upgrades are worth the subscription.

------
laydn
You should charge "per month/year", if you have any intention of supporting
your product and your customers long term.

Sell the library for X EUR, and then charge Y Eur/year for ongoing support and
maintenance, where Y is a fraction of X. If the user does not want the support
and maintenance, so be it, they can use the software indefinitely. In my
experience, most serious users have no problem paying for long term support.

Good luck.

