How Developer APIs Can Make or Break Your Business
January 27, 2020

Jevon MacDonald
Manifold

APIs are a fundamental part of modern web application development, and it's a little hard to imagine a world without them. But the decisions that startups make about implementing and managing their APIs can have profound effects on the growth trajectory of their business, both good and bad.

Startups building tools for developers are often eager to impress their customers, exposing all manner of cool tech within their applications for those customers to consume via APIs. This is often the simplest path forward at the beginning; it's a quick and easy way to get developers using your technology, and it feels like a good foundation for the application as it matures.

But over the next five years, the way that software developers build applications is likely to change. Startups need to give themselves flexibility so that, as things change, developers have a choice of what they are going to use to access technology, and how they are going to pay for that access.

Should You Expose APIs to Developers?

As your application grows, you'll soon face a problem: what's your business model? Do you charge developers for API calls? Do you build an official client library for your tech, buttressed by enterprise support? These are questions that need to be considered at the outset.

There are many benefits to thinking critically about exposing APIs to developers. Easily accessible APIs sound great, but they're not necessarily very efficient: even simple shopping-cart applications can require developers to hit dozens of APIs to get a result. Building a client library that can achieve that result in one fell swoop creates value, and also makes your technology easier to consume.

When you take a foundational component like an API and make your users dependent on it too soon, you will struggle to change it out of fear of breaking existing customer functionality, and it will warp everything you want to build on top of it. You're going to be wrong about things, and you're going to have to react to being wrong.

Twitter is perhaps the most famous example of a company that went all-in on API access only to discover it couldn't make money if people preferred to consume Twitter outside of Twitter, using superior third-party user-interface clients to what Twitter Inc. offered at the time. It cracked down on third-party Twitter client development and acquired some talent on the client side, but this process alienated a lot of developers.

Different companies have different needs, but there's one fact of life that anyone working in enterprise technology over the last decade knows all too well: Things change, and the pace of these changes seems to be accelerating.

Take Java: Five years ago, Java was insanely relevant, and it wasn't uncommon to see development tools designed specifically for Java developers. Today, a ton of Java apps are still out there, but the language is only relevant to specific communities of developers. Others have moved on to brighter and shinier languages, and tools built specifically for Java developers can't address their needs.

Startups also tend to build their early products according to the needs of their early customers, which makes a lot of sense when you're trying to prove that your technology and your team are worthy of that revenue. However, as your company grows, newer customers might have different needs, and your product needs to be able to protect the APIs built for the early customers while adding layers that address the new use cases.

Thinking About APIs as Microservice Architectures

A better way to think about APIs might be microservice architectures. In a microservice architecture, the individual services are relatively minor cogs in the wheel; some are more important than others, but the whole concept holds that if one microservice goes down, the application stays afloat.

The value comes from being able to organize and manage those microservices, which is why startups should think carefully about whether or not to expose their APIs early in their development. Once your customers depend on your APIs, rather than your products, so do you.

All of these issues involve trade-offs, of course; exposing a lot of your APIs might kick-start interest in a particular project or company. That's why these decisions are hard.

Here are a few things to keep in mind when settling on a strategy for your APIs:

■ Include rate limiting in all your clients, even if you don't expect to be that big right away. No matter what your business involves, you'll encounter bad actors, service instability at the exact moment you start to attract users en masse, and potential infrastructure cost overruns from inartful scaling.

■ Give yourself portability in your stack. Use Kubernetes and Docker, adopt a microservices architecture, and don't use services that bind you to a particular cloud.

■ Give yourself a layer of abstraction that can adapt to changing software development norms. Make it very clear which APIs are public and which are experimental, and hold on to the experimental ones as long as possible.

■ Take responsibility right away for managing the versions of your APIs and client libraries, and make sure you keep them in sync.

If you think of your APIs as your business, you'll likely default to charging on a per-request basis, based on the cost of providing the service and some sort of markup for the investment in the technology. This is easy to do as an API-driven company, but it also makes life that much harder for your customers. Is that what you really want?

Jevon MacDonald is Co-Founder and CEO of Manifold
Share this

Industry News

February 27, 2020

Datadog announced an integration with Nessus from Tenable.

February 27, 2020

Talend announced the Winter ‘20 release of Talend Data Fabric.

February 27, 2020

Alcide announced that the Alcide Kubernetes Security Platform now supports compliance scans for PCI and GDPR, enabling DevOps to deliver regulatory compliance checks rapidly and seamlessly alongside Alcide’s leading Kubernetes security capabilities.

February 26, 2020

Perforce Software released a free tool for organizations considering open source software - OpenLogic Stack Builder.

February 26, 2020

Applause announced a new partnership with Infosys to provide broader end-to-end digital experience testing services to clients.

February 26, 2020

RapidMiner announced the release of its platform enhancement, RapidMiner 9.6. This update prioritizes people – not technology – at the center of the enterprise AI journey, providing new, unique experiences to empower users of varying backgrounds and abilities.

February 25, 2020

JFrog announced the availability of the "JFrog Platform," a hybrid, multi-cloud, universal DevOps platform.

February 25, 2020

Nureva added new agile canvas templates to Span Workspace, including a heat map developed by Jeff Sutherland, the co-creator of Scrum and founder of Scrum Inc. and Scrum@Scale.

February 25, 2020

Agiloft announced the addition of its new Agiloft AI Engine, complete with prebuilt AI Capabilities for contract management and an open AI integration that allows customers to incorporate custom-built AI tools into the no-code platform.

February 24, 2020

Cloudify announced that its latest product update - Cloudify version 5 - features an Environment as a Service component, designed to achieve consistent delivery and management of hybrid-cloud services and network infrastructures across CI/CD pipelines - at scale.

February 24, 2020

Checkmarx announced new enhancements to its Software Security Platform to empower more seamless implementation and automation of application security testing (AST) in modern development and DevOps environments.

February 24, 2020

Rapid7 and Snyk announced a strategic partnership to deliver end-to-end application security to organizations developing cloud native applications.

February 20, 2020

The American Council for Technology and Industry Advisory Council (ACT-IAC), the premier public-private partnership dedicated to advancing government through the application of information technology, officially announced the release of the DevOps Primer.

It was produced through a collaborative, volunteer effort by a working group from government and industry, hosted by the ACT-IAC Emerging Technology Community of Interest (COI).

February 20, 2020

DLT Solutions, a subsidiary of Tech Data, launched the Secure Software Factory (SSF), a framework that provides the U.S. public sector with consistent development and deployment of high-quality, scalable, resilient and secure software throughout an application’s lifecycle.

February 20, 2020

Netography announced the general availability of the company’s Security Operations Platform.