I believe it was Caterina Fake who coined the term “Biz Dev 2.0” to describe a strategy of making APIs available, letting others integrate and then turning the most promising of these into commercial relationships.  I have recently seen two potential pitfalls of this approach.

First, if you expect to be paid, you might want to consider asking for a credit card early on.  Simply having something in your T&Cs that says that charges will apply for commercial usage may not be good enough to be able to collect.  For instance, what if the developer that signed up for the API key subsequently leaves the customer company?  What if that company denies  having signed up for the service?  Of course you don’t want to put up a hurdle to adoption, so most likely you will need a sandbox environment in which folks can test and play around for free, but any commercial activity requires a credit card.

Second, you better be prepared to deal with load from non-paying customers.  You’d be surprised how hard it can be to get someone to stop hitting your servers even after you have told them to do so.  I am not just talking about deliberate DoS or DDoS attacks.  This even goes for simple incompetence which can result in significant load.  So from day one you should have the ability to drop requests from blacklisted IP addresses a early in your stack as possible (ideally at your firewall / loadbalancer / reverse proxy).

I continue to be a huge fan of the Biz Dev 2.0 strategy, but recommend that you watch out for those two issues.  If you can afford it, you might want to use a service such as Mashery to help (they were thinking of launching a program that would let startups use the services for very little).  If you can’t afford it, build something minimal that still helps you guard against not being paid and against resource hogging.

I believe it was Caterina Fake who coined the term “Biz Dev 2.0” to describe a strategy of making APIs available, letting others integrate and then turning the most promising of these into commercial relationships.  I have recently seen two potential pitfalls of this approach.

First, if you expect to be paid, you might want to consider asking for a credit card early on.  Simply having something in your T&Cs that says that charges will apply for commercial usage may not be good enough to be able to collect.  For instance, what if the developer that signed up for the API key subsequently leaves the customer company?  What if that company denies  having signed up for the service?  Of course you don’t want to put up a hurdle to adoption, so most likely you will need a sandbox environment in which folks can test and play around for free, but any commercial activity requires a credit card.

Second, you better be prepared to deal with load from non-paying customers.  You’d be surprised how hard it can be to get someone to stop hitting your servers even after you have told them to do so.  I am not just talking about deliberate DoS or DDoS attacks.  This even goes for simple incompetence which can result in significant load.  So from day one you should have the ability to drop requests from blacklisted IP addresses a early in your stack as possible (ideally at your firewall / loadbalancer / reverse proxy).

I continue to be a huge fan of the Biz Dev 2.0 strategy, but recommend that you watch out for those two issues.  If you can afford it, you might want to use a service such as Mashery to help (they were thinking of launching a program that would let startups use the services for very little).  If you can’t afford it, build something minimal that still helps you guard against not being paid and against resource hogging.