API Evangelist API Evangelist
API Learnings
Toolbox
API Evangelist LLC

Making Money With Your API Hustle

November 14, 2024 · Kin Lane
Making Money With Your API Hustle

I have strong opinions about how we all make money in this space. Opinions that clash pretty regularly with the status quo, but when you sit down to better understand them, they are much more sane, sustainable, and pragmatic than popular beliefs that exist out there today. For my own clarity, and maybe the one or two other folks who will read this, I wanted to share my beliefs about how we can all make money with our API hustles and not lose our soul, and if you are a bird with similar feathers, maybe we can fly together.

It is fine for people to make money doing API business, but I’ve been at enough rodeos to be able to see what contributes to a lot of the friction and frustration with API-powered technology transformation, and feel my beliefs help reduce this fraction in significant and meaningful ways. I enjoy the API hustle, and I enjoy working with others in the space, but I have been taken for a ride more than once, and have burned out at multiple points along the way, so I have crafted a short-list of principles I have when it comes to defining how I believe you should make money with your API hustle.

  • Best in Breed Services - You have to build your API hustle on the services that do what you need–I can’t operate without AWS, GitHub, and some other services, and I am happy to support commercial services that do things well.
  • Open Source Solutions - Open source tooling is a critical building block for your API hustle, and your cornerstones can be commercial, but most of your platform should be assembled using open source that you actively support.
  • Plans and Pricing - There should be entry level tiers, but don’t always have to be free in this hostile climate, but the ladders shouldn’t be too steep for me to climb as a small business, and shouldn’t pull up the ladders once I climb.
  • Contributing to Community -The commercial and open source solutions I use should give back to the community with useful and helpful content as well as specifications, templates, and other building blocks we can put to work.
  • Venture Capital - I am not 100% against the services and tools I depend on taking venture capital, but 90% of the time I’ve seen it happen, shit goes wrong, and you need to demonstrate that you are actually building a real business.
  • Practice What You Preach - Tools I use should have APIs—there are exceptions to this rule, but for the most part, you should always be practicing what you preach when selling your wares to the API space—this is how I scale and automate.

That is the heart of business as I see it for any API hustle. I don’t care what size of company you are—-we are all hustling. Some of us are just less or more honest about our hustle, and more or less honest about the work we do and value we deliver. While I am talking with other people hustling in the API space, these are the ones I am moving up to the top of my partner list. Not because I am taking money from them—I haven’t taken money from any of these companies (yet). It is because they reflect what the principles I have laid out.

  • Bump - Documentation, Changes, Discovery, and Specs
  • Tyk - Gateway, Portal, Analytics, Security, and Monetization
  • APIMATIC - SDKs, Portals, Governance, and Specs
  • Microcks - Mocking and Testing
  • SourceMeta - Schema, Registries, Validation
  • Bruno - Client, Collection, Testing, Automation
  • OpenAPI Doctor - Editor, Governance, Rules

There are other services and tooling I am talking to, but these are API hustles I have a relationship with and reflect the principles I have laid out above. I will keep evaluating other services and tooling I see making an impact on the space, but I needed to get a handle on what my principles are and what the first cohort of partners I’ll be letting advertise across my domains and be recommending as part of my stories and consulting. The solutions I listed above have other features and services, but these are the ones that interest me the most.

Now, it would be a crime to not mention the open source specifications I am going all in on as part of my operations. As I’ve said before, I am all in on HTTP APIs and Webhooks, with these specifications being the heart of my business operations.

  • OpenAPI - I will keep supporting from the outside-in.
  • JSON Schema - I will keep supporting from the outside-in.
  • Spectral - I will keep supporting from the outside-in.
  • APIs.json - My little open-source dictatorship for discovery.
  • API Commons - Where I overshare all the lego bricks.

As with services and tooling, there are other specifications, but this is the first cohort. I will be adding to it based upon work on the table. The point of my writing this post was to 1) Organize My Business Principles, 2) Organize commercial services and open source tooling, and 3) Organize the open source specifications. Work that will allow to better align across all three areas. I will be actively using all the services, tooling, and specs listed above in my storytelling and work. I will be actively using the list of principles above to evaluate new services, tooling, and specs to the list, and deciding when I deprecate and remove one from my list as well. I just needed to get it straight in my head.

I am looking to stabilize how I make money with my API hustle, while also helping others make money with their API hustle. It is what I have done for 15 years, and I am looking to continue for another 15-20 years. I am looking to continue investing in people building real businesses and supporting people who develop useful open source tools and specifications. I am looking to shield myself, partners, and my customers from other more nefarious forms of API hustles, and help keep me from burning out too badly again. I am just looking to use existing approaches to ethically building a business as I’ve experienced with Bump, Tyke, and APIMATIC, while still bringing on venture capital. As well as continue investing in open source specifications and tooling based upon what I’ve learned so far. Then rolling it all up into a partner network that hopefully can guide us all into the next decade sustainably.