Here's a challenge for you! How can one monetize a package?
I'm developing a package. A Ruby on Rails gem (like an npm package for ruby) to be more exact.
My main constraint is that is must live in the app because it handles data and pushing that outside the app might push customers away. This is why I can't build it as a conventional SaaS and charge a monthly fee.
Now I'm wondering how can I monetize it best. I was thinking about a few strategies:
- Sell it for a fixed price per app used, leaving the customer to purchase a new license every time they use the product in a new app and giving them lifetime updates
- Charging a monthly subscription that gives the customer access to further updates.
- Charging a yearly subscription that gives the customer access to further updates.
- Have different types of licenses like $300 for one app and $5000 for an unlimited number of apps per developer/company
- Sell it for a fixed price per version and every time I bring new "big-ish" features increment the version number and charge an upgrade fee.
This is a project in which I invested quite some time and will be doing more in the future.
I'm all open for suggestions and feedback is much appreciated.
Update: To give you a bit more perspective, I think of my package something you'd want to install & use in almost all of your rails apps. Like you'd almost always install devise because your app features authentication.
Update 2:
Avo is the product I was talking about. It's a beautiful next-generation framework that empowers you, the developer, to create fantastic admin panels for your Ruby on Rails apps with the flexibility to fit your needs as you grow.
https://avohq.io
https://twitter.com/avo_hq
https://github.com/avo-hq/avo
https://discord.gg/pkTF6y8
Thank you all!
Check out Heya from Honeybadger. It's almost exactly what you're talking about - a Ruby gem that has to live in the app. They use the Prosperity Public License where it's free for non-commercial or small-case use, but paid for commercial use.
Personally, I like yearly subscriptions for updates. It's what I'm going to be using for Nodewood. Monthly is comfortable and familiar to SaaS owners, but so much of the value comes from the initial download of the code - if you could download it for 1/12 the price and then stop paying, there will be a non-trivial number of people who see that as acceptable.
That said, I'm also a big fan of "money-back" instead of "free trial", so a big up-front cost plus a long "money-back" period equates to the same thing as a free trial but with more likely usage, which leads to a more honest evaluation, and - if your product is any good - more conversions/less money given back.
Pro-tips on the money-back guarantee!
Got it! For sure!
Very eloquently put
"money-back" instead of "free trial". I agree with that. Yearly subscription for updates could be a good fit for my product.I'll let you know when I start releasing it.
Hey @adrianthedev,
Cool topic! I've been doing a bunch of thinking about this for my product premiumjs.com—which allows folks to monetize stuff like this but for the JS ecosystem.
To that end, I wrote this post recently: https://medium.com/@jones.spencera/monetizing-js-packages-as-easy-as-npm-publish-ea4df601c3d5. The first part is really the interesting part for you.
I think you have a couple of options:
1. Fully Open Source
a. Try monetizing around donations, ads in documentation
b. Charge for support, services, or maintenance (basically, start a consulting business around it)
c. Dual Licensing—basically, it's free for non-commercial use-cases and commercial use cases need to purchase a license. There are lots of projects that use this method and it's worth considering.
2. Partially Open Source
Have part of your project that's fully open-source and part that is a pro/premium tier. Charge folks whatever your customers think is reasonable for the pro tier.
3. Closed-Source Offering
Any use requires purchasing of licenses (on some payment plan you figure out).
All of your options are under the "Closed Source" category.
In terms of what and how to pay, I think it'd be best to talk to your customers and figure that out.
Hope that helps! Happy to talk more if you like. Just ping me back in the comments :)
Yup! Very well put and organized! Thank you!
Talk to Users.
What would they want to pay?
I had lots of thoughts of crazy pricing structures that would help creators create (a tool for newsletters). I thought of a tiered fixed fee structure.
But when I talked to users, they were happy to give a percentage.
So it's now turned into "Free to install" & "We'll charge a percent of transactions"
It was users who told me they wanted this. Happy to oblige!
I agree to what you're saying. Talk to the customers. Sounds reasonable! I guess I'll have to do that once I start to roll out the beta.
Not sure about the "percent of transactions" because it doesn't do transactions, but I see what you mean. That's amazing that you got to do that!
To give you a bit more perspective, I think of my package something you'd want to install in almost all of your rails apps. Something like devise for authentication.
the point was that users told me that. It's not your pricing. You'll have different pricing.
You should talk to users, before you have a product.
how do you know it's needed?
Honestly I wouldn't build an app, new, with a gem that I had to pay yearly for. I'd hate for the app to suddenly stop working because i switched credit cards.
I'd build an app, get users, and install it later when I knew I had money to spend.
so you have existing apps that need this and that would pay money for it.
Try $99 for lifetime use. see if anyone buys it now. before you build it.
Yeah. I know what you mean about your app stopped working because you 're not paying anymore. Not the kind of business I want to build.
It would probably be somewhere closer to "paid once, get the current version, stop paying, you're not getting future updates but keep what you already have"
Also good point about try pricing before release. 👍
Give away the code. Monetize the docs.
Hmm. The docs are a big seller for this product. The docs show how easy it is to get started and how much it helps you.
Thank you for the reply.
I know it's a bit too late for this post, but I want to disclose the package I built.
It's called Avo.
Avo is a beautiful next-generation framework that empowers you, the developer, to create fantastic admin panels for your Ruby on Rails apps with the flexibility to fit your needs as you grow.
Come and try it out today!
https://avohq.io
https://twitter.com/avo_hq
https://github.com/avo-hq/avo
https://discord.gg/pkTF6y8
I'd probably look at a couple of options.
Sell a single-use license that gets all minor version updates, updates for a year, or some combination of those.
Sell an unlimited license or at least some kind of multi-application license that gets the same updates but can be used in more applications at a discount.
A subscription version of each of those that will continually get updates. You could do something like JetBrains where the second year is at a discount to encourage users to go for it. This one really depends on how often you think major changes will occur.
I thought about JetBrains's "Cheaper as time passes" strategy and does kinda fit my product well. I guess this would be a "one subscription for unlimited apps" kind of deal.