Why You Should Build Your Company on APIs
This is a guest post from Matt Sornson, Growth Marketer at Clearbit.
Uber is built on dozens of third-party APIs.
But if you asked Google Maps in 2006, Twilio in 2008, or Braintree in 2007 about potential use-cases for Uber’s product — not one of them would have said ride-sharing. By opening up their API to the world, they secured a spot in future technology that hadn’t even been built yet.
When you build a monolithic product, you’re building a product for today. As the environment changes, your team has to make adjustments to keep up, or die. It means short product cycles, frequent iterations, and obsessive customer feedback just to keep up with what people need.
When you build an API-first product, you’re building a product for tomorrow. You’re creating a functionality — just one layer of software — that can be used for today’s purposes, but isn’t limited to them. You’re doing one thing really well and then putting it into the hands of thousands of developers to adapt to a myriad of use cases. Once it’s out there, it has the highest chances of sustainability.
Here’s why you should build your company on APIs.
A Brief History From API-Last to API-First
Amazon was one of the first companies to break away from the monolith model. In typical Amazon-fashion, the migration started with a mandate from Bezos, himself. The mandate ordered every team to expose their code through service interfaces — and to only communicate through those interfaces.
Within a few years, Amazon chopped up their software into hundreds of microservices that work together via internal APIs. They were able to increase the frequency of deployment, mitigate risk, and scale. This lay the foundations for what later became AWS.
It wasn’t long until companies saw a new potential for monetization. API-first companies like Twilio, Stripe, and Agolia didn’t bother building an entire platform that they sold to an end user — they build just an API that they could sell to developers. And instead of creating an “artificial,” API, it was designed for public usability from the get-go. By focusing 100% of their efforts on one functionality, such as voice messaging or payment processing, each company could offer the best feature on the market via their API.
At Clearbit, we had decided to build an API-first company. We wanted to turn a Google search into a developer tool. Along the way, we learned dozens of use-cases for our data-enrichment API that we could have never conceived of. After years of gathering data and learning from our customers, we decided to build a B2B product on top of our API.
Building an API first and a product later has benefited our company multi-fold: our code was cleaner, the upkeep was easier, and eventually, our product was much better informed. Here’s why every everyone should build their company on APIs.
1. Constraints Make for Better Code
If you build an API-first product, that means that every line of code you write has to be written with an end-user in mind. Adobe’s Lars Trieloff deems this the first and most important principle of API-first design. The principle states: “Your API is the first user-interface of your product” This is a constraint that most developers aren’t used to. They code first, design later.
But imagine if civil engineers built skyscrapers without a blueprint. Or if aeronautical engineers built rocketships without any forethought on how it would get to space. In computer engineering, the stakes aren’t as high, so many of us get away with writing sloppy code that just works. When it comes to going back and fixing something, or getting a new developer to make sense of that code, however, we run into trouble.
API-first imposes constraints on how we code. Developers are forced to consider the direction that they’re headed at every turn, to make sure they’re building something that will lead to a practical application.
There are a number of tools that have been built to help developers in this endeavor, including:
- API definition formats such as Swagger, API Blueprint, and RAML, which serve as guidelines to standardize how you build your API. It’ll help keep your design simple and keep it to the REST standards.
- API mock + testing tools such as Swagger Editor, Apiary, and Anypoint API, which let you quickly write a mock API (before writing any code) according to a definition format, and then share with your team for feedback. Most of these platforms also auto-generate documentation, based off that API.
Writing clean, elegant code is something every developer works toward because, by nature, we’re allergic to the notion of working inefficiently. As our founder, Alex, has stated, our goal is for “Clearbit, over time, [to] become renown for its code quality and its artistic approach to code.” Building API-first has given us an excellent foundation for that goal.
2. Modularization Makes for Easier Upkeep
As you eventually build a product on top of the APIs you’ve either built or integrated, it won’t be one, messy, tightly-coupled beast. The idea behind microservices is to write code that’s inherently modular. Each component is separate and distinct, and can be reused. But building loosely-coupled services is easier said than done.
Interfaces are used to decouple services. So when you build API-first, you’re essentially building the boundaries between classes. If you’re going top-down or design-first, you’re creating the boundaries before you get to writing the code in the first place.
With modularization, it’s much easier to:
- Debug, since each section of code is distinct and doesn’t affect other parts of the application. This means less downtime and faster iterations.
- Reuse code, since one task is represented in one section of code, a developer can reuse that code whenever they need to do the same type of task. This means more efficiency, and higher consistency across code.
- Share code, since it was built with usability in mind. This means higher accessibility and faster optimization of the code.
At Clearbit, when a developer is working on improving the Enrichment API, they’re not affecting the Risk API. They can get thoroughly acquainted with the code for the former and start finding ways to improve it without knowing anything about the latter. At our small company this is already a game-changer for speed of execution, but you can imagine what this could mean at a bigger company where, historically, developers have had to deal with legacy code.
3. More Developers Make for Better Products
When you start with the application, you’re limiting what’s possible with the code that you write. You might be building a potter’s wheel when there are people out there trying to build a chariot. By starting with an API, you’re keeping people from re-inventing the wheel and you’re benefiting from the creativity of dozens or hundreds of developers rather than just a handful.
If you start your business with APIs, you can wait years before building an application. In that time, you can perfect the foundation on which you’ll eventually build as you learn from your users. After enough data-points, something is going to stick. You’re going to realize that there’s one or two use-cases that derive the most value from your code, and you can build the best possible product with that information.
Clearbit started with just one API — our Enrichment API, which gave developers access to up-to-date data such as location, job title, company size, and the technology they used. From there, we expanded our offering with a suite of APIs, adding Discovery, Prospector, and more — all before building any full-fledged application. Being API-first enabled us to learn about dozens of potential use-cases, before committing to one.
Once we had enough data points, we built products where we knew there was already a demand. Our Salesforce add-on, for example, was built after we had learned that many developers were implementing our API to make their sales reps more efficient. We created an add-on for Sales reps to download in just a few clicks, without having to bother their dev team.
Future-Proof Your Product
The first generation of cloud software businesses built their API as an afterthought. They didn’t consider developers a big enough market — and, at that point, they may have been right. But what they estimated in number, they underestimated in impact. While a software company can switch their project management tool, they aren’t going to rebuild the foundation of their code. As long as there’s an Uber, a Netflix, a Trulia, an EHarmony — Twilio will be in business.
When you build your business on APIs, you’re future-proofing your business. You’re creating building blocks and throwing them into the developer ecosystem, where they have the highest probability of being indispensable.
IPinfo is a comprehensive IP data and API provider with flexible pricing plans to meet your business needs. We handle billions of API requests per month, serving data like IP geolocation, ASN, mobile carrier, and hosted domains. Sign up for a free account or contact our sales team to learn more.
