Usage-Based or Subscription-Based Billing for your APIs? feat. Behailu Tekletsadik of Archetype

Show Notes

While the subscription-based pricing option has been the popular go-to for many SaaS companies, the usage-based model has recently seen significant traction in SaaS companies. But which solution is right for monetizing your API product?

To answer that question, this week on the API Intersection podcast, we spoke with Behailu Tekletsadik, co-founder & CEO of Archetype, which is a startup focused on usage-based billing for APIs. Behailu sat down with the API Intersection team to discuss the pros and cons of a usage-based approach versus a subscription-based approach to your API pricing strategy.

_____
To subscribe to the podcast, visit https://stoplight.io/podcast

--- API Intersection Podcast listeners are invited to sign up for Stoplight and save up to $650! Use code INTERSECTION10 to get 10% off a new subscription to Stoplight Platform Starter or Pro.

Offer good for annual or monthly payment option for first-time subscribers. 10% off an annual plan ($650 savings for Pro and $94.80 for Starter) or 10% off your first month ($9.99 for Starter and $39 for Pro).

What is API Intersection?

Building a successful API requires more than just coding.

It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.

In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.

Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.

They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.

They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.

Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.

API Intersection
Podcast listeners are invited to sign up

for Stoplight and save up to $650.

Use the code INTERSECTION10 to get 10% off
a new subscription to Stoplight Platform

Starter or Pro.

Take a look at this episode's description
for more details.

I'm Jason Harmon
and this is API Intersection

where you'll get insights from experienced
API practitioners to learn best

practices on things
like API design, governance,

identity, versioning and more.

Welcome back to API Intersection.

So over the last year and a half
or whatever we've done this thing,

on numerous occasions I've probably said,
and in fact I may have here,

I'm not sure even used the word vampires
to describe usage-based billing.

So I'm just going to say
now ahead of introducing our guest

that this is going to be a

different look at
when does that actually make sense,

which is to say that I do believe
that usage based

billing is okay sometimes,
but it'll be fun.

And so I want to introduce Bahailu
Tekletsadik.

And yes,
I practiced and yes, I'm proud of it.

And did I say that, right?

Yes, you did.

Hi everyone.

So he's coming to us from Archetype.gov.

New startup kind of spinning

up, focused on usage-based
billing in APIs, but you tell me

more like tell us a little bit
about what y’all are doing.

Yeah, sure.

So essentially
what we're doing at Archetype

is we're building a solution
for API first company to essentially

enable them to monetize their APIs
and essentially manage out

like a lot of this infrastructure
that it requires, right?

So when it comes to building a flexible
pricing model for each of their enterprise

customers to assigning permissions roles

to managing their API keys authentication

to rate limits
for each of their endpoints,

we totally end up in addition
to basically like,

you know, managing the accounting
and invoicing that comes with like,

you know, managing
and tracking all the usage records.

We sort of like own all of that end end

so companies can really focus
on building their core product.

NIC or value prop,

We tend to find that a lot of companies
are very distracted by building this.

And when it comes to like

sort of like offering different custom
plans, thinking about experimentation

and actually trying to figure out
what to charge their customers

in the long run, it ends up being like
a huge nightmare for these companies.

So we just want to make that
less of a pain point,

which, by the way, I want to add, that's
why I generally tell people

this kind of advice of like
you probably don't want to do that

because it's always freaking hard.

So I am like kind of just at the
the value prop

you guys have on trying to solve this.

I think traditionally
this has been the thing

that, like the API gateway companies
have kind of tapped into.

So does that play a role
in what you guys are doing?

So that's actually kind of interesting.

So what we do is we actually interface
directly with people's backend.

So if you wanted to build an API gateway
on top of what we've done,

we sort of like allow you to do that
so you can build it at scale.

We didn't want to tie people to like,
you know, different API gateway services.

And I've talked to some people
that worked at these API Gateway.

A lot of them tap into it, but
they haven't really made it a core focus

because I think like

it's such a different problem versus
what they're doing with the gateways.

Yeah, I mean, you're
taking on a lot of inherent complexity,

latency,
all those things with, with gateways.

And I think increasingly
with like Kubernetes based infrastructure

and things like Envoy, right.

Like a lot of the traditional gateways
aren't

really playing a role
in some of the more modern infrastructure.

So I think that's smart.

Another fun bit here in the show notes,
I noticed

you had worked before on a
or currently still theoretically

working based on your LinkedIn profile
on a Lantern, an iOS app,

but I'd love to hear
you share the story here on like,

how did you go from Lantern to now
working on API building stuff?

Sure.
So that's kind of an interesting story.

So my co-founder
and I, we started Lantern in 2020

because we basically saw an opportunity
in the market around options trading

and we saw that, hey, you know,
a lot of retail investors out there

didn't really get access to option
market insight ourselves.

We lost a ton of money,
you know, trading options.

We figured, you know,
this is a huge pain point.

So we did that for about a year
through an iOS app providing insight,

you know, doing some really cool stuff,

working with a lot of the,
you know, big exchanges and whatnot.

But like about a year.

And we quickly realized
there was a lot of value in the data

that we were sourcing

because we were getting like a lot of

the market data in real time,
pretty much every transaction.

And people found
that really, really valuable.

So we tried to spin up an API and ended up

taking us two months to sort of like
just take what we had

like in our existing infrastructure
and launch it like in a monetizable way.

And a lot of that pain came from the fact
that we had no idea how to actually

build this.

Think about like, you know, entitlements.

Think about, you know,

how do we charge each of our enterprise
customers like, you know, a different

plan, a
different amount for each different plan?

How do you think about,
like creating a self-serve model?

Managing people's API keys,
letting people reset their API key.

It was actually a very generalizable
problem and we had no idea how to.

It took us a long time to sort of like

build this out
just from like a roster, right?

And we quickly realized, you know,
there is a huge pain point,

huge opportunity here
when talk to like other fintech API.

A lot of them
went through the same problem that we did.

So in September,
we sort of like started talking

to a bunch of companies about like total.

At any point that we encountered,
there was a lot of overlap.

And then in December
we started working on it.

We saw a lot of opportunity,
got a lot of blue eyes.

So working on it
like more aggressively in February,

Clojure around there and they realized,
you know archetype is definitely

the way to go like huge, much, much bigger
opportunity here.

And and with regard to the latter
and we were thinking about it

getting it applied as if to

because people had been trying
to acquire stuff very, very long time.

So we figured that now was the right time.

I mean, if you look at the markets right
now, it's probably fortunate

that we sort of like decided to take
a stab at this earlier rather than later.

I love it, man.

I love the rollercoaster origin stories of

of bright ideas and startups.

You know, I think of like

Kong starting as mashup shape
and then figuring out,

you know, their whole open source API
gateway thing was kind of the future

and selling off the mashup
side of the business.

Rebuild.

We originally focused on billing,
ended up, you know, focusing more

on the developer portal and documentation
aspect and launching really.

So it's funny
how often in kind of this API space,

you know, we're all trying to figure out
how to make these problems more efficient

in building some other product and
you end up building an API centric thing.

But I'll just say I love those stories
because they're solving selfish problems,

which sounds bad, but like that's
what drives people to actually get stuff

that makes sense, right?

Because you've actually felt the pain.

So I love that.

Yeah, I agree.

I feel like there's a lot of context lost
when you build products or solutions

for people.

The problem that other people have, right,
for a problem that you have,

you should have like will understand
intimately what your problem is.

You just sort of
have to contextualize it into what is a

you problem and what is like a problem
with like that existing market, right.

That makes sense.

So I guess back to

our frames point of contention
here in some ways, which is, you know,

so my perspective is always like,

especially with a lot of SAS
based products these days, it's like

if you're charging on some value point
and then you want to have

the ability to integrate,
it's like don't, don't

create a barrier to adopt the API
by pricing it.

That said, like
there is a whole other category of things

that are a little more commoditized

in their nature
that are innately price of the usage.

Like, I'd love to hear your thoughts on,

you know, for listeners kind of
what's the right way to think about

when this is an appropriate
sort of pricing strategy for APIs?

I mean, that's an interesting point.

I would say like there are two theaters of
thought here to go to thought here

with subscription based models, like
essentially you have a flat rate pricing.

So the

customer is

from one end who barely use
your product, are paying the same amount

as customers who love your product
and use it super regularly.

And I think the idea behind usage
based pricing is the idea that you want

to charge people for the value
that they get from your product

and in as like as close to
that as you can right.

And with that, like it's

obviously going to be like very specific
to the sort of products that you have.

Right.

So let's say you have

I feel like a good example is, let's say
an empty NFT minting API, right?

Let's say you could charge people
a subscription for minting,

you know, let's say 150,
but what if you just wanted to charge

people, let's say a dollar
for every minute that you do

like, let's say that that's a lot
more palatable, I think, to people

because how many And if you do,
they're going to mint like every month.

And I think that's going
to drive a lot more adoption.

There's also some stuff, too, like
I know they're the big industry,

you know, for KYC APIs, like, you know,
checker, for example, where essentially

they charge per usage on top of like,
let's say a base commitment.

And for listeners,

KYC being no, your customer
sort of like identity type stuff, right?

Yeah, exactly right.

Identity verification is very, very hard.

There's a lot of companies that get any
pass, which is a fellow, not Porco,

where they also charge for
you should write like it's really

it really depends right
you're not going to charge

very usage amount
for like let's say Netflix right.

I always use Netflix
as a good example for like,

you know, you should base even though it's
not like the most appropriate model

but it hopefully that
contextualizes a little bit.

Yeah I think so.

I mean I think it's like
if you can clearly see

that like value
per call isn't quantifiable

and that there isn't some existing
subscription model

in place already

and then it makes sense.

And I mean to some extent,
if you're going to launch a product

that is only an API,
well yeah, you got to have something.

Yeah, I guess that's
my other curiosity here is like,

and I know you're still very early in
and in some ways,

you know, by the time

this air's really kind of starting
to open the doors a bit, but

in terms of kind of early discussions
and learning, you know, how many,

how much do you think that like API only
kind of products versus, you know, folks

trying to be API first and adding an API
into an existing product?

Like how do you see guys
fitting in between those worlds?

I think we can fit into both worlds
fairly easily

on API first companies, the

companies that are launching

API are going to find this sort of
like more easier to integrate,

I think because we can that
we can be with them from the very start.

Companies that already have an existing
infrastructure in place

and they have a clear and present pain
point, let's say, with like, you know,

doing their accounting or like,
you know, tax reconciliation

or like manually operations like,
you know, doing something automatically

through archetype or companies
that sort of like want to build

in, you know, their own
like permission system

like and they have
something baked in already

and they just want to switch over
to something that's easier

or like more performing that would be
a bit a little bit more difficult.

But I think the pain point is so big there

that they're much more willing
to integrate a solution like archetype.

That's sort of how I see it.

And there is definitely like a couple of
like, you know, buyer personas.

I think that we can like fit into fairly
well across both groups.

But, you know, both of us coming
from a software engineering background,

although you've touched code
a lot more recently than me, I'm sure.

But you know, putting my product
hat on here,

I'd love that you guys are talking about

figuring out like willingness
to pay kind of stuff,

like experimentation,
you know, is that something that you're,

you're leveraging some other existing
experimentation platform?

Are you, you know, like,
I don't know, it's

a weird one for me to think about
with kind of API stuff.

And is this just more about kind of,
you know, what you're showing

on the pricing page
and correlating it to API tokens?

Or how do you see that working?

So this one is it's
less of a platform tool

that we can use and more of
like a benefit of using archetypes.

We're fairly

like we're still fairly early on in
sort of like that school of thought.

But essentially the idea behind it is
you can charge,

like let's say like
I have a general model, like AHIP for $10

an API call for something

and see they use it
like how many, how much revenue

did you just generate in the last month

and then spin up a new pricing model
like the next month

and then you see
how much people are willing to pay.

They're like,
you know, all else being equal.

And then from there
you can do some comparison.

And we sort of like allow the flexi line
user to have the flexible fee to do that.

I think obviously there's
a lot that you can be that can be done,

I think to make this like more intelligent
and built in like smarter

insights around that and that sort of like
what my co-founder is going to be doing

because he has a data science
background here.

And then so, I mean,
as you look at what you guys have learned

in researching this space,
you know, leading up to kind of launching,

you know, what do you kind of see
as sort of, you know, best practices

around, you know, API billing?

You know, obviously was usage based, but
there's certainly other models out there.

And are there

kind of existing models out there
that folks could sort of look to emulate

when they're thinking about their pricing
and packaging strategy on APIs?

Mm hmm. Yeah,
there's some interesting stuff.

I think like a lot of thing
that we've seen, if people want to

offer volume based discounts,
if they're doing usage based pricing.

So and I think there's a lot of system
where they can't really do that right now.

We thought that was kind of interesting.

I think if you are doing usage
based pricing, definitely think about

like whether doing volume based discounts
makes sense to your customers.

And then there's some also
some other things around.

Can you offer like can you charge
a commitment, right, like a minimum

after that usage?

And then like let's say your usage fee
for the first 10,000 API calls

and then like, you know, $0.10
for the next like a hundred thousand

and then a coffee volume basis
come from there.

There's a lot of

there's a lot of ways that you can sort of
like think about pricing as well.

And I would also when you're thinking
about it in the context of API,

just take a look at like,
what are you users doing?

Are there API
that people are finding much more valuable

or endpoints
that people are finding much more valuable

or certain sections of their data, like,
you know,

certain deals that they're searching for
that tend to be more commonly searched

and think about like
whether it's going to be taxing on you.

Is that more valuable?
Can you charge more for that?

I think there's a lot of

things that people can do
to like optimize their revenue here.

And then when it comes to subscription

based, like obviously they're it's
going to be like it's going to be

I think I feel like
a lot more straightforward as well.

But again, it's just like really thinking
about like what how much can you charge

and how much value are they going
to get iconic.

I love that

that concept that you touched on that
it's like how taxing

is this going to be for you?

I feel like it's for me.

It's always an easy way
to justify the value of something in API

terms is like, sure,
you know, we can provide this,

but it's going to cost us a lot of system
resources.

It's going to be hard to scale
and thereby it's expensive

versus something
that's maybe a very solved problem,

very optimized,
should be relatively cheap, right?

Because it's so commoditized, there's

so many options out there, it's
so competitive

and that, you know,

you could probably find
something open source and do it yourself.

But I think sometimes
that like complexity, cost

isn't always part of the equation
and how folks think about pricing.

Yeah, Yeah.

It especially matters
if you're thinking about something

that's like Rangatahi story,
like let's say scanning people's,

you know, IDs or their passports
or something like going back to the KYC

example like that
can be some fairly expensive computations.

You know,
you probably have some sort of like,

you know, computer vision going on as well
or like you're probably using

some sort of like resource of Google
or something to do that.

On top of that, like you have to like scan
or work with the government to do that.

They probably charge you a lot.

So they
did a lot of stuff that goes with that.

And that's how like
you have to think about pricing as well.

I guess the other thing that comes to mind

when I think about this subject is like

those of us
who've been in apps for a while,

all have had that client who accidentally
pushed an infinite loop to production

on a Friday night, you know, just goes
banging away at the API and you're

digging around on LinkedIn
trying to find them.

And what did you do, man?

Like you're calling it's a million times
a minute,

which I would think from a billion
pricing standpoint,

you want to like, somehow alert
somebody that this is happening, right?

So I'd imagine that sort of these
anomaly detections would be important.

Yep, they are.

There's something that people
have given us some feedback about.

Like there's also the idea of that,
you know, using a soft cap and a hard cap

like, let's say soft cap,
you get given alert to a certain,

you know, customer that they've reached,
let's say 80 or 90% of their threshold

and then a hard cap.

Let's say they go and gotten like,
let's say 110 or 120%.

I think you should just like cap it there

just so they don't,
like, blow their entire budget.

And if it was like a mistake,
you can go back and reconcile it, be like,

okay, like clearly you guys did not intend
to do this or something like that.

There is also a lot yeah,
there's a lot of stuff that you can do.

You can tie web hooks
just like have some slack related.

Well, when you know, as a vendor
just saying, hey, this one customer

using this API like a million times
when they're only like meant to use it

like a thousand times, for example.

Yeah, it's,

I don't know.

It'd be nice if,

if everybody had some sort of

perform it's baseline testing
when changes get pushed.

But you know, if you've been around
software engineering long enough,

you know, there's rarely
do you build those things.

So you know, stuff happens.

Well,

you know, it's funny,
we end up on the show here

with a lot of folks that come from

really well-established programs
that everybody knows about.

But, you know,

I've spent a good chunk of my career
in startups, and I always have

a heart for folks that are, you know,
trying to figure it out and come up.

So now you guys are right on

the cusp of kind of launching here in kind
of, you know, prime time.

So any sort of call outs to listeners here
on, you know, kind of

where all that's going here
in the month of September 2022.

Yeah,
I would say if you guys are interested

in thinking about you should bake billing
or flexible pricing models

and you're sort of like struggling
with that or like automatic stack

tax reconciliation or anything like that,
feel free to give us a shout out.

We're happy to give demos, give people
walkthroughs and get people on board

using that product.

Yeah,

cool.

Any other closing thoughts?

Were words of wisdom on the subject here?

Hmm, that's a good one. I would say

one thing

is obviously use as base
billing is not right for everyone

and you have to be very careful
about how you think about it

and you don't want to sort of like
just jump into a new pricing model before

before you're even ready
or before you've done your research into

whether it makes sense.

And one of the big things
that we're trying to do at Archetype Age,

we give people the flexibility to do that.

Even if you just want to charge
a subscription or just like a user

based model.

There's also it's really this
like a flexible pricing model

that we can sort of like let customers
use it for.

Yeah, it's cool.

I think I think of it and I don't I'm
like actively thinking here,

all we're talking about,

you know, it's like quite often
the challenge is how do you get adoption

on an API?

And sometimes folks

try to put monetization in front of that
and don't balance those concerns.

And it's like depending
on what you're doing, making sure that

even introducing usage based pricing
could be such a barrier to adoption

that it's just not a good idea at all,
but that,

you know,
if you don't have any other monetization

lever for the functionality that you're
providing or, you know, obviously.

So I don't know, it's an intriguing one.

And certainly my call out to listeners
here is like,

I'd love to hear more about your thoughts
or kind of, you know, is there

good guidance out there on this stuff?

I feel like it's a subject
everyone grapples with and there's nothing

great to go to like read up on,
but maybe I just don't know where to look.

Yeah,

I mean,

we have a couple of blog posts on our site
where we talk a little bit about this.

I would say
when it comes to getting adoption,

I would say regardless of whether
it's subscription or you should base,

you have like a couple avenues
here, right?

With this encryption,
you can have like, let's say, you know, a

seven day free trial or like,
you know, you know, 14 day free trial.

And with you said you could also go
the freemium route where like you have,

let's say the first thousand API calls
are free to go beyond that.

You sort of like
just have to enter your credit card

and then just like add more details.
Right?

There's a lot of flexibility here.

And I've seen some companies
that don't even think about monetization.

They're just like, we're in public beta,
we're capping everyone out like a thousand

API calls or something a month,
and we just want to get adoption,

see whether people even like the product
before we introduce monetization, right?

Because they want to make sure
that people actually like the product

before they even think about building
the billing infrastructure.

And I think with that solution
somewhere like R-type or whoever else

you go with, if you introduce that early,
you can just like

pull that monetization lever
like immediately and introduce freemium.

And just like if people are driving
value from your product,

they'll be much more willing to pay

in the like and much faster.

Yeah, awesome point span.

Well,
thanks so much for coming on the show.

And I just want to say like, you know,
I'd love to hear back from you in a year

or so and see how all this
how all this plays out.

Thank you so much.

We really appreciate the time.

Jason.

Thanks for listening.

If you have a question you want to ask,
look in the description of whichever

platform you're viewing or listening on
and there should be a link there

so you can go submit a question

and we'll do our best
to find out the right answer for you.