The growth of the API economy has lowered the barrier of entry for many companies. While more businesses are afforded the opportunity to enter the market, building a company around an API still presents a number of potential pitfalls.
Kairos bills themselves as a human analytics platform for developers. They offer and API and SDKs that let developers integrate face analysis into any app or service. A recent post on Nordic APIs looks at some of the lessons Kairos learned while building an API-first startup.
The first lesson is to listen to what the market needs. For an API-first company this often means designing an API as an MVP (Minimum Viable Product), and gathering feedback from key stakeholders both internal and external. By doing this it becomes easier for a company to understand their market's true needs.
Customer service is often an afterthought but according to Kairos' second lesson, companies should be an integrated part of a company's culture and structure. The advantages are two-fold: companies can hear first hand what issues developers are having and uncover unmet needs, and in keeping with the ideals of providing quality developer experience, businesses can help support their developers.
Lesson three is important for any organizations looking to start an API program but critically so for API-first companies; you must treat your API like a product. This means not only focusing on the functionality of the API, but also thinking about who the target audience is, how the API will be marketed, what sales strategy will be used, and what support processes, including customer service, are put in place.
Kairos believes that not everybody will be a good fit in a startup. For many startups, some early hires will inevitably not work out. Lesson four states that hiring the wrong person can help a company hire the right person in the future. There are techniques for offering job candidates a trial run that allow both sides to better determine if the fit is a good one.
The fifth lesson is to show potential users the outcomes of using an API instead of telling them. This holds true for both technical and non-technical audiences. For developers, providing examples as part of the API documentation helps them quickly get up to speed and is part of providing a good developer experience. For a non-technical audience, an API demo can showcase how the API solves a problem giving potential customers a clear understanding of the product in action.
Early on, Kairos found that their software build and deploy process was prone to error due to it's manual nature. This led to lesson number six, invest in automation. Kairos re-architected their platform into what they feel is a sustainable Platform as a Service centered around technologies such as using Kubernetes as the orchestration platform for managing Docker containers.
Lesson number seven ties in with lessons three and five; APIs aren't only for developers. Kairos learned that when talking to business decision makers, they needed to avoid tehnical jargon and focus on what is relevant to their customers. This meant making the API conversation less about features and instead relying on compelling narratives that spoke to the value and benefits that the API could offer.