Hacker News new | comments | show | ask | jobs | submit login
Hiring via API (mattbrezina.com)
44 points by brezina on Aug 24, 2011 | hide | past | web | favorite | 7 comments

Outsourcing parts of your software service to other software services via meterable API is indeed like a brick and mortar outsourcing part of their product or service to other brick and mortar businesses. In all the good ways, and all the bad ways. But thanks to APIs, some of the bad ways are worse than others because they impose switching costs.

In the physical world, if FedEx does your deliveries and they experience a “service interruption,” UPS will be at your door within an hour to take over. Simple delivery services are easily substitutable (more complex supply chain relationships such as integrated data processing systems and warehousing are not, of course).

APIs are all about imposing switching costs. We need to think about that carefully, especially when some of these other services can go down.

Which brings me to the next point. Conventional wisdom (“conventional" does not mean it’s right, just oft-quoted) is that you should not outsource your core value proposition, just the things around your core value proposition. So yeah, outsource hosting code repositories. What about notifications? Well, if notifications went down for a few hours, does your service still delight customers? If so, then notifications are not part of your core value proposition. They’re a nice-to-have, or perhaps a checkbox feature.

But if your service becomes useless without notifications, well, this is not something that should be outsourced without a great deal of thought. Your notification service is actually a partner of yours, not simply a supplier. You ought to have a very strong relationship with the provider or have an infrastructure that can fail over in minutes.

I’m not speaking against the article, just pointing out that APIs impose switching costs and that we should be careful when using an external service to implement part of our service’s core value proposition. If the external service goes down or goes away, we need a backup plan.

Very good point. I recently got bitten quite badly by having an external email parse api drop a whole lot of our support emails. I'm quite certain the error was on their side but theres no real way to prove it (besides log entries saying it was delivered to them, and none at our notification url).

Its a complicated proposition though. If I switch back to a home-brew system I'll lose a lot of the nifty features in exchange for more control.

You've hit on one big risk in this new way of doing business. If Heroku or AWS or Urban Airship goes down, we all get pissed. This is why these companies emphasize their reliability and customer service.

However, the better question is "would the service be more reliable if my team had written it?" People feel safer when they are in control (people are more scared flying than driving a car, yet driving is much more dangerous.). Chances are Urban Airship is going to offer a more reliable notification system than you would build yourself because this is the one thing they do.

Yeah, this is Core vs Context. Outsource everything that isn't core to your business. Concentrate energy, brainpower and delivery on the core that makes up your unique value.

“I’d rather do contract work.”

One of the best programmers I know says this.

This domain is blocked by my work firewall as "pornography". Too bad.

how weird? Sorry about that - I have no idea why that would happen. Anywho - the post has been added as a guest post over at Inside Mobile Apps. check it out here: http://www.insidemobileapps.com/2011/08/24/hiring-via-api-br...

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact