Ask HN: Making a living selling software components, not SaaS? There have been countless discussions about SaaS with tons of examples and success stories. It seems like a good way to structure new software businesses. 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). |
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 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.
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.
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 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!
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.
Very cleanly done.
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.
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
(Disclosure, I've been writing/selling Photoshop plugins for over a decade - but I'm mostly working on other projects nowadays.)
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.
Throwing money into that dynamic is opening all kinds of worm cans.
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/
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.
- 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.
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 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.
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.
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.
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 :-).
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.
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?
Q:
Should return 3 for this test case
x = add(1, 2) assert.equals(x, 3)
A:
function add(a, b){ return 3 }
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.