Mike Bifulco: Hello friends, and
welcome back to APIs you won't hate.
My name is Mike Biko, API
developer, consumer sufferer
designer, all of those things.
And coincidentally also hosted
the show for quite a while now.
I am excited to be sitting down today
and chatting with a new friend to
talk about a product that is very
relevant to lots of API developers.
If you have built.
A tool or product or service that relies
on lots of APIs, you've probably also
incurred spend and cost and you know, sent
dollars across the wire having to do with
using other people's service services.
Like me, you've probably also heard
nightmarish tales of people accidentally
taking advantage of too much of a
service and ending up with a, you
know, $20,000 spend accidentally
month over month because of a runaway.
You know, for a loop
or something like that.
And so I believe get into answering
some of the questions and some of
this sort of neck of the woods.
Chatting with my new friend Alex
Clarkfield who's founder of Super Good ai.
Alex, thanks so much for joining me today.
I really appreciate you being here.
How are you doing?
Alex Klarfeld: I am doing well.
Thanks for having me.
I'm excited to be here.
Mike Bifulco: Yeah, of course.
I'm really, really glad
you're here as well.
I, I think I hinted pretty strongly
at super good and what you're doing.
Why don't we start with the elevator
pitch of super good and I'll work
back through your story from there.
But yeah, tell, tell me the 32nd
pitch for what super good looks like.
I.
Alex Klarfeld: Yeah, for sure.
It's pretty simple.
So it's a couple lines of code you
drop into your code base and we
automatically monitor the cost and
performance of your third party APIs.
That's it in a nutshell.
The performance and cost piece,
you can go into like a rabbit hole
of like exactly what that means.
I'm sure listeners of this podcast, like
horror stories are popping into their
heads right away when they talk about
like APIs failing or causing problems
and taking down parts of the business,
causing executives to freak out over.
Insane invoices.
But those are all the problems
we're looking to solve.
Mike Bifulco: Yeah.
Got it.
Well, you've certainly
come to the right place.
I am definitely one of those people
who uses a lot of APIs that are
sort of spend per usage or at least
on some monthly cost based on.
You know, capped use.
And I think lots of the folks
who listen to this show will be
really interested in that as well.
I also should add that many of the
folks who listen to the show are
also builders of API based products
and would probably be interested in
what you have to say about offering
spend management tools to people and
creating user experience, end user
experience for the people being billed.
That is, I dunno, the most ideal perhaps.
Before we get into that, I
would really like to hear about
your story before Super good.
So can you tell me a little bit about you
before this and kind of how you got here?
Alex Klarfeld: Yeah, for sure.
So, so before Super good, I helped
found a PropTech FinTech company called
Divvy Homes divvy really cool mission.
We were basically trying to help
renters transition into homeowners.
So we take folks who like, maybe
they couldn't get a mortgage today.
We thought they could get one
in like a couple years time.
And then they would pick a house out.
We would buy it for them, and
then they would, live in it.
And each month, part of their
monthly rental payments would
go towards a down payment.
And the idea is at the end of this
program, they would we'd cash 'em out
and we'd like help them get FHA mortgage.
So really cool mission.
The sort of like nitty gritty
inside was we built like an
end-to-end home buying platform.
So every part of the home buying
process was all in-house software.
Which, you know, was a lot of
my responsibility for building.
And as you can imagine, we had
actually sat down and counted,
we had like 47 different.
Third party APIs that we
had to integrate with.
So it was the usual FinTech suspects
like Plaid, Experian Equifax, TransUnion
checker, you know, you name it.
All the payroll APIs.
And then there's sort of like
a long tail of a bunch of like
real estate specific ones.
And, you know, two things would happen,
I'm sure a ton of people listening can
relate to this was, you know, my day job
is like building code, trying to build
the best product for our customers.
And what felt was like my night
job was dealing with vendors so.
One, like we'd get a bill
at the end of the month.
Not to name names, but I will.
But like DocuSign would like suddenly
say like, Hey, you guys are over and you
owe us some crazy number of, of overages.
And we're like, they would send us
a graph, I remember very vividly.
And we're like, how do, how
do we not have this graph?
Like, it's like buried in
logs somewhere and it's crazy.
And the other part would happen
is like a developer, these APIs
would break in really weird ways
and it wasn't like outages are
easy to detect, like it's down.
What do you do about that?
But like schema changes were
a little bit more nefarious.
Like the vendor suddenly upgrades
their version and everything breaks.
Another one that like schema changes were
like value changes, like enums changing.
That was pretty bad.
The other one that was like worse I'd
imagine is like data quality issues,
like all the, the hype that, you know,
someone trying to sell you an API
can give you like you really don't
know until you run it in production
and like against real customers.
And then once it's in there, you
have to like continually analyze to
make sure like you're paying like
a non-zero amount of money to that.
So better get the most bang for your buck.
So these were the two problems I kind
of ran into as super good was like.
The sort of data quality, keeping up
with like the version of the APIs and
then they kinda like all boiled down
to like the bottom line of our company.
Like we were running customers through
this application flow, hitting a
gauntlet of APIs and it was just
like would make or break our business
depending on which, like how the
API performed and how much it cost.
Mike Bifulco: Yeah, I think what a lot of.
People maybe haven't experienced UN
until they're sitting at the helm of a
company is that a lot of your success
or failure once you have a product that
people are buying, is getting down to
unit economics and driving each user's
experience to profit for you and value
for them in whatever way that means,
you know, depending on the company.
And it's a really hairy problem to solve.
And every dollar that goes out the door in
the, in the name of making your customers
happy is you know, working against you.
And effectively in that sort of unit
economics game, it's a tricky thing to
wrap your head around especially if you
know, you've, you've spent your days
studying, say, computer science and
worrying more about merge sorts than like.
The realities of a consumer facing product
or even a B2B product for that matter.
Um, I, I'm curious, I don't know if
you mentioned before you built divvy
homes and before you built super good.
What was your background?
Or you come from a prop tech background.
Are you more on the business side?
Are you a, a sort of straight
up and down developer?
Like how, how has your, how has your
career path shaped where you are now?
Alex Klarfeld: Yeah, for sure.
So I'm a full stack developer
through and through.
I studied electrical computer
engineering in college.
Like made my way from like embedded
software into like web application
software from the Midwest, moved
out to Silicon Valley based on.
Some, some friends that came out
here and just got, kind of got
fascinated by the ecosystem, but I've
always been a full stack developer.
Sort of a master of none I like to
say, but I just love the breadth that
it, that sort of, sort of gives me
and like really being able to like,
dig into very specific problems.
I also love product so just
combining like the two, two parts
of like, just like building things.
I care a lot about the, the what that
I'm building more so than a lot of like.
Much better developers than
me care about, like the how.
So that's, that's, that's kind of me,
Mike Bifulco: Sounds shockingly familiar.
I feel, I feel like in a lot of
ways I'm looking in a mirror there.
Can you tell me then about ha have
you worked on developer facing
products before Divvy homes?
Sounds like it was more consumer
facing, but this is really built
building four developers or dev teams.
Is this your first time
around the block with that?
I.
Alex Klarfeld: S.
P pretty much.
I had a I worked at a company
that was, it was very interesting.
It was tools for like
data engineering teams.
It was founded by one of the
he was founded by the creator
of Postgres Mike Stone Breaker.
So we were building for fortune
500 companies basically, and like
the development teams in there.
So that was an experience.
And then at Divvy we were like, we had
a very cool consumer facing application.
But the, like, the sort of
like iceberg below, it was
building for ops teams actually.
'cause we had like an operations,
like it was a, it was like
software powered ops company.
So no developers specifically,
but I'm familiar with like working
with like the in-house folks.
Those were usually the people I
had to work with when I was like
dealing with API issues because it
was typically like an ops person
or like someone on underwriting's.
Like I don't, I don't know why a bunch
of customers are starting getting
stuck in their application flow.
It's like, all right,
well Experian is down.
And that kind of explains it.
Mike Bifulco: Okay, cool.
Yeah, and I, I guess the other thing
is as a you know, self-assigned
full stack developer, you've
probably been subject to many other
developer products along the way too.
So I
think that buys you some familiarity
with it, at, at the very least.
Alex Klarfeld: Yeah, I've been a, I've
been a huge consumer of these, these
APIs and there's, there's great ones
and then there's not so great ones.
And I just, my goal with super
good, my long-term vision is I
wanna make all the APIs great.
So like the ones that are great are like.
Killing it in the market
like plaid, I'd say.
Like, they're so ubiquitous, but
they're, they're ubiquitous for a reason.
Like the, the documentation is incredible.
The onboarding experience for
developers are, are incredible.
And like, I think also like Stripe
is, is one of the top dogs in
terms of like developer experience.
And I like, there's just a long tail folks
who like either just getting started out
or don't have the resources to invest.
And I just wanna like, bring everyone
up to the level that like the stripes
and plaids of the world's have set.
Mike Bifulco: Sure, yeah.
It's an extremely high bar to hit.
Is one of
those things that I think a
lot of dev teams aspire to,
especially if you're building
things for other developers to use.
We as developers tend to be really
good at sniffing out things that
we don't like, for whatever reason.
And Metaphor is a really powerful
tool there, like saying, Hey, you
know, like plaid's version of this
is so much better wise than this.
More like plaid or, you know,
what were they thinking when they
got here is a very common thing.
And usually by way of comparison,
like, oh man, I really wish that
was like Stripes web hooking
interface or whatever it may be.
We, we also very nearly made it to
10 minutes into the podcast without
me having to give the disclaimer that
I also previously worked for Stripe,
Alex Klarfeld: Oh, cool.
Mike Bifulco: something I feel
like I should call out on, on
each and every mention of it.
For, for clarity and, and for
transparency and all that.
Alex Klarfeld: Cool.
Mike Bifulco: okay, so we
touched a little bit on the, the
elevator pitch for super good.
So the tagline I think on your site
says something along the lines of
like, curb your API spend before you
get a bill which is super cool and.
I, I get the mission from that.
You also mentioned that it's
something like a, a two or three
line implementation to do that.
So I'm curious about that.
What does that look like?
How do I integrate with super good
and start getting benefits from it?
Alex Klarfeld: For sure.
So super good is a, the way that
it works today is for a free
version, it's a passive interceptor.
It's not a proxy.
So the way it works, all the
clients or SDKs are open source.
You can check us out on GitHub.
You drop in the few lines of
code and we basically apply
a light monkey patch to like.
Your favorite HTP library.
And then what it does behind the scenes
is like, as calls get you know, made
in your application, we kind of stow
away the calls locally in memory.
And then what we'll do is
basically redact everything.
Like there's, one of the big things that
I take very seriously is we do not want
to have any data that we should not have.
So everything is redacted by default.
You can set that flag and then
once on an interval, those
logs will get shipped to our.
Our, our service, which will start
to analyze from a cost perspective,
data quality perspective.
We're sort of like just running live
analysis on your HTP logs specifically
in order to solve this problem.
Mike Bifulco: Got it.
And so it sounds like it's
a client side integration.
I mean, I would imagine there's a
service side element to this too,
wherever API calls are happening.
Is, I
feel like one of the, the, the
things that my API dev friends
would ask is what does that look
like in terms of performance hit?
Is, is, are you getting in
between my call and the service?
Or is this truly something that
is just like queue safe for later?
Alex Klarfeld: Yeah, it's, it, I
intent, we intentionally built it
to get out of the critical path.
So that is why it's not a proxy.
So it doesn't mess with any
like actual network traffic.
There's no like network call
between the call that you're making.
The only limitation is like memory
like the memory limitations of the
machine that you're running on.
'cause all it is, is dropping
the call into like a memory
store locally and then running.
Redaction on the, the, the js ON.
So it's very minimal.
Latency hit just like completely memory
bound to the machine that you're running.
Mike Bifulco: Yeah.
Fascinating.
That's a very interesting angle.
I can imagine the challenge of trying to
track billing for every, every API call
is the every a API call part of that.
So what, what have you done
to try and.
Determine like which of these calls
I'm making out of my service are
ones that are metered in some way.
How do you determine who's billing me?
Alex Klarfeld: Yeah, exactly.
So when the calls come in, we basically
run it through categorization right away.
So try to figure out like easy ones,
like domain is specific to the vendor.
The harder one is each.
API has like a different signature, for
example, like S3 uses, like the sub-domain
to like identify calls, but like maybe
certain plaid calls use the path.
And then sometimes they'll stick
a like a ID somewhere in there.
So the first step that we do is
sort of like categorize the calls.
So as they flow in.
We'll try to automatically
categorize them best we can.
We actually use LLMs for that.
It's pretty good.
And then sort of like we can manually
re-categorize things if they're
not like being grouped properly.
And then after that, the, we kind
of had have like a toolbox in like
the standard way that people bill.
So like.
We know how open AI and together, like
all Bill and plaid, also bill specifically
based on like accounts rather than usage.
And then we sort of built this
flexible framework on our end
where we have the tools basically
to just implement custom billing.
Like if you're like overage based
where it's like you get certain amount
of calls for a certain value and
anything over that, it's more value.
We can, we can basically fine
tune it to your specifications.
But like for free users right away it's
just like, drop us in and get usage.
And then the sort of like more advanced
metering for like the long tail APIs.
We, we, we charge for
Mike Bifulco: One of the things that
I am fascinated by is that it sounds
to me like the hello world is drop a
snippet in and the product sort of starts
sprinting away and going to work for you.
Alex Klarfeld: that.
That's right.
, Mike Bifulco: that's really cool.
What did the first version
of this product look like?
Like did you target one API in
particular, or were you starting
from categorization from day one?
Alex Klarfeld: Yeah, the first version
of the API was, it was just a node
library that like monkey patched fetch
and then just logged all the calls.
I think like a lot of people, like outta
the gator, like, you know, I have Datadog
or, or, or sort of century to do that.
And like the first version
that we built at Divvy was like
trying to use Datadog to do this.
And
it's really hard, like it's just a very,
like both like expensive from like a
cost perspective where you have to.
Like triangulate everything, like
every, every single thing that you
need to, to meter or you need to like
tag and, and instrument appropriately.
Plus the sort of like dashboarding
and setting up of it is like hard.
And sometimes like there's a
lot of like, you know, native
knowledge to the, to the team.
That's like, it's one person that
understands the Datadog logs and then
you also have to like maintain it.
So like not only is Datadog gonna
charge you per like field that you're
indexing, they're gonna, you're gonna
like have to continue to maintain it.
So the first version of this
honestly, was like, tried to
build in Datadog super hard.
Very difficult to maintain.
Second version of it was like a
custom logger which is more similar
to what super good is today.
And then really it was
just a graph on a screen.
There's just like, here's a bunch
of vendors you use and then here's
like their, their associated usage.
Get ready for the invoice and, and, and
kind of like building on from there.
Mike Bifulco: Okay.
And so.
Let's say I, if I've integrated with super
good, it's starting to measure metering
for the various APIs I'm consuming.
What does my end user experience
look like with Super good?
Is it a dashboard I get?
Do I get a series of emails?
Is it ACL I?
Like what, what's my how do I get
insight into what this all looks like?
Alex Klarfeld: For sure.
So we have a dashboard.
Though as an engineer myself, I
do not want to give engineers a.
Another single pane of glass to look at.
So it is, is meant to audit
if you, if you want to.
The two ways that we mainly interface
with, with folks is through alerting.
So right now we have standard
slack alerting set up.
So if it's like we start to notice
overages spikes in the bill, you'll
get, you'll get a Slack alert and then
also like sort of a weekly report.
So at the end of the week you'll
say, okay, this is sort of like the
usage that we, we've been seeing.
If you have uploaded like
your contract information,
we'll sort of be able to like.
Give you a heads up that like some
sort of renewal is, is happening.
And then the sort of the, the other
suite of tools we have is around
like data quality monitoring and like
more of like the nitty gritty error
monitoring, where it's like, okay, we
see an error that we haven't seen before.
We just wanna flag this to you to make
sure it's not taking down another system.
'cause a lot of these errors
that issues have can go quietly.
Mostly because if you, even if you have
instrumentation set up and like the
best tools, which we, we use personally,
like Century and Datadog, they get
noisy because APIs might error for.
A non error reason.
For example, like if plaid,
someone disconnects their account,
you're gonna get errors all the
time, every time you pull it.
But like, it's not really an actual
error, so you tend to ignore it.
But if you have like 80% of your calls
to plaid totally disconnected, that's
probably something that you, you shouldn't
ignore to save some money, at least.
Mike Bifulco: Sure.
Yeah, that all sounds very familiar.
Actually.
I spent a non-trivial amount of time, just
this week debugging an error with Twilio.
We were getting an error response
from, from some API calls.
And the API call is basically like
Mike and Alex are texting each other.
If I have a text conversation with you
over SMS and I, if I send an API call to
say, please add Alex to this conversation.
It fails sends a a 4, 4 0 9 back.
And the docs for Twilio say like, if you
get this error, probably just ignore it.
But it, it's, you know, when you
start getting that error a lot,
it sends up a lot of signals.
And especially if that was
something that was billed, it's
something I'd wanna know about.
But it may also just be a signal
from my tooling that we're trying to
do something we shouldn't be right.
It, it may be a a non breaking error or
maybe a breaking error, but it's a little
hard to ascertain from the beginning.
And I would certainly wanna know
if all of my, or 80% of my Twilio
calls started failing in a hurry too.
That's that's a great angle to take.
Alex Klarfeld: Yeah, and the,
I mean like it just feels like
pushing a boulder up the hill.
Like even if you instrumented something
to catch that specific error and you
put all the instrument, like, okay, this
is a thing that we need to like alert.
If it's only exceeding a
certain threshold, it might be
another one that's like probably
gonna come up in the meantime.
And it's just sort of never ending battle.
That's why like as an engineer, it's like.
Just drop us in.
We handle like the
instrumentation remotely.
Also, like APIs are like a finite there's
like a finite schema for each of them.
Like there's documentation,
there's a lot of data that sort of
like confines the problem space.
So like why not utilize that rather than
trying to set everything up on your own.
Mike Bifulco: Sure.
Yeah.
To, to that end, I'm curious for devs who
may be listening who build API products
is there something they can do or is
there a way for them to integrate from
their side to ensure that Super goods
understanding of their API is correct?
Do you consume anything along those
lines to say that, like, don't let the
LLMs decide, let, let you know, the
product owners themselves configure it.
Alex Klarfeld: Yeah, actually, so
part of, part of our, our pitch is we
wanna also help out the API vendors.
We're starting to roll that out right
now, where basically we wanna help give
the same experience that the plaids
and the stripes of the world give to
their customers to those API vendors.
So.
That integration's a little bit different.
We basically don't wanna get in in the way
of any sort of like live traffic as well.
So we'll actually hook into the API
vendors logs themselves and sort
of start, start using our tool.
Like the first version of this product
is basically like building out internal
dashboards if they don't already exist.
And then surfacing that
information up to the sales team
or supports teams so that like.
They can provide a better
experience for their customers.
Like some of the best API experiences
I've had are from like, honestly
like Century and the Datadog, where
they're like, Hey, your usage is
about to exceed what you pay for.
Just like wanna give you a heads up.
And that's just like not the norm.
So we want to kind of help, help
the API vendors themselves, make a
better experience for the customers,
like engage customers when we they
notice they're having issues engage
when like there's spikes in usage.
So that's also like a pretty big
focus of ours is like building
a product for the vendors.
Mike Bifulco: Yeah, as a vendor,
there's many things to get right there.
Pricing is a tricky challenge because
it needs to ensure the vendor can make
money, but also that there's an on-ramp
for users who start at a reasonable level
and that they, they don't have to, you
know, invest a ton to prove that the thing
is useful and valuable at the same time.
I would imagine some of it is also,
trying to be competitive with the
competition and making sure that
comparable services, you know don't under
underprice or overprice you or whatever
the optimization challenge is there.
To that end, maybe one of the things
I'm curious about and I had kind of
noted to ask you about is tell me a
little bit about Super goods pricing.
Alex Klarfeld: Right.
So we, we just released a free tier.
You can download it for free.
We basically limit to like, we, we won't
actually block you because I don't believe
in that sort of sales tactic just as
like an API consumer who, goes overage.
We're not gonna, we're not
gonna overcharge you for that.
We'll hopefully have some conversations at
the start, but the free tier is basically
a hundred thousand calls a month.
You can, you can set up pricing
for three vendors automatically and
then sort of like track usage from
the rest of the vendors for free.
Just to, the idea is like, we don't
wanna charge you for the vendors that
like work and aren't really expensive.
Like you shouldn't have to
pay for like tracking, like.
You know, maybe Google
APIs or like Stripes APIs.
'cause those just work.
So the best customers are the ones who are
like, yeah, we, we like, have a specific
set of APIs that we wanna keep an eye on
from price and like, quality and usage.
And those are the ones that like,
we also want to provide value for.
So that's, that's the way that like
philosophically, like I'm trying, we're
trying to price is, is get that for free.
And then everything else is sort
of like the enterprise part where
you have more than a million calls.
You have all sorts of vendors that
you want to sort of keep an eye on.
That's, that's sort of like dependent
on the the, the, the enterprise itself.
Mike Bifulco: Okay.
That makes sense.
I, I feel like there's a pretty big.
Delta between three APIs and a hundred
thousand calls and enterprise grade.
The question I would have there as
a potential consumer is when I get
to 100,001 calls and four vendors
like what is, what is the on-ramp?
Like there, am I jumping from zero to,
you know, thousands of dollars a month?
Is it like, what's the scale of,
of initial costs, I guess for
someone who's incrementally adding.
Alex Klarfeld: Yeah.
And, and, and like our goal is like
onboard slowly, especially like with
growing companies, like you just don't
know how many APIs you're going to use.
And I, for one, don't wanna be
someone who's like, oh, surprise,
you added like another LLM, this
is like adding to your bill.
So we basically try to charge,
we basically try to give
th 30 days free to monitor.
Every single API at any volume,
just to make sure that like, okay,
is this an API that is like worth
monitoring and worth tracking?
And the idea is at the end of the 30
days, you tell us and say like, yeah,
I wanna keep tabs on that, or I don't,
and then we basically discard it.
Or like, there's, there's a way that you
can set, set to ignore certain vendors
inside of our UI to just like, turn 'em
off right away so it won't stop working.
We'll just stop tracking if you
choose to, to stop tracking that API.
Mike Bifulco: Sure.
Got it.
I'm gonna press a little
further only because I feel
like it's my solemn duty
to do so, but like what was
truly, what's the scale there?
Am I looking at hundreds, thousands?
Alex Klarfeld: Scale in
terms of like the volume.
Mike Bifulco: No, sorry,
in terms of cost, right?
So, so like, when, when your customers
convert from free to paid maybe for
the smallest ones who are growing,
what does that tend to look like
for their, their incremental ad?
Alex Klarfeld: Yeah, for sure.
So it's, if it's pushing a million
calls upwards we basically start
at like 99 a month and then 10
million calls upwards, like, sort of
like custom pricing based on that.
But again, if it's a million calls to,
like, Google doesn't, like, probably
something you don't need to track.
So it's like more of like million calls,
like, like open ai a month kind of
thing is like a hundred bucks a month.
Mike Bifulco: Right.
Okay.
Yeah, that makes sense.
That, that to me is a narrative
that I think is easy to sell too.
Like the the scary thing is if the
product you're using to manage your
spending becomes a giant spend to
manage the spending, then it's
like, you know, an or a boroughs
of challenges to, to upsell through
the product stack there too.
Alex Klarfeld: No, I'm very cognizant of
that, like all the ways that vendors have
hurt me with pricing is like not something
that I wish to incur on like my own users.
So the idea is to be transparent
and like not screw up their
businesses as much as possible.
Mike Bifulco: Cool.
Yeah, I love that.
I think that's a, a good angle to
take and especially like I alluded to
before, I think developers are really
good at sniffing out when they're
being toyed around with, and, you know,
they're the first ones to head for
the hills if something feels fishy.
Alex Klarfeld: I don't really blame him.
I've done the same.
Mike Bifulco: Right.
Yeah.
You are one of 'em.
So it, it
makes sense.
Yeah.
Okay.
So tell, tell me what's next?
Like, what other problems are you starting
to think about or maybe do you have
releases coming that you're excited about?
What, what are you working on now?
Alex Klarfeld: yeah.
So you can download the Super Good Tracker
for free at Super Good AI current account.
One of the things I hate is.
Trying to te test out a dev tool
with like talking to a salesperson.
So you can do it for free
without talking to any of us.
We'll add you to a Slack channel
just to help you get onboarded async.
But drop us in check us out, kind
of go off to the races from there.
And then the sort of like
longer term is we want to help
the API vendors themselves.
So starting to talk to the vendors
that we're already monitoring
today to try to make a better
experience for the customers.
The current integration today is
if, if we have a special partnership
with these API vendors, you get
essentially premium support through us.
So you're the first to know if
these, these vendors have issues.
It's super good.
We'll know before the status page
updates just because we already have.
A bunch of the data going.
So like if you're having an issue,
one other customer's having an
issue, we joke, it's like the, the
age old problem of like debugging an
API is like, is it us, is it them?
We try to answer that,
that pretty quickly.
And yeah, just trying to make
the vendors have the best
experience for their customers.
And then also trying to get
into larger enterprises.
So we actually have a, eBPF agent
also in the works, which is targeted
towards like larger enterprises.
I'm happy to go into detail of that.
It's an interesting technology,
but it's like a little bit more
robust than making a code change.
It's more of like an
infrastructure change.
Mike Bifulco: Yeah.
Interesting.
So that's more, more gateway level,
presumably, or like more broad level
where maybe you have dozens and dozens
of different software stacks through an
organization and it's hard to just add
three lines in one place and be happy.
Alex Klarfeld: Yeah, exactly.
So trying to, trying to gear up for that.
So it's a agent that sits
next to your box and does the
same thing as the, the logger.
But does it on like the, the kernel
level and then performs the same way.
It's just a little bit
more effort to debug.
It's usually teams that have.
DevOps teams already set up.
But we, we had, we started with the, the
logger because that was the easiest way
I thought that we could integrate too.
Mike Bifulco: Yeah, it
makes a lot of sense.
I think one of the interesting
things about what you're working on
it super good is that you get to.
Interpret and traverse and feel parts
of the software stack, the protocol that
a lot of developers don't think about.
Like, you're, you're making some
really interesting network requests.
You're sniffing out for
certain shapes of things.
Patching, fetch is like an idea that I've
never even remotely considered, right?
But it's a super cool thing to, to be
able to do and to kind of monopolize
isn't the right word, but utilize as,
as an opportunity creator for you and
certainly a value add for developers.
Maybe this is a good, good segue
into one of the other things I was
interested in is like, tell me about
your team, the size of the team
building this thing and the tech stack.
What does that look like right now?
Alex Klarfeld: Yeah, for sure.
So we're a really small team.
There's three of us.
We're all engineers.
The tech stack is pretty straightforward.
I'm a big fan of TypeScript,
so all the web application
stuff is done in TypeScript.
And a lot of like data processing
is also done in TypeScript.
We actually utilize neon.
So I'm a Postgres stalwart.
Like I just think it's the best.
Hopefully that doesn't lose me
too many favors, but there's
a really cool technology.
Called Neon that helps, like,
does like serverless Postgres.
I'm a huge fan of it.
It's greatly increased our
developer productivity.
Being able to like clone a
database immediately in the cloud
behind your, your VPN just makes
developments so much faster.
So we use Neon for, for Postgres
and you can also like set up
multi-tenants very easily with them.
And we deploy on a combination like
render for the front end stuff and then
GCP for a lot of the backend stuff.
And then.
Just using like the core GGCP stuff
like cloud run and things like that.
Pub sub and GGCS.
Mike Bifulco: What I really like about
your product and a thing that I really
like talking to founders is when you
hear about a product that has such an
interesting and simple implementation
story and that a lot of it is just good
fundamentals and a solid idea for how
to help people and not not having to go
spend 10 years like researching a brand
new, you know, I don't know, algorithm.
Not having to do what open AI
did and figure out how to make
an LLMA thing to begin with.
There are loads of opportunities for, you
know, enterprising people to go and solve
problems without having to I don't know,
level up computer science as a theory.
Right.
And it's, it's a really cool
sign that you're onto something
that is an interesting value
add and also just fundamentally
probably a helpful thing too.
That that's super cool.
Uh, and the team size of three is pretty
impressive for what you've built too.
Alex Klarfeld: Thanks.
Yeah, they're, they're top engineers.
I'm a, I'm a big fan of them.
Mike Bifulco: Yeah.
Cool.
Well Alex be, before I let you move
on, I've got a, a couple of questions
that I wanna make sure I don't skip.
Um, where's the best place for
developers to find super good
online and to get started with it?
Alex Klarfeld: Yeah, for sure.
So you can check us out@supergood.ai.
Mike Bifulco: Cool.
We'll send them that way straight away.
And maybe what's a sign that
someone should be considering using?
Super good.
Alex Klarfeld: If you've ever
got a bill that someone has, I.
Could been very confused by that's
one if you have a horror story in
mind where you're like, this API
caused me to wake up in the middle
of the night and, and heartache.
That is, that is a good sign
that we might be helpful.
If you have more than, I'm gonna call
it like five APIs, like if you're, the
best customers that we have are like,
kind of like they've, they've started
to think about their unit economics.
Maybe they haven't like implemented
things yet, but if you're like a smaller
company, you probably are just like,
Hey, I'm just trying to, trying to grow.
So I don't care that much
about like, watch these APIs.
We're just gonna chuck stuff at it.
Which, which I've been in that place too.
So typically like larger
companies that are just starting
to think about this problem.
And also if you're dealing
with international APIs
we actually have a pretty.
Large contingent of, of
international vendors that we've
been working with to monitor.
They are working pretty hard
to get up to snuff with some
of the, the US based vendors.
So that's a good, that's
a pretty good one.
So anything expensive too?
Is, is, is great.
Like the Twilio stripes plaids.
Oh.
If you're working with any credit
bureau also I'd love to talk to you.
They, they have a special place
in my heart 'cause they've been
pretty difficult to work with.
Mike Bifulco: No doubt.
Yeah.
Wow.
That makes it super easy.
If, if you have just listened to
Alex and you, you fall into any one
of those buckets get in touch stat.
Alex, then where's the best
place to find you online?
Alex Klarfeld: You can find me on
LinkedIn, you can find me on Twitter.
I respond to dms on both.
So please, please hit me up.
You can find me on GitHub too if
you wanna watch me write code,
but that's a little less exciting.
Mike Bifulco: Well, I will make sure
that there's links in the show notes
to everything we've discussed ways to
get super good and to you and Twitter
and LinkedIn and all the other places.
Alex, I really appreciate you
coming and hanging out and telling
us a little bit about Super Good.
Thanks so much for joining.
I really appreciate it.
Alex Klarfeld: Yeah.
Thank you so much, Mike.
I appreciate it too.
Mike Bifulco: Of course, Alex Feld.
We'll catch you next time.
Thank you.
Alex Klarfeld: Alright, see ya.
Mike Bifulco: Bye.