The word startup is one of those trendy silicon valley terms that’s been thrown around the last few years. With it come images of warehouses lit by Apple computer screens, being grinded down by young hipster like adults as they try to sell, sell, sell.

Brian Brackeen, the CEO at Kairos, looks at it differently: “A startup is a mentality, a grit, a singular belief that beyond all odds you are going to change the world”. Kairos, a human analytics platform for developers, has gathered some useful experience while turning an API-first business into a working model. In this article we’ll share 7 lessons they’ve learned while growing an API-first company from the ground up.

Lesson 1: Don’t ignore the market.

There are dozens of stories about extinct startups that never found product-market fit, or ran out of money before they could even build an MVP (Minimum Viable Product). Those companies likely failed to validate their ideas quickly and efficiently, or if they did, failed to act on the data and learn what the market needed.

And what the market needs is very different from what a single customer needs. Too often founding teams are led astray by the appeal of building custom features to close a deal. Or they simply mimic the competition, thinking they need to match what already exists.

Kairos didn’t start out as an API company but as a traditional B2B SaaS startup; they built an iOS time clock for employees to track their work hours. Yet, as they learned more about the market’s needs, they saw an opportunity to disrupt the tired and slow-moving time & attendance industry with facial recognition instead. After building a quick and dirty internal API, and after showing it to a small group of select customers, Kairos proved the concept could be applied in many situations. By listening to the needs of the market, you can increase your own opportunity exponentially.

For startups looking to raise venture capital, you may have to similarly pivot before you can demonstrate a highly scalable and repeatable business model to investors. Becoming API-first may be an important facet in this, as it often means you can solve diverse business problems with a relatively small team, making the product highly efficient, scalable and profitable.

TIP: Train your inner Product Manager: Learn how to say “no”

Lesson 2: Customer Service isn’t a Department

Companies sometimes look at customer service as a separate function. Kind of like a fire department, we only think we need it when there is a fire and when there isn’t one we passively wait for one to start. The problem with this is when a fire spreads and no one is ready, everyone is affected.

Quality developer experience should be part of an API product. Just as valuable as any other product feature, it should be designed to solve problems and help developers achieve their goals. With a few simple processes everyone — from the CEO to the Intern — can be kept in the loop on support tickets and bugs. The agility of a startup means that anyone on staff should be able to deliver customer support.

Tools like Groove, Slack, and good old fashioned email have been proven successful. Groove manages support tickets and conversations which connect to Slack, allowing the whole team to see any support conversation and collaborate on solutions before replying, leading to significantly better time. Launching a dedicated Slack channel for customers can put you even closer to their daily needs.

This level of transparency breeds efficiency and accountability and more importantly, you can walk in the shoes of the customer as they interact with your platform. In turn, this tightens the feedback loop at the start of the customer journey, making common problems easier to identify and ultimately solve.

TIP: Pitch Customer Service to your company as the ‘UI of your brand’. It is, after all, one of the key interfaces that your customers experience.

Lesson 3: Treat your API like a product

Most providers didn’t start out as API-only companies, yet saw APIs as a way to diversify an existing business model. Merchant services such as Square, or stock photography behemoths like Getty Images provide APIs to allow deeper integration and ’stickiness’ of their products. For them, an API is a feature of their overall solution — and that’s okay — we’re not saying this is inherently bad. However, it is different than thinking of an API as a product and building a company around it.

The most effective products aren’t always the ones with the most features. More commonly, for an API-first business, the API will fulfill a very niche, specific “job.” By deeply understanding these jobs, and the types of solutions a customer integrates, companies can better design products that are geared to what a customer is trying to achieve. To discover your startup’s “job,” interview customers to unlock important data about why they chose a specific API over another, and how the API fits into their applications.

Kairos uses a customer research methodology inspired by Tony Ulwick’s Jobs to Be Done framework. It’s good practice for sales and marketing teams to refine their discovery interview techniques to extract insights from customers at the very beginning of their journey. Rather than simply take orders, probe to unearth the deeper reasons behind why someone is interested in your technology. This outcome data can be a boon to informing product, marketing and business strategy.

TIP: Pretend an API is a candy bar. How is that packaged and marketed? Ulwick’s exercise will help to focus on the experience and brand, not the features.

Lesson 4: Hiring the wrong person helps you hire the right person.

Working at a startup sounds cool, but it isn’t for everyone. Some people just work better in bigger businesses, but it may take hiring those people to figure that out. In the beginning, some early hires may not be able to deliver for a startup. Treat such team fluctuation as an opportunity to determine what you want in a future core team.

Startups don’t always have fancy benefits and large salaries to offer prospective candidates, but they do have a vision. The vision of a company can be use to attract the right employees. Those who have a similar vision in their life or understand the company’s bigger goals will be more drawn to the company than others, and for the right reasons. Define and communicate the vision to prospective hires and the right people will start submitting their resumes.

There is an old startup mantra: “Hire slow; fire fast” and we tend to agree. Frameworks such as the GRIT scale have proven useful in understanding some employee archetypes. Time is the most expensive asset, so use it wisely. Yet, as a leader try to always build a network of potential future hires.

One technique is to trial candidates in a mutually beneficial, low-risk format. Invite them to join tech stand-ups for a week, or ask them to supply feedback on things like our product roadmap. These gentle steps are often what is needed to help show where value can be exchanged, as well as providing a window into how the company operates.

TIP: Get involved in the local tech community and get to know the people attending local networking events, hackathons, and summits. People who invest in their future, their career, are part of the community because they care and are people you may want to invest in.

Lesson 5: Show, don’t Tell

Developers and a technical audience will understand what an API is, yet APIs are often unintelligible to non-technical folks. 99 times out of 100 a potential customer will want to see the outcome of using an API, showcasing it working on a problem, with a solution.

Creating API demos are a must. Why?

• It will give the API an edge over the competition
• API demos are almost always mandatory at showcases
• Customers and Investors want to see the product in action
• Preps for technical failures and improvements

TIP: Use your demos as a way to validate upcoming features with customers — even if they are not perfect, it’s a quick and cheap way of gathering controlled feedback.

Lesson 6: Invest in Automation

Infrastructure-as-code is a great motto that’s often easier said than done, especially for a team of developers with minimal infrastructure operations experience. From the start, we knew that we wanted to use a configuration management tool (CM) to manage our infrastructure, but which tool? At the time there were an array of possibilities; Puppet, Chef, cfEngine, and Ansible. We decided Puppet met our needs, yet, due to its complexity and our lack of Puppet experience, we were only ever able to leverage Puppet to configure the servers themselves, whether they were at RackSpace or Amazon Web Services (AWS) and not provision the infrastructure itself.

Even though the servers were configured automatically, we had issues with our production and development environments not quite being the same. This resulted in bugs that were often hard to troubleshoot. Our software build and deploy process was still quite manual and error prone.

Despite being a relatively young company, we did find ourselves with some technical debt that was slowing our progress down. So, we made the decision to re-architect what we had built, leveraging the lessons we had learned from scaling out our first iteration of the platform, into what we feel is a sustainable Platform as a Service (PaaS). The technologies we chose this time around are centered around Docker containers using Kubernetes as the orchestration platform for managing those containers. Each microservice we build is developed, tested, and deployed in a Docker container and that container is the same container that runs on each developer’s laptop as well as in production. To configure the infrastructure we ditched our complex Puppet setup we had and chose to go with a much simpler combination of Terraform to provision the infrastructure and some Ansible scripts to configure the hosts and bootstrap Kubernetes.

With Docker and Kubernetes we were able to finally automate our software build process via Jenkins and go from a process that was fraught with anxiety and heartache to an automated pipeline that for the most part runs without a hitch. The developers can commit their code to Github and instantly Jenkins will see their change and start building a new Docker container for it and deploy it right into our development environment for testing. At each step of the way all members of the team can see what is going on through tight integration with our instant messaging platform, Slack.

TIP: If you have to do something more than once, it is worth investing the time to automate it now.

Lesson 7: APIs aren’t only for Developers

There’s a big misconception that only developers benefit from using an API. It’s true that a developer is needed to write code that makes the API work, but if you’re an API company selling to the market, your prospects are not limited to this group. In fact, most of the decision makers buying API services have likely never written a line of code in their lives.

APIs serve as a powerful communication tool between platforms and give businesses the ability to expand their offerings, make their services easier to use for their customers, and provide additional revenue streams. Smart business people recognize that these upsides are good for their bottom line and see an API as a solution, rather than as just a three-letter-acronym they don’t fully understand.

Recognizing that these decision makers are some of your biggest advocates can be a turning point for any API business. It certainly was for Kairos. The key is to talk to them in a way they can relate to. Technical jargon won’t fly with this audience. Compelling narratives, however, will.

In this case, ‘The API’ conversation becomes less about its technical features, and more about the benefits of the implementation; to solve big problems, increase sales, improve customer loyalty, and help your customer distance themselves from their competition.

This makes pricing an API tricky, yet it’s important to remember what your products are actually doing for the market and for your customers. What is the benefit that using your product can have on their business? What manual processes are you replacing? What new features are you allowing your customer to bring to market? How many new customers can they win based on your solution? These are important questions to answer when trying to decide how to monetize your product. It becomes about value, not cost.

APIs are highly flexible and you can easily track a customer’s usage. You don’t need a one-size fits all package. Some of the best models account for different phases of someone’s business plan. There is often a test, growth and major expansion phase, even within the maturest of companies. If you can adapt to their model and provide options that companies can grow into, you show your value as a partner for the long-haul. Short term sacrifices can equal long term gains.

Think about this in terms of your own product’s features, adding in premium capabilities for example, at higher price points when customers are ready, but still providing quality service at even the most basic or cost efficient level for those just getting started and vetting. Creating a menu of options for different size businesses and different phases of maturity show that you understand the business market and are willing to adapt. Of course, you don’t want to get too complicated in how you price, but accounting for your customer’s different business objectives allows your target customer base to expand exponentially.

TIP: Avoid jargon and deeply consider what is relevant to your customers.

Final Thoughts

Kairos is only just beginning, yet we’re humbled with how far we have come, what we have learned along the way and how it has set us up for future growth. No matter what stage you are in we hope that our tips will help your business grow as it did ours.