Manually Automate Your API
When 369 of something suddenly appears, I get excited about the opportunities to do something with it. When I noticed the 370th new ad network, I realized there were probably a few opportunities to do some interesting things across them. AdReady – a company I made an investment in a year ago – is seriously kicking ass (if you do any display advertising on Google, Yahoo/RightMedia, or AOL go take a look at them) and their early success reinforced this idea to me.
While I’ll talk more about a new investment we’ve made in this area in a few weeks (yeah – that’s what real journalists call "the tease" or something like that), when I was at Clickable a few weeks ago (not an investment of mine, but a really interesting one by Union Square Ventures and Pequot with the tagline "online advertising made simple") we were discussing the challenges of integrating with some of the existing ad networks through their weak to non-existent APIs.
As a horizontal thinker, the API is my friend. APIs are hard and often take a long time to get right. Anyone that has integrated with someone else’s web service knows there are a whole series of things that "should" be part of the next version of the API. Frustration abounds and the rationalization of "we’ll do this thing that will massively drive user adoption and our services utility when company X finally puts it in their API."
To that, I say "manually automate your API." Figure out what you want the workflow to be, hire a person, and have them do whatever the API should do, but do it by simply running the other system. Way back in the land of DOS there used to be neat little script programs (anyone remember the Peter Norton, Paul Mace, or Dan Bricklin tools that did this) that automated your keystrokes. Your manual API person can do the same thing today with the contemporary versions of these keystroke automation programs.
By manually automating your API – or creating a manual version of the API you wished the other guy’s web service had – you can immediately drive more value to your users while prototyping – with precision – what the integration points between the two systems need to be. Yeah – you could get a developer to write a bunch of screen scraping code, but you don’t have any extra developers laying around, plus it’ll break in six days anyway when the other service does a new release. Just hire a young smart person and give him the mission of figuring out how the puzzle pieces fit together.