Mike Bifulco: Hi friends, and welcome back to APIs you won't hate.
My name is Mike Biko.
I'm one of the co-founders of APIs you won't hate.
And of course, podcast co-host and occasional friend of Phil's.
We get to catch up and talk about API stuff when I can find
him wherever he is in the world.
But today I'm excited to sit down and chat with a new friend of mine.
I'm here talking to Alan Kaba about what he's building with API bull.
And really excited to hear your story.
Alan, thanks so much for joining today.
How are you?
Allan Knabe: Hi, Mike.
I'm doing very well.
Thank you.
Thanks for having me on the show.
First of all.
Mike Bifulco: Of course.
Yeah.
It's a pleasure to have you here.
I would love to to to hear a little bit about you to start.
Gimme your, the history of how you got to what you're building today,
and then I want to hear all about API
Allan Knabe: Okay, cool.
Yeah, I'll skip the early years 'cause I don't think they'll interest anyone, but
Mike Bifulco: Sure.
Allan Knabe: I, I guess, you know, the, the origin is like starting at university
saying information systems, which is code word for not very good at programming.
I think, you know, everyone else were, you know, software engineers, but I
would write code that was like one page long or something like this, and then
a real software engineer would come along and say, okay, you know, I could
write that same thing in one line.
Right.
And, kind of like the, the, the penny click that I needed to
be a little bit more diverse.
So information systems where, where I, I kicked it off
with my, my computing career.
And yeah.
From there I, I kind of started off with an Oracle consulting company in
Birmingham, which is, you know, basically where I'm from in Birmingham, uk.
And great Years had some like really good fun in like these, like very
small teams of like 10 people.
It's where I really love to, to be, you know, where everyone's working hard and
you can see like what you're achieving.
So good fun there.
But ultimately I left for a bigger company, Fujitsu computers.
Mainly kind of.
Backend development type tasks and Oracle databases and all this kind of
stuff that were, you know, popular in the early two thousands before moving
on to being a Siebel consultant.
So, I dunno if anyone still knows what Siebel is, but Siebel CRM was
really big in the two thousands.
And
Mike Bifulco: Sure.
Yeah.
Allan Knabe: yeah, I, I, I think I.
Mike Bifulco: while since I've heard that word.
Yeah.
Allan Knabe: Yeah.
Yeah.
Siebel, it was massive.
Right?
And then Oracle bought them and kind of, they disappeared a little bit, but
there are still some projects out there.
But I kind of, I san about 10 years of my life into Siebel,
I'll never get back somehow.
Right.
It's, it's, I don't know for people who don't know where it is, it's,
it's basically before you had Salesforce, you had Siebel and.
Instead of programming, they gave you like this tools console, which
basically just toggle switches and you toggle them on and off.
Right?
And it would just, you know, activate feature toggles in code
that you could never see, right?
So like this black box and you had no real idea what was going on.
And sometimes you would just kill performance, right?
Because you were doing some sort of outer join in behind the scenes.
So not nice stuff if we're being honest.
So my API story kind of started when I, when I left Germany.
So I was in Munich for 10 years.
And I went to Swisscom in Switzerland.
So Swisscom is like at and t basically, but in Switzerland.
And joined the API team.
So I, I moved across to, to doing APIs and, well, it was
a world of difference, right?
The, the API team, you know, was really young, fresh, cool thing to be doing.
You know, we were having like hackathons and it was really about that genesis about
10 years ago on now of like when the, the API started to really come onto the scene.
It was a really, really cool time to be working in APIs.
Really
Mike Bifulco: Yeah, that's an interesting time to be getting into it.
There was sort of this like renaissance of people kind of having this realization
that they can go in and grab things from services they want and like kind
of assemble products from, from whole cloth based on just little bits and
bobs of services round and about.
And that's de definitely where the modern conversation of how do we build
good things and like how, how do I behave properly as someone consuming
or building these APIs started?
That's really cool.
What interesting timing.
Allan Knabe: Yeah.
Yeah, it was really cool.
And it was like, you know, I think Apigee pre acquisition
by Google at the time, right.
So it was still in like startup mode as it were.
And, you know, we got to go across to San Jose and, meet
with a and go to the, I love APIs conferences and all of this stuff.
And it was yeah, it was a nice time, really great time to be
getting into, into the APIs.
I think nowadays we're maybe a little bit more mainstream, although there are a
lot of API companies coming out now, like startups, like my company, a pable, right?
We're we're startups and we're entering this space and kind of
sitting over the top of what these more traditional players are doing.
Mike Bifulco: Yeah.
And you know, that's a perfect segue.
So what's the elevator pitch for a pable?
Allan Knabe: Okay, well the, the elevator pitch for a pable I mean if
we, if we think about when we came up with the idea, it was also at Swisscom.
So my co co-founder is a, a clever guy called Alexander Ham.
And he was working.
With me in the, in a squad as it were, we had like this Spotify
squad concept going again, it was 10 years ago when it was mega popular.
And we led a team of like 10, 11 developers together.
And you know, we had a great time doing that.
It was amazing fun.
But one of the challenges that we had is that we were asked
to create new digital products.
So API products for Swisscom, so think like payment services and.
You know, the precursor to like WhatsApp and things like this.
That's what we were trying to do.
But we found that the tooling that came out of the box for
developer portals was pretty poor.
So we were using the one that came from apg, which was this Drew Pal PHP
solution that, you know, we didn't really like it, but we used it for a while.
And eventually no one kind of patched that solution and security said,
okay, it's just too vulnerable.
You have to take it down.
So a lot of companies did that at the time.
And what did they do?
They built their own API portals, right?
That's what we did.
Right.
You know, we spent like, I don't know, like two years, like making the API
portal and did a really good job.
Fantastic.
But it was kind of that feeling that the, all this energy from
mankind is going into building.
API portals there are bespoke.
And, and really the amount of features you want to build for an API portal.
If you're building it yourself, it's limited, right?
You can only get X features in there before someone says that'll do.
And it's basically just getting the API key sticking some documentation on it.
But we wanted to do a lot more with it, right?
And, and that's kind of like where, where we went with API all is saying, okay,
well, treating APIs as products right is one of the biggest things that we do.
You know, I really believe in API product management.
I am an API product manager and see the value in that.
So we really try to bake that into API able, and that does go
hand in hand with monetization.
Not every company wants to monetize, but those that do,
can do it with a pable, right?
So it's, yeah, it was that kind of like genesis moment of saying,
okay, if everybody in the world is building these API pools, why
don't we just build one that's like great and provide it as a service.
So that's where we got to.
And I, I think what we're really noticing as well on the, again,
more on the enterprise side, is the amount of organizations that
have more than one API portal.
It sounds a bit crazy, but if you're as an organization, you've done some
acquisitions and you end up with like multiple technologies, so, so imagine
a situation where I think you've got MuleSoft and you've got Kong
and you've got Apigee, for instance.
Sometimes you'll have three portals.
My, my previous company, Connor, at one point, I, I'm glad to say it's not the
case anymore, but we had, I think Dev.
dot and we have develop dot and we have developer dot, right?
And you've seen some, and you've seen banks as well.
You see this very similar situation as this, like different factions within the
organization using different technologies.
And the technology assumes that you will use our portal and we are,
you know, the only company in the world and, and you know, so there's.
Cross usage there.
So that's one thing that, that we kind of identified and we said, okay, well we're,
we're technology agnostic then, right?
So you can have Kong and MuleSoft and Apigee in your organization and just go
ahead and connect the gateways in, right?
So as a developer, we're making developers life much easier that they don't have to
then log into three different API portals.
You have like.
One unified portal where you can just get everything you need.
And the token management should work in the same way across, across all.
Mike Bifulco: Sure.
Yeah, I think that's, it speaks to an interesting thing that happens
in product development on any scale, but certainly at enterprise level.
I would imagine pick, pick, I mean, if you're listening to the show, pick
any like, fortune 500 sized company that's not primarily a tech company.
Imagine the size of their dev team and the amount of stress they're
under to deliver things probably in an underfunded under timelined sort of way.
They will put as many resources as, as they're able to, I'm sure, to
developing the API itself, right?
Make sure it does the things it purports to do, right in the languages
that they, they are comfortable with.
And when it comes time to make that thing available for usage there's
probably a very rushed moment where it's like, ah, okay, now we need
to expose this thing to the world.
So let's,
what's the simplest way to put up a, a.
A developer portal where someone can go and now consume our APIs.
And I think that's maybe the curse of product development is it's like you
spend so much time building it, and then the last bit of pushing it over the line
often is where things start to fall apart.
And if you've, I, I mean lots of our listeners are probably familiar with
this, but if you've tried to consume an API from, like some random company Inc.
You know, from, from wherever in the world and you've come across a
site that looks like it was built in, you know, visual studio.net in
Allan Knabe: right.
Mike Bifulco: you've had this feeling.
Exactly.
So, so that's really interesting.
And so, I mean, it's, it's a core problem that, that a lot of these
product teams face and a lot of API devs have certainly dealt with.
I'm curious, how, how long have you been working on this?
You said it started when you were at Swisscom.
What's kind of the timeline for that?
Allan Knabe: Yeah, we kind, we, we carried the idea from there.
And it was really when I, when I left Swisscom I, I moved to Finland
to Helsinki and started working with an elevator or actually I think they
call themselves a people flow company.
Right.
To, you know, be more modern.
Right.
I guess, you know, but they're an elevator company.
Yeah.
And when I started seeing, okay, the same problem there, right.
Different technology, but you know, multiple gateways and, you know, not, you
know, no one providing a good API portal.
That was kind of the, the point for me where I said, okay, I need
to quit my day job and do this.
Of course, I quit in February, 2020.
I mean, the best timing in the world, right.
Mike Bifulco: Yeah.
Allan Knabe: Yeah, I, I, I, you know, of course, you know, coronavirus
was, was around at the time in China and I just thought, okay, you know,
that won't be a problem for me.
And I quit my day job and by April I was babysitting.
'cause we have three children, so my wife was working and I
was just looking after the kids.
So that was good fun.
But that was kind of like the genesis there in that.
In 2020 when I formed the company and basically was looking around
for potential customers and we found a great company called bmo.
They sell bicycle insurance.
And what they're trying to do is embed their APIs within the shopping cart
of you know, larger bike companies.
So you can go like specialized or con or someone like this.
See an insurance offer within the shopping cart process, right?
So, so we've helped them with their APIs and getting them exposed so that
they can get more partners effectively and get more customers that way, rather
than relying upon someone buying a bike and then thinking, oh, I wonder
if I should insure this thing, right?
Because that never happens, right?
But if it's in the shopping cart process, you're like, oh yeah, I can
do this 50 bucks a month, whatever.
And put it in.
So, so yeah, so we, we built like out the first version for bmo, which
is kind of like a small and medium sized company which is good 'cause
we could do like, you know, the base and work with them to get that done.
And so we were building it like basically 2021 22.
We got funding in 23.
We basically perfected the products and then we have a bunch of customers
working on it from like smaller startups.
We have a startup in Canada that's called pirate weather.
And they've got now, I, I guess it's something like 8,000 developers using
the portal, which is, is amazing.
Yeah.
But told us something about scale within the product as well, so
that gave us some work to do.
So it's pirate weather.
Yeah.
And
Mike Bifulco: Wow.
Allan Knabe: so, so we basically we're, we, we've onboarded these guys.
And that, that's where it kind of came in and we've been working on
it for, yeah, some, some years now.
We've probably been working on the product too long.
We should have, you know, gone in, out the door sooner.
But we, we wanted to make it like really feature complete, so wanna make
sure that it has like the, you know, great API products that are monetized.
And one of the features we just added, actually, that I really
wanna bring out is the API catalog.
Which is more like an internal developer thing.
'cause we came across some, quite some customers who have so many
APIs, like thousands of APIs, and are cataloging them in an Excel sheet.
So it must be a developer working in an organization like this bank we, we
were talking to in, in South America.
And if you wanna know what APIs the company has and and which one to
use for any specific case, you gotta be searching an Excel sheet right.
No developer in the world wants to search an Excel sheet, right?
Nobody wants to search it, so, so we put together this API catalog, which
effectively, because we connect into the API gateways, we can retrieve
a list of all the APIs available in that gateway and then list them.
Now if you've got like just one API gateway, maybe that's not so useful.
But we find that especially in enterprises, they can have like up
to a hundred API gateways or more.
Right.
You know?
Especially if they've got lots of regions, again, different technologies coming
into Play Kong versus Apigee and so on.
But having like this one unified API catalog.
Is being really helpful.
It's like one of the features that we didn't intend to build, but, you know,
it was the most requested and it was actually kind of easy for us to build
since we already did all the integration work to the underlying API gateways.
Mike Bifulco: Yeah, I think that fits pretty cleanly into the, like,
problems worth solving that a lot of certainly enterprise scale companies
will never dedicate time to you know, if, if the thing is working
and someone can find it in the Excel spreadsheet, like dust it off, problem
solved, we'll call that good enough.
But I'm, I'm sure, especially if you've.
Been able to build a solution that's reasonably plug and playable from
there and it makes life better.
There's clear value add, especially if they see, you know, API usage, picking
up or whatever monetization, picking up whatever the metric is there.
I think there's lots of ways to measure that.
So can we talk a little bit about the, I guess the like major features
that API will provides today?
It sounds like there's obviously the, the gateway product and the catalog.
Is there a documentation angle as well?
What else are you providing right now?
Allan Knabe: Oh yeah.
Yeah.
I mean the, the core developer experience is something that was
always very very important to us.
And, and so there we're actually using something open source called rapid Doc
Web that I, I guess we can get to that.
In more detail, but we're using Rapid Doc web to, you know,
put the API specifications up.
We were going to build our own documentation tool, but then
we found this and said, okay, look, it's absolutely fantastic.
We'll go ahead and use that.
So, so we put that in there for, you know, developer documentation.
We do some nifty things like synchronizing the documentation from the API gateway.
Which is nice.
So you can update it on the documentation on the gateway and you get it synchronized
across into your API products.
Some of the other things we do as well is we, we really tailor the documentation
for the subscription you are using, right?
So sometimes you, you see like an API specification, which
is, I dunno, 50 pages long.
And you have to try and work out as a developer, you know which parts
of it are relevant to like your use case that you should be using, right?
And so what we said is that if you can say, okay, in this particular
API product and in a particular plan, because you might have like
a small, medium, and large plan.
And in the large plan, you might get more endpoints.
More methods, right?
And you want the documentation to reflect that, right?
So you can switch between these different plans and see, okay you
know, oh, okay, I'm not getting a post possibility on this endpoint,
but I do get that in the large plan.
Right?
And so making that really clear to the developer what, what they're
working on with the whole, you know, triad functionality is
a triad console there as well.
Once you've subscribed to an API, the API credentials are automatically
assigned to the documentation.
So you can just start pressing buttons and it will do, you know,
API calls for you and so on.
So, you know, trying to help the developer.
And I, I'd say, you know, they're one of the key things as well is that we
noticed, we noticed working at, at Swisscom and elsewhere as well, is
that the decision maker to use an API is not always the developer, right.
Developer may be the one like signing up using it, but we really feel that if
we can get the decision maker to sign up for the API and put their credit card
in and sign any contracts and go for the approval process, and then do invite
the developer in a at the correct time.
That's much more useful for the developer because, you know, no
developer likes waiting for approval.
Right.
It, you know, you, you go, you go to a site, you sign in, you know, I wanna use
this API, the worst thing a developer can see is, okay this is pending approval.
Yeah.
We'll get back to you when John comes off his vacation in two weeks time.
So, so we, we really try and, you know, work from our experience of seeing Okay.
You know, who's making the decision to use the api?
Sometimes it's the developer directly, right?
For, you know, more enterprisey, contractee, APIs we, we let you know
more of a business person take care of all of that stuff, and then just say,
okay, within the team, invite in the developer to work on the API and then
they just, you know, get straight in.
The subscription is there, they get the API key and they start working.
Okay.
Mike Bifulco: Yeah.
I am, I'm victim or I have been victim of that in the past where hey, here's
the next great thing we're gonna use, or maybe I have the idea to, Hey, like, our
team should probably adopt this product.
And you get there and you're hit a door stop because it's
not security approved or I.
Accounting hasn't approved the expense or whatever the case may be.
It's a really interesting approach.
I, I think typically when we're talking about API products it's not really a
facet that comes up and it's definitely like an important angle, especially I'd
imagine if you're dealing mostly with enterprise level customers, there's a
lot more of that like red tape in place to keep the business safe and secure.
That makes a lot of sense.
Allan Knabe: Yeah.
Mike Bifulco: You, you touched on something a minute ago that I, I think
is interesting too, that you were talking about differences in plans for APIs
and making different things available.
I noticed on your site that there's some monetization features available as well.
Can you talk a little bit about that?
Allan Knabe: Yeah, that's, that's really exciting.
Right now we're working on some of the more advanced monetization cases as well.
At the moment we've got, you know, more of a like standard subscription base
that if you subscribe to use these API endpoints, you can use them for, I don't
know, 10,000 times a month, 10,000 API calls for 50 bucks or something like this.
So that's kind of where we started on.
A lot of our early adopters have used this, but we are getting
into some cases now where we're doing more usage based pricing.
Which is what people expect with APIs, right?
So per API call, you're gonna, we're gonna charge you $1, or whatever it is.
The caveat there is that we, we are not a proxy to the API, right?
So we do not get involved in like the networking layer of your API.
We leave that to the API gateway.
So unlike some other solutions which proxy everything and
add latency, we don't do that.
The downside of that, of course, is that we then don't going get
to count the number of API calls.
So we have to do that afterwards via the the log file, which is
what we're working on right now.
We hope I mean may, maybe even by the time this podcast comes
out we'll have completed this for these advanced cases where.
You know, you can charge for a particular endpoint for a particular
method, you can have a different price to anything else, right?
So especially with AI companies, they if they really are interested in these
cases of saying, okay, certain calls are more valuable than than other ones.
And we get 'em requests now for credits as well to say, okay, someone
could buy a package of credits.
And then depending on the kind of course they're making it
uses more or less credits.
So, so these, you know, it's really interesting time to be working in
this and yeah, luckily the team is doing a really good job, so.
Mike Bifulco: Yeah, that's a big change in paradigm that I think we faced probably
somewhere in the last two years where LLMs in particular have made it so that like
the same API call costs differently every time you call it, based on how much input
and output that it's, it's using which.
I don't know if, if you use it back to, call it February of 2020 that was a pretty
foreign concept not too long ago and is very, very like standard these days for,
for a lot of the creative AI based tools.
So really cool to see being able to support that.
There, there's a lot here.
I'm, I'm honestly really impressed by the amount of things that, that API will.
Provides, and even like the granularity you're getting into for, for monetization
between seeing freemium and usage based and different subscription tiers and
all those things, there's, there's quite a bit that goes into that.
Can you tell me a little bit about what it would be like for a team that's interested
in using api, able to adopt API able, what does the integration process look like?
Allan Knabe: For the integration process, we really tried to make it.
As simple as possible.
I know everyone one says that, but we, we saw like when we were at Swisscom and
elsewhere, that there are products you can get and you can do a lot of your own
development to, to integrate, et cetera, and you are ready some weeks later.
But we, we had, I mean if we take just that one case of pirate weather very
small company in Canada, I think they were up and running in an hour or something.
They just connected their.
Amazon API Gateway, which you can do with a role right in the Amazon.
Like 10 minutes to connect that.
And once you've got your APIs well then you just need to, you know, put
a pretty picture on it and say how much you want to charge basically.
And it's kind of working, right?
So yeah, we really tried to do it like, you know, product led in, in that case,
so that it was, you know, off the shelf.
Very quickly.
Obviously for enterprise customers, they might want a little bit more, more help
with the onboarding process and so on.
And for that we have, you know, pilot programs where we sit with
them and, and discuss their needs and so on, which is fascinating because
then you get to uncover like these, like really urgent needs they have,
like the, that's how we got to the API catalog part as well, right.
Just by talking to, you know, people who wanted to use it and then
figuring out that actually they want a catalog to seal their APIs, right?
And being able to add that.
That quite quickly.
But it, it does drive my development team insane because it, it's just constant
feature requests, you know, from me.
And I apologize to the team if they're listening to this, but I, I do keep like
a constant flow of new features coming in.
So at some point I have to stop and we just need to tidy everything up, but yeah.
Mike Bifulco: Well, that's the joy of building a product that people
want, is that there's lots more ways to use it that come up along the way.
So one of the interesting things about the product you're building
then, and, and from what I'm hearing is that a pable is probably from the.
Implementation standpoint of the dev teams that are integrating
with API bullet, you're sort of language ag agnostic, right?
There's really just needs to be able to point to and understand
the sort of the shape of a gateway.
Is there do you find yourself working with particular I don't know, flavors
of team more often than others?
Like, do you, do you find that Ruby developers come to you or rust
developers or something like that?
Or is it coming from all over the map?
Allan Knabe: It is all over the shop, to be honest.
We, we, we get everything come through and at the moment we're getting all
shapes and sizes of company come across.
It's, it's obviously really interesting working with startups.
And, and you know, them getting like Python requests and stuff like this,
it's really interesting when they come along because they, they wanna get going
immediately and have it finished in two weeks and they don't mind giving you
a hundred requests at the same time.
So very useful speaking to those guys.
Very useful.
The enterprise is, you know, first of all, you have a conversation for
six months with someone who's not actually ever gonna use the portal.
And then, then you get to the real team who are, who are kind of using
it and connecting gateways and stuff.
So it's two, two different worlds.
But yeah, in terms of like, you know, languages, it's, it's a huge chasm.
Mike Bifulco: I could imagine.
What about open source work?
Are you doing anything with open source projects?
Allan Knabe: Well, well, I hinted at rapid Doc.
Is, is one that we use within our products.
It's honestly very, very well put together.
You, you can find it at a rapid doc web.com.
I guess you'll put a link as well in.
Mike Bifulco: Yeah, absolutely.
Allan Knabe: Yeah, that's great.
So it, it, it's it's a really good project.
I think, you know, probably more people could get value from that
if you just want to, you know, if you've got a simple API you wanna
document it and put it up somewhere it's a really nice project for that.
And we're, we're hoping to, to support that community more
and more as we go forward.
So, so that's exciting.
Other stuff we're kind of like interested when we get five minutes
because like I said, it's a constant like feature frenzy at, at api able,
but one of the things we're looking at is more on the oof two side as well.
Somehow helping.
And this was, this was like an idea we had a few years ago working at Connor.
And that's when you turn around to a product manager when you're building,
for example, an app and development team starts to ask some questions like,
what, what flavor of OO two should we use for securing this application?
Right.
And getting blank stares back.
Right.
So the, the, there's some kind of a translation needed there.
That I think is really doable.
Some kind of like a tool that you could build to say, okay, in,
you know, more, more human terms.
How would you like to secure something?
What are the cases, right?
You know, is it on a per user who's logging in basis or is it more of a
machine to machine case, wherever.
So some kind of like, maybe just utility that.
You know, you go through that flow and out of it comes like the correct
o or flow or you know, JWT, what you should be using as a technology
to secure it for that given case.
Right?
So that's kind of one open source tool that we would like
to, to put out at some point.
'cause OF two is, you know, well, it's developer, right?
And it doesn't translate very well to, you know, you can't send,
you know, we've done this, right?
We've sent like business people the o to a specification and said, yeah,
just choose the right flow, right?
And they've looked at it and go, oh my God, this is crazy.
So, so there's that kind of thing there.
The other one that we would like to look at maybe get a chance this
year a little bit more is to say, okay, how green are your APIs?
Right.
So I'm, I'm sure Phil would be interested in this one as well.
But we're in a, a very good place since we're connected into all of the
API gateways across the organization.
And we can, you know, see from the log files what developers are all doing.
And start to drop in some hints for the organizational owners, the
customers to say, okay what could you be doing to reduce the footprint here?
Because I mean, APIs are, is it 83% of all internet traffic or is it more than that?
I can't remember.
It's around that kind of like area, a huge amount of work happening
with APIs and you know, are there some quick wins, for example.
If we see a developer is getting the status of something
every two seconds, right?
It could be you know, a potential then to turn around and say
well, maybe this should be behind some kind of a web hook, right?
Say, okay, instead of some polling all the time, you know, and, and that generating
a lot of backend work, you could say, okay, we'll update you in like four hours
when this thing has changed status, right?
So.
That's like an immediate idea, but I'm sure we could uncover
like, a lot more to say.
Okay.
Just, you know, let's, let's reduce the number of API calls if possible.
And also not forgetting the, the load on the back ends as well.
Mike Bifulco: Yeah.
Oh, that's, that's a really interesting product angle and you're certainly well
positioned to be able to advise on that.
Given what you must know about how, you know, gateways are deployed and
consumed and all that really fascinating.
Yeah.
I think that is, one of those things that teams rarely think about, right?
Like, not everyone has a Phil Sturgeon on their team who is very, very cognizant
of the existential crisis facing all of us with, with environmental friendliness.
And it's hard.
It's, it's something that's subtle, right?
Like, it seems really simple to make a polling call and like, yeah,
every two seconds we're sending a couple of packets across the web.
But like,
you stack that up for a day and a week and a month, and you're, you're, putting
a lot of energy through the wire that doesn't necessarily need to be done there.
That's super cool.
I like that.
Allan Knabe: that's,
Mike Bifulco: oh, sorry.
Go ahead.
Allan Knabe: I was gonna say, it's, it's actually a, it's probably an entirely
new company and product of its own Right.
But that, that, that's, you know, if someone wants to run
with this idea, go for it.
Yeah, again, my team hate me because I always have these crazy ideas.
I.
Mike Bifulco: I like it.
I'm into it.
Well, I, I will make absolutely sure to drop your GitHub organization in
the show notes as well, if people are interested in following the open
source and exposed code and projects that you're working on, on the web.
And certainly if folks are interested in chasing you down for working
on some of these projects there, there'll be ways to do that there too.
Let's let's talk about what's to come for you.
What is API bull looking at building next?
What are the things on the horizon that are exciting for you?
Allan Knabe: Yeah, I think I already, I already touched on kind
of like these, these features coming in advanced monetization cases.
Also along with that, the analytics that we can get to say, okay, how
are you using the APIs a little bit.
This like green thing is in there as well.
Of course, you know, when we get to see, okay, what you, what you're doing with
the APIs and, you know, our developers you know, signing up to use your api I,
but then not making the first API call.
Or did they, or they, were they a regular user of your API and certainly
dropped off and things like this?
There's lots of very interesting things we can do there as well, but I, I think
we're pretty much like feature complete.
Other than that we'll probably add more API Gateways, we support Amazon, API
Gateway and Kong and Appg and Azure.
And so we'll probably add some more API gateways this year.
Lots of people on like MuleSoft and stuff like this, so, we'll,
we'll, we'll add those in.
But that's yeah, we're, we're, we, we need to, you know, not
do more features and so I'm
Mike Bifulco: Yeah, features versus focus is a perennial startup founder challenge.
I get that.
Okay, so what about your team?
Are you expanding?
Are you looking at hiring?
Allan Knabe: Okay.
So we're, we're currently going through our seed round.
So, so we're doing another raise at the moment, and as soon as that's
complete, then yes, we will be looking for developers to join the team.
You know, especially we have need for DevOps type people, site
reliability engineers to, to take care of the infrastructure because
there's a lot of moving parts.
We opted for a single tenancy application which is, which is great.
But at the same time takes a lot of, you know, maintenance and looking after.
So that's, that's definitely one role we'll be looking for in the future.
Mike Bifulco: Got it.
Yeah, that's another link I have in the show notes is the, the correct sort of
URL for careers or job listings for api.
I able too.
That's great.
So before we wrap up, Alan where, where's the best place for listeners
of the show to go to find and chat with you if they're interested?
Allan Knabe: Okay.
I spend most of my time on, on LinkedIn.
I'm not cool enough to be on X, so I'm, I'm mainly on, on LinkedIn.
Other than that, you know, it just come to the website and then just, you know,
throw in a contact request or something and you know, get a, get ahold of me.
That way as well,
Mike Bifulco: That's great.
And just so that we say it out loud, what is the website.
Allan Knabe: a API able io so you can think of it's, we make you API able
or you could be asking a question.
As a developer, when you look at some code, you can say.
Is that a pable?
Mike Bifulco: I love it.
Again, another one of those things we'll drop in the show notes.
And Alan, thanks so much for, for joining me today.
It's been a real pleasure.
I'm super excited about what y'all are building, and happy to have you come back
on the show anytime if you're you know, rolling through new feature announcements.
So there's some you know, environmentally friendly things we want to get
into for a deeper conversation.
I'm happy to do that too.
Super, super cool to have you here.
Thanks for joining today.
I appreciate it, Alan.
Allan Knabe: Yeah.
Thanks a lot, Mike, for having me on.
Really enjoyed it.
Mike Bifulco: Of course.
Yeah.
Take care.
Talk to you soon.
Allan Knabe: Thanks, bye.
Mike Bifulco