Starting an API-First Company
What it takes to start an API-first company, from developing product vision to securing your first round of funding.
Join the DZone community and get the full member experience.Join For Free
You’ve developed an amazing API product. Fantastic. But that’s just the beginning of your journey. Starting an API-first company brings with it a whole host of unique challenges for you to face along the way. Based on my own experience of founding an API-first company, I've shared some insights below to help you avoid some of the pitfalls and make the most of the opportunities that lie before you.
“API-first” can mean different things to different people. However, for the purposes of this article, we’re referring to companies that publish APIs as their primary product and make money by selling their APIs to other businesses.
What Is Unique About Starting an API-First Company?
When you start an API-first company, you are selling your product to developers (B2D). This is one of the key differences between an API-first business and traditional enterprise businesses. You’re not a B2C company nor a B2B one – you occupy a unique position somewhere between the two which has its own set of challenges.
This means some of the traditional playbooks for lead generation and sales don’t always apply. You’re selling to an audience of developers who are, largely, known for being less responsive to traditional sales and marketing efforts. At the same time, the purchase of software is much more decentralized than before. Individual developers have tremendous autonomy when choosing which tools or APIs to leverage. More buying power is now dictated by the individual developers who discover and integrate your APIs.
This means your go-to-market (GTM) must be aligned to reaching and selling to developers. A popular playbook is to land developers first and get them to pay a token amount (such as $50/month). This requires having a robust content and inbound marketing strategy to pull in developers.
At the outset, you need to drive discovery and engage with developers on their own turf. Content is your friend in this respect, so it’s time to focus on positioning yourself as an authority in your particular subject area. You’ll need to demonstrate your expertise while speaking to developers in their own language, showing you understand their frustrations and supporting them to find genuine solutions – one of which is, ideally, your product!
Going in heavy-handed, recruiting a full sales team will likely yield poor results without mastering your self-service adoption and activation funnel. You need to make it easy and affordable for developers to try your product on their own terms and pace. Get that right and you can layer in sales at an appropriate stage later in your company’s growth.
Likely you started the company as an engineer-turned-founder, which likely makes you familiar with the problem/solution space. However, your experience is just one of many experiences. It’s important to perform proper customer discovery to understand each customer’s pain points and what gets them to adopt an API like yours. Different customers have different needs depending on size, industry, and technologies. While getting developers to initially jump on a call can be tricky, it can work if they start to see the value first (such as testing your API or reading a piece of valuable content). One of the best ways to get product feedback is by spending plenty of time getting to know your first few customers through support tickets and associated calls helping them get up and running.
It’s very valuable for the CEO/CoFounder to be handling initial support tickets while building an initial MVP rather than delegating. This is where some of your best customer discovery will come from, including outstanding insights into the specific ways in which customers are using your product and finding value in it. Connecting with your early adopters can therefore provide you with a wealth of information on use cases, pain points, and more. These insights will be invaluable when it comes to growing your fledgling business.
Learning About Sales
A startup founder has to learn a bit of everything along the way – about finance and legal, human resources and marketing, and sales. You may be an engineer, but you have to embrace a whole load of other business disciplines too, including sales.
Developer-first (or product-led growth) doesn’t mean zero sales headcount. You’ll still need to assist customers to get up and running and make them successful. The CEO/CoFounder should perform the initial sales calls as he or she will know the product and use cases best, at least until around ten customers are landed. Those early sales discussions will be super valuable to see first-hand what a potential customer’s issues or objections to adopting your API. A formal sales process is not necessarily required at this stage. However, you should be focused on creating a steady stream of qualified developers signing up and trying the API. We say qualified because it’s important to ensure your marketing strategy targets, developers, at organizations with the potential to buy.
The other thing to bear in mind when it comes to sales when you start an API-first company is how easy you need to make it for developers to trial your product. By providing a cheap introductory plan that a developer can stick on a credit card, you’re reducing the time for developers to get up and running with your API. Making it too complicated or too expensive can lengthen your sales process heavily as it will likely require approval from many stakeholders. For example, instead of a lengthy SaaS agreement that requires legal review, leverage click-through Terms of service. Instead of expensive POCs or pilots, leverage a trial that’s self-service so developers can get up and running at their own pace. This also means your sales process might not get engaged until a later point once they have shown intent and or tested your API.
One of the things that will likely be near the top of your To-Do List when you start an API-first company is finding funding. API-first companies can have good unit economics and not require a ton of startup capital, but you still need a structured approach like any sales process.
When looking to fundraise, start with your existing professional contacts. You’ll have a much easier time getting investment from those who already know you vs a complete stranger. Many professionals in tech like to angel invest, which is a good starting point before venture capital. An angel investor is someone who is investing their own money, but you must confirm they are accredited. Of course, startups are inherently risky. Never accept money from someone who could be heavily impacted by a complete loss. The best way to navigate angel investors is to have an informal coffee date. No deck, no formal pitch. Just talk about your problem/solution space and gauge if there is mutual interest.
Usually, angel investors can close after a single meeting or maybe a few follow-up emails. Once you decide to target venture capital, there is a slightly more involved diligence process depending on the stage. Angel (or pre-seed) money can help you hire a few key roles to build an initial MVP (minimal viable product)
Create a Product Vision
The final piece in the puzzle when it comes to starting your own API-led company is creating your product vision. Without one, you run the risk of building a whole heap of uncomplimentary features and ending up with a confusing solution.
The crawl, walk, then run approach can work well to formalize this. For example think about what you can do first, such as a single API with one function. After that, you can think about additional features that could turn it into a larger product in the medium term. Finally, how do you turn your product into a larger platform that wins customers and the market? This approach means you can move logically from having a single API to adding complimentary APIs and features that create more value around your platform. A clear vision and plan will help you get there smoothly.
In addition, ensure your company has a mission statement which encompasses your vision. This can be helpful to ensure your product and marketing roadmap aligns with that vision. While a company’s mission can change over time, it should be well understood by the company at any given time. As you propose new product features, ask yourself: does this align with our company’s vision? In addition, look into which features are missing that prevent you from achieving that vision.
Build and Iterate on Product
If there are multiple players in your space, it can be easy to get caught up with "the competition" and become overly secretive with your idea. The worst you can do is build an entire API platform in stealth without any validation from customers. The great thing about API-first businesses is that APIs are like Lego building blocks. Instead of building and releasing all functionality at once, get a minimal viable product/minimal viable platform (MVP) in the hands of customers which could be just a small set of APIs. You can add additional APIs later which could expand functionality. It’s surprisingly hard for another company to completely change its product strategy and replicate your entire vision. It’s better to embrace the competition and see what kind of innovative partnerships you can create instead.
Remember, too, that many tech founders like to blog. This means you can keep up not just with the tech developments of the other players in your sector but also with whatever they care to share in terms of the operational and cultural development of their businesses. When you’re in the early stages of your own startup, some of those insights could be particularly helpful.
Rapid Decision Making
When you start your API-first company, you’ll have a whole heap of decisions to make. Sorting these decisions into groups based on their outsized impact can help to focus on how much time you allocate to making those decisions.
For example, should you spend more time planning your backend architecture or your product messaging? Changes to the former could be hard to implement and have a large scope, while changes to the latter can be rolled out quite quickly. Thinking about the implications of the decision is a great guide to how much of your attention that decision warrants.
Starting an API-first company is a learning experience every step of the way. If you’re after further inspiration, this podcast on How to Build an API-First Company with Nick Patrick, CEO of Radar, is a great place to start.
Published at DZone with permission of Derric Gilling. See the original article here.
Opinions expressed by DZone contributors are their own.