Don’t build it in-house. There is an API for that.
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.
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. 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.
tl;dr We made an infographic that weighs the pros and cons of API vs. in-house.
The hacker mentality
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?
In Routific’s early days, 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 was superior and far more comprehensive than what we built.
Lesson 1: Leverage existing APIs from the get-go.
The perception of cost
Many APIs have a free startup tier, so those are obvious choices. What about the services that cost $69/month? Somehow 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 — 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.
Lesson 2: Third-party services are always cheaper than building it in-house.
A fast-growing meal delivery startup in Paris compared their in-house routing algorithm to Routific. See the results here.
All you need is time
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 API documentation pages, before we decided to switch over to readme.io. Maintaining our own documentation page wasn’t too hard, but it was taking more time than necessary.
Lesson 3: Rely on a third-party service to free up your time to focus on growth.
What if you 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.
Well-funded startups
What’s even more interesting is the case of well-funded startups. 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.
When 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. Because there’s an API for that (disclaimer: we built this API). What competitive edge — which ought to be the point of IP — does a home grown routing system give you, if your competitor is using an API that does it better?
If there is an API, it means that the offering has been commoditized. It is not valuable IP. Investors won’t care.
TL;DR
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.
Big thanks to @rohamg and @suzannebma for reading early drafts of this!
