22
33 Comments

The API Business

I've been thinking recently about API businesses. This movement seems to have started with some companies many Indie Hackers will know well, such as Stripe & Twilio. I'm seeing it more and more:

I wanted to understand what makes these markets suitable for APIs as a business. Thinking out loud here...

  1. There seems to be a bias towards finance/fintech
  2. The underlying supplier seems large, slow, complicated incumbents (banks, airlines, etc)
  3. Some of these are regulated industries

Any other things you noticed about these API companies? What makes them good businesses? Has anyone else seen any other interesting API businesses?

  1. 27

    My 2 cents here,
    As a CTO, my job is to iterate as fast as possible. Usually, when interviewed for a position, I'm asked the "build or buy" question. My answer is insanely fanatic - anything that's not the IP of the company + is easy to buy = buy. Anything that's the IP of the company but can get you faster to market without hurting you downstream = buy. In other words - I lean towards the buy side and need a strong conviction to move towards the build side.
    As an example, I was the CTO of a telehealth company - we needed backend dashboards with complex charts - the answer was simple, are we a company that specializes in online charts? Definitely not, so we bought an expensive solution, which cost the equivalent of one hour of developer salary a month. It saved us money, a TON of time to deploy and more importantly - these companies know their shit - they have solved problems you haven't realized you'll have if you build it yourself.
    This long prologue was to say a very simple thing - find a pain, something that a LOT of businesses NEED, but it's not their business. If you find such a pain, you can easily charge $10-$500 a month.
    The best routes are high paying X high volume markets X easy onboarding for devs. This is of course elusive. But starting small - solving a VERY small problem and then growing it vertically is a VERY valid plan as well ( see Segment https://thisweekinstartups.com/e935-segment-co-founder-ceo-peter-reinhardt-shares-insights-from-pioneering-customer-data-infrastructure-cdi-to-unseat-crm-lessons-from-first-failed-product-launch-critical-pivots-the-importa/)
    Cheers,
    Jonathan

    1. 4

      And a well thought out API would let you iterate very quickly indeed by de-coupling core business logic from the ever-changing edge business considerations. Well said, but I think you missed this part at the end! - Pavin.

      1. 3

        Amazing addition, thanks!
        I always tell my devs - the code has to be written in our product language - never ever should I see the name of the solution in the code, for example:
        If we're using Stripe for billing then the code should be all about our language of billing using a separate internal billing service that uses the Stripe API.
        That way if we switch from Stripe to a different vendor - one file changes (our internal billing service) and the rest of our code works flawlessly.
        Thanks for bringing that up!
        Cheers
        Jonathan

    2. 2

      This is useful, thanks Jonathan. In terms of specific industries then, that makes for a good target for building an API replacement, I suppose a good marker is one that
      a) has the ability to slow a team down should they try to build themselves (complex)
      b) is outside of their core focus

      1. 1

        I agree completely, and maybe elaborate:
        a) Everything a team has to build slows them down (except for things which are a few hours work - very rare)
        b) 99% of what you do in a product is outside the core focus ( OK, OK, maybe I'm exaggerating but definitely more than 50%)

        PS If you'd like to have a quick 30-min meeting and dive deeper, feel free to book me (free of course) https://calendly.com/jonathanoron

    3. 2

      I found this very insightful. Thanks for posting it! What I liked the most was 'start with a small problem and then grow it' and your synopsis about 'finding a problem a lot of people have.'

      1. 1

        Cheers and thanks!
        Curious what CRUU is, couldn't find a post or link on your profile about it.

        1. 1

          Our website is cruu.io. Sorry I didn't have a link up yet. We are still pre-launch! We've built the world's first interface builder for React so React engineers don't have to code CSS and HTML by hand anymore. But obviously we have yet to build Cruu's first 'elevator pitch' ha ha. Still working on trying to figure out a pithy way to explain what we do alas. Thank you for asking about Cruu!

          1. 1

            Very cool!
            My wife keeps asking me why Figma -> Code takes so long.
            I actually thought about this avenue one day when trying to get divs to align... LoL
            I'd love to hear more and hopefully give you some helpful advice: book me - https://calendly.com/jonathanoron

            1. 2

              Thank you! We are setting up a time now. Thanks!

              1. 1

                Very cool!
                See you soon... :)

  2. 5

    I'm also running an API business (bite.ai), here are a few things to consider:

    1. If the buyer is not the developer it can take a really long time from the day someone purchases your product to the day they start using it. If you price based on usage you can end up with deals that take 6-12 months to start generating revenue.

    2. Most of your revenue will probably end up coming from large customers, so you'll have to spend a lot of time doing sales.

    3. Indie developers and early stage startups will try your stuff but will fail more often than not. The ones who stick around are usually on a tight budget and won't have a lot of usage so they're unlikely to pay a meaningful amount for your product.

    4. If you're focused on a niche, ship an API ASAP, then build your own UI on top of it so customers can use it and test it out without having to integrate it. This will make it easier for SMBs to start using it.

    5. If your API is not hard to implement customers will start with your product then try to rip it out and replace it the second it gets expensive.

    1. 1

      Hello, it's a bit offtopic, but how do you do billing for your API? What software are you using? I'm running my own niche API and need to do a per-request billing with every-day reports for a clients, can you recommend anything?

  3. 4

    Hi,

    I'll add newsapi.org to your list, I used it recently for MVP, where I needed news feed.
    So the idea is that at some point I would stop using it and parse news by myself, but for MVP it was great.

    More options:

    Same thing here used them for MVP, just to speed up development.

    Another one:

    Same thing, to speed up development and test MVP as fast as possible.

    And the last one:

    Used it in lots of projects, building this by myself would be just too hard and time-consuming, so it's easier to use these guys.

    So as you can see, mostly it's saving time and dev resources. I used these services as an employee of startups plus by myself with side projects.

    Let me know if you have any questions...

    1. 1

      Hi! I'm the founder of CometChat. Thank you for mentioning us @antonkrasov. I am happy to answer any questions about CometChat or API businesses in general.

    2. 1

      Some nice examples here, thanks.

    3. 1

      I've used mux.com before and I love it! Great product and I agree, building what they have done would be very difficult. So much easier to just plug into their API.

  4. 3

    Thought I'd chime in as I run an API-based business - bannerbear.com

    Another few examples for you:

    Interesting that you see a bias towards fintech. I don't see things that way - although I'm sure there's some selection bias at play here.

    Personally I see the API business through a developer productivity lens. The companies I find most interesting / most useful are the ones that make life easier for me as a developer.

    There's opportunities for this everywhere, I think. Take some complex (or mundane) functionality that nobody wants to build / maintain in-house, and abstract it into a product that developers can integrate quickly.

    I launched my API service about 3 weeks ago. I'm yet to make it a roaring success, but I'm really excited about it and I'm quite bullish on API services being a good area for indie hackers to explore.

    1. 1

      Thanks, Jon. My next question was going to be whether this was a suitable vertical for Indie Makers, which you've pre-empted. I'm interested to explore this space too and I'm trying to get a sense of the markers that lead to success. Did you have other API ideas before settling on Banner Bear? Anything specific that made Banner Bear the one to go with?

      1. 2

        I didn't have other API ideas, but I knew several months ago that APIs were a product type I wanted to explore.

        When Bannerbear first launched it wasn't an API, it was sort of a typical CRUD-based application that produced images. It was only after I kept getting requests for tweaks and changes from users / customers to suit their particular use cases, that I realised the whole thing would be much better off as an API product - and then things sort of clicked.

        But whether it's the "old" or "new (API)" Bannerbear, the problem I want to solve is the same at a macro-level. It's about helping people to do creative work at scale or significantly easier. That's a problem space I've been interested in for a while.

        So for me, I began with the space I found interesting, had in the back of my mind I wanted to create an API, launched a conventional MVP product or two, and then pivoted to an API once I had feedback/clarity on what that would actually look like.

        Again, I'm not a "success story" as my API is only 3 weeks old, but I'm liking where things are heading so far.

  5. 2

    I was the PM owning the API business for two successful SaaS companies, Moz and Avalara.

    I originally joined because I like how machine-to-machine communication can extend positive impacts. For Moz, it was letting others build interfaces and tools we wouldn't build, and increasing distribution of our metrics for branding purposes. For Avalara, it was the way people connected to the service, but the host system was what customers considered "the product". A few things I've realized in my time thinking about this:

    1. APIs that provide info about you, specifically, have a 10x - 100x higher value than bulk data APIs
    2. APIs need to have great DX (Developer Experience). Not just docs, but user-first experiences from the standpoint of the developer.
    3. They need to solve a real business problem, just like any other product. For Avalara it was something like "automatically calculate the right sales tax rate for any product or sale."

    One opportunity I see is in pricing. API 1.0 products like those above are generally usage-based to protect resources. With resource prices dropping, it enables new pricing models. This could allow new entrants to compete with existing API businesses.

  6. 2

    We just launched an API-first hosted email platform last week at Mailcheap. Here's the documentation. We used to provide (still do) dedicated email servers without any user/domain limits for businesses (at first) and resellers (later on), so an API became more and more important to mold the product to each business's requirements - Pavin.

  7. 1

    My thoughts on the trend of successful API companies:

    We've seen an uptick in entrepreneurship as a whole lately. A lot of that is increased access to resources online, communities like IH and ProductHunt popping up, and a whole lot more developers, designers, and product people who are able to build cool things. APIs speed up development, which is a huge value add for this new wave of entrepreneurs, but what's more significant is that APIs scale with entrepreneurs' success. APIs help entrepreneurs succeed by speeding up dev, lowering cost of entry, etc. They in turn earn more and more profit as the entrepreneurs they support are also seeing success. That scales up infinitely, causing huge companies to continue to rely on APIs like Stripe even when they've grown massive. It's a back and forth paradigm, which is great for entrepreneurs/hackers and the API companies alike.

  8. 1

    API's also offer a way to white-label a solution.

    For example, the Tipalink API (https://www.tipalink.com/docs/api) offers other apps and websites the opportunity to add tipping/donations/ordering/paywall features to their own projects in a way where they control the front-end UI/UX (without employing the Tipalink Plugin and branding).

    And it's not just for fintech or big businesses. Holiday API is a cool example of a dev who created their own API product: https://holidayapi.com/.

  9. 1

    I usually try not to depend on someone else, but if it solves a painful enough problem and has a reputable company behind I am on board. Think Mailgun.

  10. 1

    https://saasify.sh is the easiest way to launch your own SaaS API. 💯

    1. 1

      Saw this - nice idea!

  11. 1

    This is a very interesting space. I have been thinking of things like gathering data sets such as currencies, banks etc in one API. The business model is attractive since I guess most customers will be big enough to use this at a larger scale. If you charge for usage this could mean $$$.

    I think https://rapidapi.com/ has nailed their model as well by acting as an API marketplace.

    1. 1

      Yep, generating your own dataset is an extension that I see as well.

  12. 0

    Don't forget geolocation API businesses like https://ipapi.co/ and all their clones

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 17 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments