Many software entrepreneurs are interested in creating a working business around an API. As such, the API-as-a-Product trend has blossomed in recent years, with more and more startups beginning to embrace an API as a core SaaS business offering. This is exciting, as a self-service API could generate passive income for the provider.

However, it may not be as “passive” as you think. Sustaining an excellent API-as-a-Product requires a good deal of ongoing support. There are also many open-ended questions to answer when forming your business model. For example, how should API calls be priced? How should we design the service for a quality developer experience? How can we evolve the API without introducing breaking change? What challenges should we anticipate as usage scales?

For our API-as-a-Product LiveCast, we brought in Alan Glickenhouse, IBM, and Ed Freyfogle, Co-founder of OpenCage, to take a more in-depth look at the API-as-a-Product trend. In the event, we explored how to make a working business around an API and realized some unexpected realities of owning an API-as-a-Product in production.

Below, we’ll review these unexpected challenges that arise with API-as-as-Product. Of course, not every API product will encounter every one of these issues, but all should be aware. So consider these tips to overcome them to create a modern, profitable, developer-friendly business.

1. It’s More Than A Technical Challenge

“An API product is an API offering made available to a target market to satisfy a developer customer’s needs,” describes Glickenhouse. Having a standardized, machine-based delivery mechanism enables the rise of automation and overall digitalization. But creating a working, self-service API model is harder than it seems.

“It’s really hard work,” said Freyfogle. API providers are often naive in believing that providing an API is merely a technical challenge. “If you can get it to work, that’s enough,” you may think. In reality, your business challenges can significantly outweigh the technical effort.

This is, in part, due to a general knowledge gap. While there are many shared standards around API formats, design, and protocols, fewer shared business practices exist within this new economy. “There’s lots of very good technical advice, there’s very good discussion about newest technology, but not nearly as much about the business side of things,” said Freyfogle.

2. Realizing You Need an API Product Manager

Due to this condition, many API products enter the market without a product manager or a lucid product mindset. This may be because the product is a solo venture or supported by a lean team.

A traditional product manager identifies a target market, understands customer needs, and generates a package to suit those needs. Though API teams could benefit greatly from an API Product Manager, Glickenhouse finds they don’t often loop one in. “This is a role too many businesses try to do without,” describes Glickenhouse.

Taking a product management viewpoint can help you consider the API lifecycle and estimate ongoing costs. In the process, you may discover complementary API management or gateway tools that could help host and secure the API offering, offloading potential maintenance work.

3. Developers Will Spam Your Free Trial

Ed Freyfogle has spent over five years running OpenCage, a straightforward geolocation REST API powered by open data. Throughout running his API-first SaaS business, he’s noticed a weird phenomenon — “people will go through extreme lengths to not become customers.”

Software developers want to try before they buy. Thus, having a freemium account or free trial is standard for SaaS subscription models. But, Freyfogle has found that users routinely abuse these free trials. Instead of upgrading to a paid tier, some users will rig up hundreds of free trial accounts. For the API owner, policing all this can take a toll. “It’s frustrating, and takes a lot of time,” said Freyfogle.

4. Developers Are Resistant to Paying

Developers want to pay only for what they use. Yet, Freyfogle has noticed a stark contradiction: developers want complete pricing predictability, but they are terrible at estimating usage. Within software developer culture, people are “deeply resistant to paying for anything,” says Freyfogle.

Interestingly, in practice, Glickenhouse finds that the bulk of API business potential doesn’t even lie in direct charging, but in indirect models. “This is the real API monetization,” he describes. For example, in some affiliate models, a developer receives payment, acting as an agent for the provider. Therefore, it may behoove API providers to consider what alternative methods or partnerships they could leverage outside of direct monetization.

API providers must consider usage limits, price subscription plans accordingly, and consider how they bundle endpoint access per developer account. With all this in mind, figuring out the financial terms around an API product and proving its success in production may take some time.

5. Providing Ongoing Support is Challenging

The burden of providing support may come as a surprise. Especially for small teams, it can be challenging to provide ongoing feedback to support a functional integration. This is worsened by the fact that many people don’t read the docs. “Build it and they won’t read it,” joked Freyfogle.

Or, developers may approach your service who have little programming experience. “Definitely don’t assume all users will be highly experienced engineers,” said Freyfogle.

Global API services may also encounter language barriers. Though English is the lingua franca of software development, many users won’t feel comfortable asking questions in English and will struggle to communicate with you. To help solve this issue, Freyfogle recommends eliminating jargon and anglo-centric cultural knowledge from your support materials.

6. Lowering Barriers To Adoption

“APIs allow business assets to be securely and easily consumed and used by developers,” describes Glickenhouse. Yet, too often, developer experience isn’t front and center for API products. There should be “no barriers to adopting an API product,” stresses Glickenhouse. Excellent self-service developer experience requires forethought and a good deal of construction.

A sleek API portal will include reference documentation, testing environments, code samples, code snippets in multiple languages, a getting started guide, an authentication guide, and SDKs for multi-platform support. By lowering the entry bar to meet the developer wherever they are, you can increase usability and adoption rates.

7. Your Real Competition May Surprise You…

The Amazon, Microsoft, and Google behemoths of the world could easily build out an API and kill your product in an instant, right? Well, in practice, Freyfolge hasn’t found an issue here. It’s easy for a startup to differentiate itself. Instead, the real competitor is often the developer user, saying, “oh, I could build this myself.”

Developers may question the value of your offering and assume they can build it on their own. This is especially common if your service is a layer around open-source data, as is the case with OpenCage.

“A big part of the argument is convincing them why they shouldn’t build it themselves,” said Freyfogle. To get through to potential users, he recommends stressing how maintenance is much harder than development. Make time and cost savings clear, and create clean developer experiences for quick, convenient use. Once developer users realize the difficulty in constructing their own API, they will more likely return to your service.

8. Build It, And They (Might Not) Come

Many fledgling API products suffer from a lack of promotion. “Don’t assume you only must make [the API] available,” said Glickenhouse. “You need to encourage usage, and really drive consumption, and iterate the product,” he described.

API-as-a-Products must not only promote themselves but fight for attention against competing services. To stand out, there are many methods to increase the exposure for your API. For example, you could arrange a Product Hunt launch and offer perks to new users. You could profile your service in API directories and marketplaces. Or, improving developer center SEO and publishing content for non-IT visitors could help appeal to new audiences.

Final Thoughts: The Real Product is Trust

We have hardly scratched the service of what it takes to sustain a functional API product. As more companies come to rely on third-party API dependencies, there will likely be a greater need to meet SLAs and compliances. Additionally, as more and more APIs are breached, security and access management is surging in importance. Auditing your surface area for security vulnerabilities is thus vital to maintaining a stable API product.

As you can see, running a public API-as-a-Product is not as easy as it seems. It’s not just about writing an OpenAPI spec and generating some docs. In practice, the bulk of your time may be spent in entirely non-technical areas to support the product.

Thinking from the developer’s perspective, some common requirements include: Does it solve my problem? Can I depend on it? Is the price reasonable? With all this in mind, what you’re really selling is a commitment to maintain the API. “The real product is trust,” said Freyfogle.