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.