Ask HN: Making a living selling software components, not SaaS?
50 comments
We have sold a JavaScript component as our sole source of revenue for about 4 years now, having started selling it 8 years ago.
We've played around in the SaaS market, in end-user apps that use the component, but we've never found anything that makes even remotely the amount we make from selling the component. A lot of people think SaaS is easier, I personally find it x10 harder.
We ended up gaining far more benefit from giving away the SaaS products as a means of marketing the component.
The thing with the component market is the revenue is far more an "amplification" of the economic environment. You're at the bottom of the food chain, you need new development projects to be started to be considered. Development projects are expensive. In late 2008, budgets were slashed, our component sales probably dropped 80%.
SaaS is much more stable revenue-wise. But on the flip-side, in 2007 when the going was good, sales just soared, it's not only downturns that you feel in the component market.
My advice would be
- focus on building a cash buffer as soon as possible, doing so was the only reason we're still here.
- aim for the Enterprise market, forget three figures a license sales. That level means the component is too simple, something open source will come along and kill you.
- The component market is better for margins and good salaries. The SaaS market generally scales better. Which you choose probably depends what you want to do with the business in the medium and long term.
We've played around in the SaaS market, in end-user apps that use the component, but we've never found anything that makes even remotely the amount we make from selling the component. A lot of people think SaaS is easier, I personally find it x10 harder.
We ended up gaining far more benefit from giving away the SaaS products as a means of marketing the component.
The thing with the component market is the revenue is far more an "amplification" of the economic environment. You're at the bottom of the food chain, you need new development projects to be started to be considered. Development projects are expensive. In late 2008, budgets were slashed, our component sales probably dropped 80%.
SaaS is much more stable revenue-wise. But on the flip-side, in 2007 when the going was good, sales just soared, it's not only downturns that you feel in the component market.
My advice would be
- focus on building a cash buffer as soon as possible, doing so was the only reason we're still here.
- aim for the Enterprise market, forget three figures a license sales. That level means the component is too simple, something open source will come along and kill you.
- The component market is better for margins and good salaries. The SaaS market generally scales better. Which you choose probably depends what you want to do with the business in the medium and long term.
Can I ask what the JavaScript component is/does?
Looking at his profile:
I'm a co-founder of JGraph. We make mxGraph and draw.io
http://www.jgraph.com/ http://www.draw.io/
I'm one of the co-founders at Binpress (http://www.binpress.com), which is marketplace for commercial open-source projects. Unlike Codecanyon, which someone else mentioned in this thread, our focus is on professional development and components that are more than simple scripts. Cocoacontrols (https://www.cocoacontrols.com/) is another good example, with some of their commercial components doing very well.
We have several developers making SV comparable salaries from publishing on our platform (in the 100k$ range annually). I believe this can be a huge market - if you look at companies selling licenses to code or SDK binaries, there's quite a few who built very profitable businesses around it.
Very well known examples of companies selling code licenses include MySQL and Magento (through their enterprise versions), though they provide complete solutions and not components. Gravity Forms (http://www.gravityforms.com/) a wordpress plug-in, is another good example - it generated millions in revenue if you trust their installation counter.
We have several developers making SV comparable salaries from publishing on our platform (in the 100k$ range annually). I believe this can be a huge market - if you look at companies selling licenses to code or SDK binaries, there's quite a few who built very profitable businesses around it.
Very well known examples of companies selling code licenses include MySQL and Magento (through their enterprise versions), though they provide complete solutions and not components. Gravity Forms (http://www.gravityforms.com/) a wordpress plug-in, is another good example - it generated millions in revenue if you trust their installation counter.
Logged in to say this.
As someone who has sold components on Binpress for the past year, and built a successful business (that i have recently sold) with the help of sales generated through their platform. I can vouch for these guys 100%. They are the best in the market for selling code/components. They have the best UI and by FAR the best support. Eran especially who really tries hard to make sure your components are presented well. This is great, especially for developers who do not necessarily know how best to present their work.
I've used a bunch of their competitors and i recommend them too, but if i was told to choose just one place to sell your code. Binpress would be it.
As someone who has sold components on Binpress for the past year, and built a successful business (that i have recently sold) with the help of sales generated through their platform. I can vouch for these guys 100%. They are the best in the market for selling code/components. They have the best UI and by FAR the best support. Eran especially who really tries hard to make sure your components are presented well. This is great, especially for developers who do not necessarily know how best to present their work.
I've used a bunch of their competitors and i recommend them too, but if i was told to choose just one place to sell your code. Binpress would be it.
I run product development for a toolkit company that exited to a public company in 2011.
Our .NET and Java toolkits sustain a 25 person division with healthy margins and decent growth.
The keys have been:
* make something valuable and charge enough for it so that you can offer great support. If you charge $500, you lose money if anyone calls you -- instead you should want people to call you -- so, charge enough money to make that worthwhile.
* have ways that make the engagement scale. Meaning, it's ok if an average deal is 5-10k, but if someone gets a lot of value, you should want that to scale up to 100k or more
* you can charge like a Saas for things that are not delivered like Saas, and some people prefer it. Meaning, we sell .NET assemblies (not a hosted service), but you can pay xx,000/year for it if you want unlimited deployment.
* You have two segments (broadly) -- companies that make software for themselves -- companies that sell software. They have different needs and get value in different ways -- think about segmentation to price appropriately.
You will be competing against free -- so you need to deliver value. Don't look for markets with no free alternatives. I compete against a ton of open-source very well. We're better and we have support.
Our .NET and Java toolkits sustain a 25 person division with healthy margins and decent growth.
The keys have been:
* make something valuable and charge enough for it so that you can offer great support. If you charge $500, you lose money if anyone calls you -- instead you should want people to call you -- so, charge enough money to make that worthwhile.
* have ways that make the engagement scale. Meaning, it's ok if an average deal is 5-10k, but if someone gets a lot of value, you should want that to scale up to 100k or more
* you can charge like a Saas for things that are not delivered like Saas, and some people prefer it. Meaning, we sell .NET assemblies (not a hosted service), but you can pay xx,000/year for it if you want unlimited deployment.
* You have two segments (broadly) -- companies that make software for themselves -- companies that sell software. They have different needs and get value in different ways -- think about segmentation to price appropriately.
You will be competing against free -- so you need to deliver value. Don't look for markets with no free alternatives. I compete against a ton of open-source very well. We're better and we have support.
We sell a downloadable, self hosted CMS (http://grabaperch.com). We launched it as a side product of our consultancy business just over four years ago and by the beginning of this year we stopped taking on client work as the income from Perch has essentially replaced that of a successful consultancy, so it is possible.
We don't have recurring revenue as such, a license is a one-off purchase and includes all support, first party addons etc. However our customers tend to be web designers buying a license for each project. If we do a good job they want to use Perch for more than one project!
Growth was slow and steady, I think the toughest part was when we were 50% client work and 50% Perch, as we had customer support making it hard to get on with client projects and we really just wanted to be working on Perch!
We don't have recurring revenue as such, a license is a one-off purchase and includes all support, first party addons etc. However our customers tend to be web designers buying a license for each project. If we do a good job they want to use Perch for more than one project!
Growth was slow and steady, I think the toughest part was when we were 50% client work and 50% Perch, as we had customer support making it hard to get on with client projects and we really just wanted to be working on Perch!
I also sell a downloadable self hosted app that targets developers (www.duetapp.com). I would love to hear about how you market Perch. My app has been growing pretty well since it was launched 5 months ago, but it's not yet profitable enough to replace my client work. I'm in the 50/50 place you described and it's....challenging...
5 months isn't a long time after launch for this sort of thing, it really took us most of 4 years to replace our consultancy (there are two of us, a husband and wife team).
The thing that works well for us is what people call "content marketing" these days. If you can write interesting articles and blog posts for your own blog and also for other sites, that appeal to your audience then it is likely that people will click through and have a look at your product. You don't need to write directly about your product - just to a developer audience.
The most surprising marketing success for us though has been sponsoring podcasts, specially where the hosts know and use our product and can talk personally about it. The return on investment on those has been really good.
Hope that helps in some way, I'm a member of a forum at http://discuss.bootstrapped.fm which is all people doing this kind of thing and talking about what they have tried so you might find that useful.
The thing that works well for us is what people call "content marketing" these days. If you can write interesting articles and blog posts for your own blog and also for other sites, that appeal to your audience then it is likely that people will click through and have a look at your product. You don't need to write directly about your product - just to a developer audience.
The most surprising marketing success for us though has been sponsoring podcasts, specially where the hosts know and use our product and can talk personally about it. The return on investment on those has been really good.
Hope that helps in some way, I'm a member of a forum at http://discuss.bootstrapped.fm which is all people doing this kind of thing and talking about what they have tried so you might find that useful.
I've just started content marketing, so hopefully that will start to have an effect soon. Bootstrapped.fm looks awesome. Thanks for the suggestion :)
Slightly off-topic but kudos on that landing page.
Very cleanly done.
Very cleanly done.
Thanks! It only took me a day so it still has some rough edges, but I hope to iron them out soon.
<!-- OFFTOPIC
Kudos for the landing page! However I would suggest you to play with the "buy" wording and replace the stock photos of the business people.
-->
Thanks for the feedback. Any suggestions for the "buy" wording? Can you shoot me an email? I would really appreciate it.
People making money selling software components:
http://www.componentsource.com/index.html
http://bfo.com/purchasingfaq.jsp
http://www.chilkatsoft.com/purchase2.asp
Discussion (though might be dying): http://discuss.joelonsoftware.com/?biz
Withholding Tax (if you are non-US, selling to US) "Components" are taxed at 5%; "desktop tools" (like compilers, editors, IDEs etc) are taxed at 0%. The tax is an admin hassle all round, so this is one plus for not selling components. (NB: this is an oversimplification, there's tax treaties, 30% tax if not under a treaty, byzantine IRS forms, tax rulings on the definition of "royalty" for components, etc).
ASIDE an idea: "Software Components as a Service". That is, it's in the cloud and paid for like a SaaS; but the service it provides is not an end-point (like an API to a business), but a transformation - the kind of thing you'd normally call a library for. e.g. text->pdf. Sounds inefficient, but you co-host with AWS/dropbox/heroku/GoogleApps etc so bandwidth is fast and free. (Alt: let the customer install a copy in the cloud, but you charge like a SaaS business model - an advantage for them is they can expense it monthly, not taxed like a capital purchase).
I've seen some evidence of this, in the form of cloud integration services e.g. http://www-03.ibm.com/software/products/us/en/castiron-cloud... (2010), but it's still mostly about integrating end-points, not the bits in between.
Discussion (though might be dying): http://discuss.joelonsoftware.com/?biz
Withholding Tax (if you are non-US, selling to US) "Components" are taxed at 5%; "desktop tools" (like compilers, editors, IDEs etc) are taxed at 0%. The tax is an admin hassle all round, so this is one plus for not selling components. (NB: this is an oversimplification, there's tax treaties, 30% tax if not under a treaty, byzantine IRS forms, tax rulings on the definition of "royalty" for components, etc).
ASIDE an idea: "Software Components as a Service". That is, it's in the cloud and paid for like a SaaS; but the service it provides is not an end-point (like an API to a business), but a transformation - the kind of thing you'd normally call a library for. e.g. text->pdf. Sounds inefficient, but you co-host with AWS/dropbox/heroku/GoogleApps etc so bandwidth is fast and free. (Alt: let the customer install a copy in the cloud, but you charge like a SaaS business model - an advantage for them is they can expense it monthly, not taxed like a capital purchase).
I've seen some evidence of this, in the form of cloud integration services e.g. http://www-03.ibm.com/software/products/us/en/castiron-cloud... (2010), but it's still mostly about integrating end-points, not the bits in between.
One angle is selling plugins to popular creative software. Not quite "the old way", since they are standardized components and sold somewhat more like apps are, but it's a way of selling software components. Photoshop plugins, VST plugins for audio applications, and plugins for the Unity game engine are three fairly active markets I know of.
Another strategy, though from what I can tell with declining popularity, is to write a GPL-licensed open-source library, and then sell proprietary licenses to companies who prefer those terms. Two random examples: http://www.juce.com/documentation/commercial-licensing http://www.cgal.org/license.html
Another strategy, though from what I can tell with declining popularity, is to write a GPL-licensed open-source library, and then sell proprietary licenses to companies who prefer those terms. Two random examples: http://www.juce.com/documentation/commercial-licensing http://www.cgal.org/license.html
I wouldn't recommend making Photoshop Plugins to anyone now, unless you have some absolutely killer must-have algorithm (in which case, you'd probably still make more money by licensing it to Adobe / Google etc). That ship has largely sailed, its heyday was around 2007 or so. But if you executed well, there was definitely money to be made at the peak. (Literally, the peak of the Crossing The Chasm bell-curve.)
(Disclosure, I've been writing/selling Photoshop plugins for over a decade - but I'm mostly working on other projects nowadays.)
(Disclosure, I've been writing/selling Photoshop plugins for over a decade - but I'm mostly working on other projects nowadays.)
MAD, the Mars Audio Decoder, is an MP3 decoder library that is available as GPL or commercial license. Macromedia licensed MAD for the Flash Player (where it's still used today).
http://www.underbit.com/products/mad/
http://www.underbit.com/products/mad/
I'm a developer, I remember one time I needed to have a particular piece of functionality in an app. I could have built it, but I found that someone was selling what I wanted for $3.00 on the internet, it was a no-brainer. I paid with something like gumroad, downloaded and plugged it in within a matter of minutes, vs the few hours I would have spent writing/debugging.
Odd price, $3. He could have doubled his price to $6, doubled his income, and lost no sales. Anyone who would consider buying a component online would surely not blink at the difference if it saves them a half-a-day of effort.
Maybe he doesn't want to have to provide support and thinks that $3 would be the cut off point for that? Hard to say really.
I would happily sell a bunch of scripts for a few $ on an "if it works, it works" basis. Once you start thinking about saving days of dev time it makes sense to bump it up to $100+ but then you will have to deal with emails or calls.
I would happily sell a bunch of scripts for a few $ on an "if it works, it works" basis. Once you start thinking about saving days of dev time it makes sense to bump it up to $100+ but then you will have to deal with emails or calls.
If that was on a site like codecanyon he might had no choice for the price. The staff there have their own ideas for the prices and doesn't let sellers set their own.
That's interesting. As you say, it's a no-brainer. I wonder if some kind of micropayment market in functions could be pulled off... The kind of thing Ted Nelson or Jaron Lanier talk about, only for small pieces of reusable code rather than small pieces of reusable text.
Stackoverflow is close, but the only currency is karma. But you can offer it as bounty to answer your question.
Throwing money into that dynamic is opening all kinds of worm cans.
Throwing money into that dynamic is opening all kinds of worm cans.
That's true. But money in that micropayment sense might not be entirely insane (assuming the whole micropayment model isn't entirely insane to begin with). The idea (as I understand it) is that you'd get a tiny wee payment every time someone quoted your work; so why not every time someone quoted your code? In the context of some Xanadu-like system, wouldn't that make sense?
http://www.experts-exchange.com/ ---
"In defense of Experts Exchange" https://news.ycombinator.com/item?id=6406373
But (I think) he means as a product, not a service (i.e. for bounties, only the asker pays, so it's a service; though it's true that everyone else benefits too).
I like this idea. The big problem, as always, is the boundary or interface of the module/component. (1). The buyer has to specify it, which is usually the difficult bit and writing it is usually easy. (2). For a market, you need to find modules that many people need, that people can search for and find, and that are difficult enough to implement that people would buy rather than build.
Maybe it's possible, for things that seem one-off or too specialized to a person, if you reduced friction enough, in a SO way. They've solved the search problem.
I guess an example would be a square-root function. I wouldn't know how to code it, I'd have to look it up, test and debug. It would take at least hours, I'd think. Of course, it's such a useful one, it's already done. That's the fate of all generally useful functions. The exceptions are new ones and niche ones.
I guess you could just add a little "debugged code" box for SO, and the person keeps coming back to it, to support it. This might be a useful addition; but I think you're right that money would spoil it. However... if you imagine a spectrum from one-liner to massive library, there's probably some level where the amount of work would make it reasonable to pay.
Conclusion: to see the value in the idea, leave money out (build something people want). How would you modify SO, or start a new one, to provide this value, or reusable functions/code snippets?
But (I think) he means as a product, not a service (i.e. for bounties, only the asker pays, so it's a service; though it's true that everyone else benefits too).
I like this idea. The big problem, as always, is the boundary or interface of the module/component. (1). The buyer has to specify it, which is usually the difficult bit and writing it is usually easy. (2). For a market, you need to find modules that many people need, that people can search for and find, and that are difficult enough to implement that people would buy rather than build.
Maybe it's possible, for things that seem one-off or too specialized to a person, if you reduced friction enough, in a SO way. They've solved the search problem.
I guess an example would be a square-root function. I wouldn't know how to code it, I'd have to look it up, test and debug. It would take at least hours, I'd think. Of course, it's such a useful one, it's already done. That's the fate of all generally useful functions. The exceptions are new ones and niche ones.
I guess you could just add a little "debugged code" box for SO, and the person keeps coming back to it, to support it. This might be a useful addition; but I think you're right that money would spoil it. However... if you imagine a spectrum from one-liner to massive library, there's probably some level where the amount of work would make it reasonable to pay.
Conclusion: to see the value in the idea, leave money out (build something people want). How would you modify SO, or start a new one, to provide this value, or reusable functions/code snippets?
Matt Cutts (Google SEO) fondly referred to this site as "Expert-SexChange" at Wordpress Conference in San Francisco in 2009! Google it. The video is funny!
This pretty much sums up how that would go down.
Q:
Should return 3 for this test case
x = add(1, 2) assert.equals(x, 3)
A:
function add(a, b){ return 3 }
Q:
Should return 3 for this test case
x = add(1, 2) assert.equals(x, 3)
A:
function add(a, b){ return 3 }
I get your point and fully agree with it.
But it makes me wonder when exactly we start to call something over-engineered. The same function will be implemented differently depending what you are going to feed into it i.e. if the numbers are sufficiently large then you need to worry about integer overflow etc. Probably a function definition should be considered incomplete without pre/post conditions.
But it makes me wonder when exactly we start to call something over-engineered. The same function will be implemented differently depending what you are going to feed into it i.e. if the numbers are sufficiently large then you need to worry about integer overflow etc. Probably a function definition should be considered incomplete without pre/post conditions.
One could imagine incorporating the component store into the app store, where developers could get a cut of app profits for providing components while the app store is responsible for all the bookkeeping. Think 5 cents/app sale micropayments, but that includes all apps on the store that want to use your component.
My website http://5000best.com/tools/ may be relevant. It lists mainly the most popular SaaS tools, but a few categories include widely used software components (non-free software only - no open source):
http://5000best.com/tools/Modules/
http://5000best.com/tools/Software_Dev/
http://5000best.com/tools/Specialized/
http://5000best.com/tools/Wordpress/
http://5000best.com/tools/Joomla/
http://5000best.com/tools/Drupal/
http://5000best.com/tools/Magento/
http://5000best.com/tools/E-commerce/
http://5000best.com/tools/Modules/
http://5000best.com/tools/Software_Dev/
http://5000best.com/tools/Specialized/
http://5000best.com/tools/Wordpress/
http://5000best.com/tools/Joomla/
http://5000best.com/tools/Drupal/
http://5000best.com/tools/Magento/
http://5000best.com/tools/E-commerce/
I do not make money from software components, but when I browse http://codecanyon.net, I find a few developers who seem to be doing relatively well. They basically sell more or less sophisticated scripts.
You could regard themes for WordPress as software components. Or theme frameworks such as Genesis (studiopress.com).
The really successful ones (such as Genesis) seem to bundle software components with something like subscriptions to future updates, a paid membership site, additional content like ebooks, live seminars, training, support etc. to get additional income streams and be able to upsell or cross-sell customers.
Game engines or mobile development frameworks (KendoUI, Sencha) that can be licensed also fall under selling software components. Again, the successful ones seem to offer additional resources or they sell their components in a one-year-license model, where customers have to renew the license every year. That would be more or less the same as SaaS in terms of recurring revenue and keeping customers in the loop.
You could regard themes for WordPress as software components. Or theme frameworks such as Genesis (studiopress.com).
The really successful ones (such as Genesis) seem to bundle software components with something like subscriptions to future updates, a paid membership site, additional content like ebooks, live seminars, training, support etc. to get additional income streams and be able to upsell or cross-sell customers.
Game engines or mobile development frameworks (KendoUI, Sencha) that can be licensed also fall under selling software components. Again, the successful ones seem to offer additional resources or they sell their components in a one-year-license model, where customers have to renew the license every year. That would be more or less the same as SaaS in terms of recurring revenue and keeping customers in the loop.
As a buyer, here are a couple of software I've bought-
- vBulletin forum (http://vbulletin.com) for the base of my site - CometChat (http://cometchat.com) for adding Facebook like chat to the site - Kayako (http://kayako.com) for support tickets and issues
The advantage I found with self-hosted software is that its one-time. I pay for it and I don't have to worry about a monthly billing. Similar software in SaaS model would cost me about $70-$100 per month. Eventually these costs start adding up. In one-time, I know that my investment is around $500-$800 or so. But that's all then. I can use the software for years without an issue.
- vBulletin forum (http://vbulletin.com) for the base of my site - CometChat (http://cometchat.com) for adding Facebook like chat to the site - Kayako (http://kayako.com) for support tickets and issues
The advantage I found with self-hosted software is that its one-time. I pay for it and I don't have to worry about a monthly billing. Similar software in SaaS model would cost me about $70-$100 per month. Eventually these costs start adding up. In one-time, I know that my investment is around $500-$800 or so. But that's all then. I can use the software for years without an issue.
Do you want to hear about failures?
I tried; with Flextras ( http://www.flextras.com ). I wanted to build a set of UI Components which would extend Adobe's Flex Framework. For various reasons it was a failure; and I shut down the "commercial" portion of the company in January of this year.
At the time I launched the business; Flash was still viable and Adobe was pumping a lot of money into growing Flex--which was basically "Flash for programmers". Adobe was trying to grow the user base for Flex to a million developers and I wanted to get in early and ride the wave, so to speak. I thought there would be a market for high quality components that extended the Flex Framework and Adobe stated they wanted to focus on the tooling and infrastructure while leaving components to third parties. I thought I was in a good spot.
When I was preparing to launch Flextras, I was planning for a 70% drop in income [compared to consulting rates] and hoped it would grow from there. I ended up with a 90% drop in income; so that hurt a bit.
We launched with a single component, and the first year only had one sale, and all my energy was spent on building out our Calendar component. [which took a year and I threw everything out and restarted from scratch 3 times because I decided the API/implementation wouldn't provide enough flexibility].
I think it was in our second year released the Calendar component and an AutoComplete component. A "Spark" Version of our AutoComplete came out later to integrate w/ Flex's new component model. Then we released some mobile components. We were growing from our "first year" revenue and averaged about $10K per year before shutting down. The business was growing, but very slowly. Then Adobe had some bad PR mishaps and sales stopped overnight.
I could go on and on about problems and mistakes I made along the way.
I focused on the wrong things--I think I spent three months creating transitions on our Calendar component. Business users don't care about such things [although I got a lot of 'hey cool' during demos]. During this development time; the new version of Flex came out [a point release] which broke all of that work.
The model of selling individual components is inherently flawed. It does not present recurring revenue. I hoped to combat this by releasing a lot of products; unfortunately that didn't happen for a variety of reasons. Components took longer to build than I anticipated [especially the Calendar].
We should have had a package of some sort [one price gets everything we built]. We should have had a subscription [one yearly price gets everything we built; plus everything we will build]. My attempt to switch our business model was a colossal failure on many levels.
I covered quite a bit of the business failures in a presentation called "How to Fail Fantastically" at the 360|Stack conference ( http://vimeopro.com/360conferences/360stack-2013/video/72773... ).
I tried; with Flextras ( http://www.flextras.com ). I wanted to build a set of UI Components which would extend Adobe's Flex Framework. For various reasons it was a failure; and I shut down the "commercial" portion of the company in January of this year.
At the time I launched the business; Flash was still viable and Adobe was pumping a lot of money into growing Flex--which was basically "Flash for programmers". Adobe was trying to grow the user base for Flex to a million developers and I wanted to get in early and ride the wave, so to speak. I thought there would be a market for high quality components that extended the Flex Framework and Adobe stated they wanted to focus on the tooling and infrastructure while leaving components to third parties. I thought I was in a good spot.
When I was preparing to launch Flextras, I was planning for a 70% drop in income [compared to consulting rates] and hoped it would grow from there. I ended up with a 90% drop in income; so that hurt a bit.
We launched with a single component, and the first year only had one sale, and all my energy was spent on building out our Calendar component. [which took a year and I threw everything out and restarted from scratch 3 times because I decided the API/implementation wouldn't provide enough flexibility].
I think it was in our second year released the Calendar component and an AutoComplete component. A "Spark" Version of our AutoComplete came out later to integrate w/ Flex's new component model. Then we released some mobile components. We were growing from our "first year" revenue and averaged about $10K per year before shutting down. The business was growing, but very slowly. Then Adobe had some bad PR mishaps and sales stopped overnight.
I could go on and on about problems and mistakes I made along the way.
I focused on the wrong things--I think I spent three months creating transitions on our Calendar component. Business users don't care about such things [although I got a lot of 'hey cool' during demos]. During this development time; the new version of Flex came out [a point release] which broke all of that work.
The model of selling individual components is inherently flawed. It does not present recurring revenue. I hoped to combat this by releasing a lot of products; unfortunately that didn't happen for a variety of reasons. Components took longer to build than I anticipated [especially the Calendar].
We should have had a package of some sort [one price gets everything we built]. We should have had a subscription [one yearly price gets everything we built; plus everything we will build]. My attempt to switch our business model was a colossal failure on many levels.
I covered quite a bit of the business failures in a presentation called "How to Fail Fantastically" at the 360|Stack conference ( http://vimeopro.com/360conferences/360stack-2013/video/72773... ).
I used to. The problem was I aimed at a component that was useful as a fixed standard (not always changing, upgrading etc). So, you can guess how this story ends...
I accomplished this. But it was by definition a stationary target, and competitors (in this case, open source) largely caught up. But worse, I lost interest, because I was no longer "the only/best in the world" at it.
Success: I not only made enough to live on, I made enough to invest in index funds giving a return that was itself enough to live on, and "retire" (for small values of retire, i.e. a student-level lifestyle - "ramen retirement"). Business began in 2000, able to retire in 2004 or so IIRC. Have lived off the business/investments since then.
- I tried to make it too much a business; if I'd stayed truer to my roots, it might have been OK. If you have an open-source version (or, at least, free), it starves off the competition, leaving them with no oxygen to get started, because no one needs it, they get no interest. And everyone's happy, which actually is very important for one's personal happiness too.
- I actually made a lot of money selling to the enterprise; but I hated it. Like, it really really got to me. In one particular sale, there was 5-6 months of negotiation, admin, international tax laws, etc. Ugh. And it all feels dishonest, pointless, and interacting with people who aren't competent because aren't interested and don't care. (the standard story of a developer dealing with business issues). So, you can do it this way, if you keep going up-market. The enterprise likes old stuff, that is trusted, field-tested, known etc.
- turns out I don't enjoy making a fixed standard. There's beauty in it as a business model; but for a technologist, the fun part is making it (and for me, supporting and debugging was also fun). But when it's all done, all working perfectly, it stops being fun. It's a funny old world.
- the underlying factor is that progress marches on. It's good for the world, and it's fun to participate. But not so good for a self-sustaining business with a competitive moat (Warren Buffett likes candy, chewing gum, soft-drink, bricks, furniture etc - stuff that doesn't change fast). You have to keep investing in it - developing new features, new products, new users (analogous to the capital investment required by the cotton mills of Berkshire Hathaway, making them a terrible investment). But this is all OK, if it's fun for you. And it can be.
I accomplished this. But it was by definition a stationary target, and competitors (in this case, open source) largely caught up. But worse, I lost interest, because I was no longer "the only/best in the world" at it.
Success: I not only made enough to live on, I made enough to invest in index funds giving a return that was itself enough to live on, and "retire" (for small values of retire, i.e. a student-level lifestyle - "ramen retirement"). Business began in 2000, able to retire in 2004 or so IIRC. Have lived off the business/investments since then.
lessons learned:
- I tried to make it too much a business; if I'd stayed truer to my roots, it might have been OK. If you have an open-source version (or, at least, free), it starves off the competition, leaving them with no oxygen to get started, because no one needs it, they get no interest. And everyone's happy, which actually is very important for one's personal happiness too.
- I actually made a lot of money selling to the enterprise; but I hated it. Like, it really really got to me. In one particular sale, there was 5-6 months of negotiation, admin, international tax laws, etc. Ugh. And it all feels dishonest, pointless, and interacting with people who aren't competent because aren't interested and don't care. (the standard story of a developer dealing with business issues). So, you can do it this way, if you keep going up-market. The enterprise likes old stuff, that is trusted, field-tested, known etc.
- turns out I don't enjoy making a fixed standard. There's beauty in it as a business model; but for a technologist, the fun part is making it (and for me, supporting and debugging was also fun). But when it's all done, all working perfectly, it stops being fun. It's a funny old world.
- the underlying factor is that progress marches on. It's good for the world, and it's fun to participate. But not so good for a self-sustaining business with a competitive moat (Warren Buffett likes candy, chewing gum, soft-drink, bricks, furniture etc - stuff that doesn't change fast). You have to keep investing in it - developing new features, new products, new users (analogous to the capital investment required by the cotton mills of Berkshire Hathaway, making them a terrible investment). But this is all OK, if it's fun for you. And it can be.
We made some decent money with our library however since we live in very expensive area I do some consulting as well.
If you are single and live in not so expensive place making software components could be a viable business. Just chose something that will not become obsolete in 2 or 3 years.
We are in the PDF space that is quite crowded but still much better than Flash (for example) that is becoming less and less relevant.
If I had to start today I would probably look for some security related stuff.
If you are single and live in not so expensive place making software components could be a viable business. Just chose something that will not become obsolete in 2 or 3 years.
We are in the PDF space that is quite crowded but still much better than Flash (for example) that is becoming less and less relevant.
If I had to start today I would probably look for some security related stuff.
I am running Component Owl (http://www.componentowl.com/) for about three years.
The original idea was to create top-notch WinForms and WPF controls (.NET visual components). However, developing single great WinForms or WPF control is pretty challenging task. One need excellent knowledge about the framework and tools. It is much more than programming and deployment. It is also about knowing dark internals of the platform you use.
For example, the greatest challenge was doing seamless Visual Studio integration. Most users didn't know how to add a component to their software. They assumed it will "just appear" in Visual Studio Toolbox window and they just click on it and start using it.
Furthermore, most of my customers haven't just bought the component. They required some adjustments and features here and there. They also needed assistance with implementing the component even though we provided thorough documentation with code samples.
Because of the above reasons, I am currently orienting more on niche components and leaving all the buttons, combos, calendars and other typical controls to big players.
The original idea was to create top-notch WinForms and WPF controls (.NET visual components). However, developing single great WinForms or WPF control is pretty challenging task. One need excellent knowledge about the framework and tools. It is much more than programming and deployment. It is also about knowing dark internals of the platform you use.
For example, the greatest challenge was doing seamless Visual Studio integration. Most users didn't know how to add a component to their software. They assumed it will "just appear" in Visual Studio Toolbox window and they just click on it and start using it.
Furthermore, most of my customers haven't just bought the component. They required some adjustments and features here and there. They also needed assistance with implementing the component even though we provided thorough documentation with code samples.
Because of the above reasons, I am currently orienting more on niche components and leaving all the buttons, combos, calendars and other typical controls to big players.
I have a counter-example. I built an OSX application for remotely tailing logs on servers (http://www.remotetailapp.com/). Originally I did it to scratch and itch when I was administering a bunch of servers over SSH. I added Heroku log support when I started working on a Heroku project. I had dreams that it might grow into a self-sustaining side project, but it hasn't really taken off. The key lesson that I learnt is that the technology just solves part of the problem. Just because it is downloadable software rather than SaaS doesn't mean that you don't need to put effort into marketing and sales.
I've been selling a php self-hosted ad server, mySimpleAds, at http://wwww.clippersoft.net for years, which makes some side money. I recently launched a SaaS version at http://mysimpleads.com .
For the little bit the SaaS has been up, people still seem to like the self-hosted version. So, I guess it really depends upon the product and your target customer. There's some things that some people just prefer to host on their own :-).
For the little bit the SaaS has been up, people still seem to like the self-hosted version. So, I guess it really depends upon the product and your target customer. There's some things that some people just prefer to host on their own :-).
Do you think maybe it's a self-selected audience? Like these are the people that know and love you as a self-hosted product, and now you need to reach a different, more SaaSy crowd?
I certainly agree, while there will be some bleed over I think the segment is slightly different. I just haven't figured out how to reach them yet.
How does it compete with OpenX? Why did you chose this product?
I've had many people coming from OpenX that found OpenX too cumbersome, slow, and/or confusing. So, it's a different customer base - they don't need the millions of bells and whistles, just want some quick and simple to use.
I chose it because people in a forum I was a member of were asking for such a thing and thus I was presented an opportunity.
I chose it because people in a forum I was a member of were asking for such a thing and thus I was presented an opportunity.
We sell a self hosted PHP app: http://teampasswordmanager.com. Sales went up this June when we released V2 (bootstrap based UI, more features). We're now adding more features and trying to keep up with requests from our users.
Wordpress templates are just "components" that can't function alone if you think about it.
And don't underestimate the money that can be made with those. There are some dedicated marketplaces for those (can't remember right now their names, sorry)
Themeforest is probably the biggest marketplace for wp themes (run by Envato, the same guys behind codecanyon etc.). WooThemes, although not a marketplace, is another player doing very well selling wp themes.
[deleted]
However, I wonder if there's anyone here who makes decent money selling software components or code "the old way".
Please share your stories.
(I'm also interested in hearing the buyer's side, so please mention useful code/software that you had bought).