I’ve been thinking about selling SDK’s recently. I have a pet theory that just like everyone 
has a novel inside them, every developer has a SDK inside them. A SDK that would make constructing software as pleasurable as running through a summer meadow, who’s many hundreds of unit tests would shine green like a leprechaun on St Patrick’s day, and every design trade-off was explained by a 30 second video from @unclebobmartin.
A beautiful dream, even more so if you think that you can sell your SDK for cash-money, to run a profitable business, in the 21st century.
But without me noticing it (until now), the software tools business is rapidly turning itself into a commodity business, like electricity and gas, where you pay for what you use.
Reasons SDKs are a tough sell
First let’s look at why selling SDKs is difficult
- Software developers have no money – By in large most small software teams have little budget for tools
- Software devs don’t like spending money – Devs brought up in the Linux/Ruby
/Python communities are so used to installing gems etc for free, that the thought of actually paying for software is often met with outright hostility. - Not Invented Here – If you didn’t code it yourself, it’s probably rubbish. What Linus coded it? Well he probably made some stupid decisions. All devs look down their nose at others code.
- Laziness – evaluating a SDK is quite difficult, more so if there’s tons of dry documentation to read. We’d rather code it up ourselves, right?
- Upgrades – Upgrading your software is a nightmare, there’s a reason everyone delivers client-side code over the net.
- Platform specific – you write your code in Python, well only some dude who knows Python is going to be able to do anything with it, you’ve segmented your market (in a bad way) before you’ve even started.
So where does that leave you, basically with 4 strategies:
- Pile-em-high, sell-em-cheap – If you have a SDK or tool that is mass market – eg Resharper. I’d suggest your maximum price point is circa £200. Much more and no matter your claims small teams just won’t be able to afford you, or they’ll look down their noses at you.
- Enterprise – Large enterprises are more used to paying for tools and software. However, they often have large legacy code bases, so may not require new tooling (or their devs are enslaved on Windows XP and an ancient version of Eclipse). But if you can find a niche you may be able to sell here possibly up to £10,000
- Exclusivity – If you have tooling that help crunch numbers for quants, oil surveying etc then you can probably justify a very high ticket price.
- Service – Give away your tooling and charge for support. Eg Red-Hat linux etc. This can work, but I’d suggest it’ll take a ballsy investor to green-light this strategy.
So selling SDKs and tooling is a tough business, it can be done, but it’s hard. So is there an alternative?
Its services all the way down!
I first heard people bandying around the term Software as a Service (SaaS) maybe five years ago. At the time it was all talk about silos, XML and SOAP. Anyone who’s looked at SOAP was so bamboozled by WSDLs and handshaking and 2000 lines of XML that they abandoned all hope.
But then the 3 Musketeers of REST, Json and OAuth came along and changed all that. Suddenly the average dev could understand and consume your API with ease, without requiring a PhD in angle-brackets.
So what’s are the advantages
- Low barrier to entry – No downloads and generally a free trial to try it out
- Pay for what you use – most SaaS providers offer a tiered structure, ie 100 users = £5, 500 users = £10, 100 transaction = £5, 1000 = £10. So price is right for everyone.
- Upgrades are pain free – they upgrade their platform, you benefit at no cost to you (unless API breakage, but that’s rare)
- Economies of scale – If you integrate a SaaS service into your software then each additional customer you gain, will generally mean the price-per-unit you pay to the SaaS provider becomes cheaper overall. Ie because 2 customers are doing 500 transactions between them the price per transaction drops.
- Platform agnostic – cranking out your code in Objective Haskell? That’s cool you can consume our API.
It’s an absolutely brilliant way of delivering tooling to other devs. I’d be convinced if you’re currently trying to sell a SDK to developers that the core or some element(s) of your product could be turned into a service and delivered using the SaaS model.
On a recent project I’ve used Rest based services from SendGrid, Zencoder, Zendesk and SagePay to name but a few, and it’s been a joy.
Conclusion
I prefer to abandon the term SaaS and use “commodity” instead. If you start thinking of your service as a commodity like electricity then it’s easy to think of customers consuming it like a commodity and paying only for what they use.
Major vendors from Microsoft on down are adopting the commodity model. It wouldn’t surprise me, in fact, if Windows 9 was given away for free, and you would just pay for cloud backup, office 365 etc as you needed them.
The SaaS/commodity model is here to stay, it scales, is platform agnostic and makes your service easy to consume and cheap from the end user point of view.
I’d suggest that all vendors of SDKs and tools to other software devs start to look seriously at delivering over SaaS, otherwise your competition will.
Convivial Coding 