Don’t Build It In-House, There's An API For That

Disclaimer: I'm the Founder of Routific, a route optimization API for delivery businesses. Because we've packaged a routing API as a product, you can guess how I feel on the subject of whether or not businesses should build things in-house or leverage existing APIs. Below, I'll lay out my arguments and also take the time to address the other side of the debate.

We live in a time where there is an API for almost anything. You can build and launch a product quickly if you know the right tools. We don’t have to build our entire technology stack from scratch — something that most first-generation technology companies were forced to do.

If you’re looking to build a commodity feature, there’s probably an API for that — and that API will most likely be better than what you can produce. Let me explain.

More reading: What is an API? In English, please.

With all the established cloud services at our disposal, it simply doesn’t make sense for startups to build and host their own servers anymore. Why do we still decide to build commodity services in-house? Why do we want to reinvent the wheel, when some APIs provide a better, more effective wheel that has been refined for years?

I’ve fallen into this trap myself many times over, but I've finally learned my lesson. In this article, I explore the psychological, temporal, and strategical aspects that influence the decision making process — in an attempt to rationalize myself out of the destructive “let’s-build-it-ourselves” mentality.

(If you don't have time to read on, here's an infographic that weighs the pros and cons of API vs. in-house.)

Lesson 1: Leverage existing APIs from the get-go.

Hackers are like magicians. We create things out of thin air. Churning out heaps of code makes us feel productive and it proves our worth. But does it necessarily contribute to the success of the company?

When we first began getting traffic to Routific's route optimization API and people began signing up for our routing web service, we tried to build everything ourselves. An automated email system? Easy! Add a few endpoints to the backend, use Gmail’s SMTP server with Nodemailer and you’re done. Since we could leverage open-source libraries, it was relatively easy to do. But it required unnecessary engineering effort to build and maintain, and soon became a distraction.

We eventually needed to change our email templates, add an unsubscribe button, and incorporate email analytics. This is when we realized that Mandrill (now part of Mailchimp) was superior and far more comprehensive than what we built.

So, here's lesson #1: Leverage existing APIs from the get-go, and don't waste your time building and maintaining systems that aren't your core product.

Lesson 2: Third-party services are always cheaper than building it in-house.

Many APIs have a free startup tier, so those are obvious choices. What about the services that cost $69/month? Some how we have a distorted perception of recurring monthly costs: businesses seem to be more willing to invest weeks of engineering time (let’s value that at a conservative $2.5k) to build something inferior rather than subscribing to a $69/month service, even though you could have a 3-year subscription for the same price and it comes with support and updates.

Most services are not nearly as expensive when compared to the cost of an engineer. This article from Founder Collective really drives this point home. It lists 36 services that Sawhorse Media uses for the price of a junior developer.

If a piece of your tech requires a dedicated engineer to build, test, and maintain — assuming an engineer costs about $10k/month or more— you shouldn’t even flinch at a service that would cost $2k/month. It is still 5 times cheaper. Most importantly, you are freeing up an engineer’s time.

An example from our experience at Routific: We had a fast-growing meal delivery startup in Paris compare their in-house routing algorithm to Routific.  They spent three months and $16,010 USD building it. Despite the investment of time and resources, the in-house routing system had sub-optimal results–especially when compared side-by-side to Routific's route optimization API.

Read: Routific's route optimization API increases Popchef's on-time deliveries by 44%.

So here's lesson #2: Third-party API services are (not only better but) always cheaper than building it in-house.

Lesson 3: Rely on a third-party service to free up your time to focus on growth.

Time is the most valuable asset for any company — or life in general for that matter. If you run out of time, you’re dead. So let’s not waste it.

Reinventing wheels is most certainly a waste of time. Leveraging existing services will free up your time, so you can focus on the things that really matter: growth.

At Routific, we used to host our own routing API documentation pages, before we decided to switch over to ReadMe. Maintaining our own documentation wasn’t too hard, but it was taking more time than necessary. ReadMe is one of the leading experts in personalized, interactive developer hubs. Why not leverage their expertise and their out-of-the-box platform so we could focus on our improving our routing algorithms? Focusing on your core competency, your bread and butter if you will, enables you and your team to grow your business.

If you've read this far, I hope I'm in the process of convincing you to leverage existing APIs. But probably have still some questions that linger in your mind. I'll try to address those doubts below:

What if I have no money?

Pre-funded startups are by definition strapped for cash, and even a $39/month subscription seems expensive. Scrappy founders try to avoid cost at all cost — we certainly did. In hindsight, this was a mistake because we ended up spending time on non-crucial things, even though it was a race against the clock. Spending time in order to avoid cost is a contradiction, because time is money. Delaying the growth of your startup means that you have to bootstrap longer.

And while startups have little money, they have even less time. Use the latter wisely to maximize your chance of success.

What if I'm a well-funded company?

What’s even more interesting is the case of well-funded. Companies that have raised large rounds of financing have an even stronger “build-it-ourselves” mentality. They have too much money. They double or triple their engineering team to build everything in-house. I just cannot wrap my head around this. Once you are on the VC treadmill, your goal is to hit the growth targets no matter what. You have even less time to waste!

Money is not an issue, so spend it on third-party services that can help you hit your growth targets quicker. Focus on your KPIs. Do things that really matter. You better have really good reasons to build something yourself.

Is there ever a time that building in-house is a good thing?

There are two main reasons when you should consider building commodity features in-house: security and reliability. As you increase the reliance on third-party services, you also increase the potential for failures.

From a security standpoint you’ll have a larger surface area for potential breaches. If one of the services that you use gets compromised, your sensitive data might be at risk. This isn’t a concern for stateless APIs.

From a reliability standpoint, any third-party outage is going to affect your service. For example, if your business relied on 10 third-party services, each with an uptime of 99.9%, you now have a 99.0% uptime, because it is multiplicative — like Christmas lights in a series circuit.

What about Intellectual Property?

One argument I’ve heard way too many times is around this thing called Intellectual Property — often confounded with Lines of Code. It is important to our investors that we build up our IP, the argument goes. That’s great and all, but you should be really careful about how you define your IP.

Let’s take an on-demand laundry business as an example. To build a successful startup, you must continuously provide value to your customers so they keep coming back. Here’s a small sample of things that the laundry business needs to figure out to this end:

• pick-up clothes on time
• quality control
• customer support
• workforce happiness
• branding
• customer acquisition
• actual cleaning

This is your IP: things you have figured out through the course of finding product/market fit; things you know about your customers that nobody else knows; ways in which you have figured out a scalable business model.

While your entire logistics operations is indeed IP, your homegrown routing system isn’t. What competitive edge — which ought to be the point of IP — does a home grown routing system give you, if your competitor is using a route optimization API (disclaimer: we built this API) that does it better?

If there is an API, it means that the offering has been commoditized. It is not valuable IP.

In conclusion

Don’t waste time building things that somebody else has already built. In most cases, if there’s a service you can rely on, you should use it. It will speed up your development, so you can focus on your core competence — which is your real IP.

If a third-party service seems expensive at first, do the math and compare the costs — both monetary and opportunity — of building and maintaining it in-house. Baremetrics just released an awesome Build vs. Buy Calculator. Let the numbers do the talking.

Don’t build it in-house. There’s an API for that.