Mike Bifulco: [00:00:00] Hello and welcome back to APIs You won't hate. My goodness, it has been a while since I've recorded a podcast. My name is Mike by ko. This is the first in a series of episodes I'm doing with API developer product builders. And I'm really thrilled to be able to sit down and talk to someone who I've known for quite a while now actually, because of APIs you won't hate to get an update on product lifecycle, what's going on in, in the world with his products and whatnot.

So I'm sitting down today to chat with a Alex from Super Good. Alex Clarkfield, thanks for joining us so much. I really appreciate you being here. How are you doing? And where are you calling in from today? 

Alex Klarfeld: Thanks for having me, Mike. I'm happy to be here and yeah, I'm calling in from San Francisco.

Mike Bifulco: Man it's really good to see you. I was, so you and I have recorded a podcast before for APIs you won't hate. I was listening to it earlier today. We chatted last in August of 2024 and almost verbatim your pitch for super good,

was, it's a couple of lines of code that you include in your code base to be able to maintain and monitor the spend on APIs within your product.

Alex Klarfeld: That's right. [00:01:00] 

Mike Bifulco: I get the sense that a few things have changed between then and now. In fact, I know a few things have changed between then and now.

Why don't you gimme the elevator pitch for super good now, and then after that I'd love to hear about how you got from where you were then to where you are now. 

Alex Klarfeld: Yeah, absolutely. So what we do at Super Good is we generate and maintain operative word, maintain APIs for products that don't have them. And we do this by means of semi-automated reverse engineering and we just focus on enterprise portals behind a login.

And we focus in like a few verticals, even though the platform is like fully agnostic. But like prop tech. Government, tech, legal tech, healthcare, anything you can imagine with a very old enterprise portal. 

Mike Bifulco: Cool. Yeah. So that's like fairly different, right? Yes. We were talking about monitoring costs before, and now you're into maintaining APIs unofficially for services.

In fact I think if I went to your website right now, the. Top line on your website, your H one says unofficial APIs officially maintained, which is that's right. Captured in four words really well. Tell me how you got [00:02:00] there. 

Alex Klarfeld: Yeah, absolutely. So as you noted, we started with this observability product.

The idea behind the original version of Super Good was you drop in a few lines of code and we tell you which one of your APIs are costing too much. How much, like which ones are breaking all the time, what's like garbage and what's not. And we launched this and it turns out that pointing out problems with APIs isn't as good as fixing them.

So we were plagued with this like existential question, which is just what do you do to actually fix the APIs? And when you're like, the API's obfuscated for you most of the time, like it's a black box on the provider side. So you can't really do much if something breaks. But we had a few, like very devout customers and we kept trying to figure out like, why, like why did they love us so much?

So basically what we did is I rolled up my sleeves with my small team and we dug in to figure out like why they liked our monitoring products so much. If we like really, weren't able to fix them. And it turns out [00:03:00] that what we were monitoring for them was this like whole slew of homegrown scrapers and like unofficial API products that they had built internally and they just had no in instrumentation and monitoring around.

So we went in there and just started helping them build and maintain these sort of like unofficial scrapers and we're like, Hey, there's like actually something there because the monitoring product. Was really helpful in just figuring out what was going wrong. And we hit this tailwind of cogen, I think some of the latest like cogen models were released like, like around that time.

And then basically started off building like. Simple scrapers, which you know, is a, I think scrapers are great, but they're like a lot of them in the world. And we started getting more and more requests from this customer and others were like, Hey, your scrapers are cool and all, but can you actually get me data behind the login?

And that was what kind of kicked everything off, is we had this like initial observability platform that can like arbitrarily monitor and inspect network [00:04:00] calls. And then we were using. Like this new tooling that we're building to build APIs on top of that. And it ended up being like a really good product to build an API.

That by definition is will change or might change and like. Is not monitored and the core observability product plugged into that makes it a lot easier to deal with at scale. 

Mike Bifulco: So what's interesting about that to me is obviously there's some need for that. So people are dying for APIs for all sorts of things that will never exist or maybe haven't existed or haven't been updated. There are also, we're living in a world now where.

LLMs and agents are very popular and I'm familiar with at least a few tools that I would describe as you give an agent a task you like, give it the description of what you want it to do and it will go and figure out how to do that. That feels subtly, but importantly different from I have this.

Shape that I send a post request to or get request to that always does the same thing and the middle bit, the black box is the LLMs doing the magic in between for me or the code gen doing the magic in between [00:05:00] for me. Can you tell me like it, do I have that right? Is that roughly what's going on here?

Alex Klarfeld: Yeah, it's basically like we're using cogen more as like a tool to be able to spin up these APIs rather quickly and then using the agents to debug the code that is generated. That, that is basically it. But I think the actual special sauce that we have is the original observability product is essentially we built like all the rails and all the instrumentation to be able to use any of the lms like most of, most effectively.

So the way that it works is we have this tooling that we're working to put in the hands of any developer. But right now all our customers have access to it. But we kind of dog food it and make sure it's really good. But we can spit up an API in 15 minutes. Really. It's just like QAing the code.

And then we can spit up like a whole suite of them. And then the code that we generate is built on top of our in-house platform. So like every network call is instrumented. All the sort of we have an internal helper library that we use that makes it very easy to spin up. And then once that code is, and it's also deployed on our platform, so like we'll [00:06:00] handle the capcha.

Anything that you like need, you don't, basically don't need to think about it because of our helper libraries. But it's deterministic code that runs. And then what we're doing behind the scenes is just monitoring that code, using the observability platform to figure out like, has something changed?

Has something broken? Are you seeing a request? And then basically we build up a knowledge base for these unofficial APIs over time, where it's like we have access to network calls, we have access to what's being done and we can essentially act on it now to change things on our end. Or to alert the customer that they're inputting data wrong.

But it's the observability is the perfect platform for unofficial APIs because by definition there's no other way to interact with them outside of trying it and seeing what works. 

Mike Bifulco: Sure. And so your customers then are, they're running deterministic code. They're not actually running agent or LLM driven code, but their code is being maintained by what I would assume is a fleet of really smart scripts that, fire off agents and do things of that nature.

For your end users. The observability means that I [00:07:00] can send my, my get request your system will run the same code. And if things go wrong, they go wrong in a place that's pre predictable and that's instrumentable and you can say okay, go focus on where this thing broke and update that thing.

Is that vaguely right? 

Alex Klarfeld: That's right. And like the other thing is we don't hide any of the reverse engineering from customers. Like I think reverse engineering is cool, but the real like value add of our product is being able to run. Products that are reverse engineered in production. So you can actually see in the platform of every single step that we're doing behind the scenes on the target platform.

It not only makes it easy for customers just understand what's going on, but it makes it easy for like agents and everyone who's like trying to debug the code to see what's going on. So I think the like sort of transparency of it. Probably the most important. 

Mike Bifulco: Yeah. So let's talk about what your customers end up getting.

Then they presumably get some sort of API that they have access to that has some description, maybe, API description, maybe an SDK, whatever that looks like. They have a dashboard, it sounds like a dashboard that you maintain. Or is it more like they have a. What is [00:08:00] it called? Open Telemetry hooks to get their, the observability stuff out of it.

What's the actual end user experience like there? 

Alex Klarfeld: Yeah. What we're trying to make is if we were building official APIs, it would be the greatest platform to manage and monitor official APIs as possible. So basically they get an ap, a native, as close as possible to a native, like API experience.

Which means like full documentation of every API, we spun up to the best of our ability to like, understand what's going on. Within these products, they get full access to our observability platform, which is basically not only like full logging, but full like instrumentation of every single network call that is happening behind the scenes.

And then also like explainers of if something goes wrong. Why did it go wrong? How can I fix it? Do I need to change user input? And then as well as one of the things that's really important for like unofficial APIs is tap into this authentication problem. So we have a whole other product that's embedded in this product that just manages authentication for these like target [00:09:00] platforms.

So we basically let users. Spin up what our like authenticated users in the platform that we can then execute API calls on behalf of, or network calls on behalf of. And those accounts have like real phone numbers, real email addresses. That are all like, fully managed within our platform. 

Mike Bifulco: Okay. So a I'm gonna go for an extremely contrived example here.

Yeah. But if I wanted to use Super Good to make me an API for the Great British Bake Off. Okay. Gimme all information about it. Literally a TV show.

Alex Klarfeld: Okay. 

Mike Bifulco: Gimme the cast of the season 12 show. I might have a. A TypeScript native, SDK, where I have like great British bakeoff season, go get season, whatever, get me the cast.

It'll come back and gimme that. But the other interesting thing about it too is then like British Bakeoff doesn't have a user system, an access system and authentication or token system. You're also giving me that, right? So I have now like a, what would you call it, like a service account or something that I can use to access an API that doesn't truly exist in, but is like in the ether between me and the [00:10:00] TV data.

Alex Klarfeld: Kind of, you can think about it as like platform specific. So let's say all the data you need on the Great British Bakeoff is on IMD imdb.com So we would basically bake an API for IMDB where let's, I don't know if IMDB supports this natively, but let's say you have your MIC user and then you're like a, a TV producer or something like that.

It's all like naturally combing through IMDB and you have the ability to add an assistant to the IMDB platform that can then fetch data for you on your behalf, look up cast members, look up their bios. What super good does is essentially we'll generate a service account and essentially access your assistant to get added to the IMDB account and then we can essentially spin up.

A set of APIs on top of imdb if they don't already have 'em, if you if IMDB already has them or any platform has them, we just say, please use official APIs. You do not really use us and you shouldn't use us. But if there are no APIs, you can essentially tell us like, Hey, we want an API to fetch the, give it a cast member's name, give their bios [00:11:00] or like gimme the information they've done in the past.

Like anything you could manually do on IMDB related to Great Bridge Bake Off, we can turn into an API. 

Mike Bifulco: Sure. Okay. Yeah. I'm really interested in the breadth of these that you've worked with. I know you mentioned a few verticals before to whatever ability you're able to share. 

Alex Klarfeld: Yeah. 

Mike Bifulco: I'd love to hear like your ty, your typical customers or what your new customers are looking like.

What are people trying to do and getting in touch with you about? 

Alex Klarfeld: Yeah, it's typically it's not strictly this, but it's a lot of like new software trying to build new software companies trying to build in old industries. So it will be like modern prop tech that's trying to sell to property managers.

And these property managers have the oldest. Like management portals, they, the property management systems that you can think of, and those PMSs are not letting anyone in. They have this crazy walled garden, but they're like the core brain activity of every single customer that you interface with.

And there's no way, and the thing is our customers don't wanna move them from the [00:12:00] platform. They just wanna meet customers where they are. But these platforms make it impossible, basically, intentionally or unintentionally to give them access. So we basically. Make it fully accessible so that new software companies or companies just trying to integrate with like older institutions can automate a whole lot more than they previously could.

And essentially not only automate, but like onboard new customers who like operate within these like core brain centers that like no one has ever heard of. That's like our core use case or like old enterprise portals that are fully locked down. 

Mike Bifulco: Sure. And I feel like you hear lots of startup pitches that revolve around that.

And in fact I run a company that's very much like that craftwork is a, is yeah. New tech in a very old industry. We work in painting. And so you and I have overlapped in that world a little bit too. We have lots of data that we consume or lots of need, data needs that we would love to have, official unofficial APIs for things.

I expect there's probably also other, I dunno what you call that service industry stuff in this world. PropTech makes a ton of sense too. Yeah, 

Alex Klarfeld: yeah, that's right. [00:13:00] Especially coming from divvy. Like we dealt with these systems all the time and like I had to do this at Divvy. A lot of times. It's just there's no other way to interface with this old school I don't know, like deed management system or title. There's just no other way to do it. Unfortunately, 

Mike Bifulco: yeah. Yeah. Man you're speaking to my heart in so many different ways right now. One of the weird things I found myself doing is I grew a fascination over the last year with something called urban infill lots for sale.

Okay. So in, in big cities cities of all sizes, I suppose there are often like small, awkwardly shaped plots of land that never get sold. So you can think of it as like a. Pizza slice shaped piece of land between two buildings if they're on a corner or something that like isn't really owned. It's owned technically by the city, but it is something that is like you could purchase.

Okay. And there are many places where you could feasibly buy a really cool piece of land that's I don't know, 50 square meters, like small, but you could put a little tiny popup there if you could find a way to, to get to ownership of that. And many cities you can go and find like. Baltimore and Boston and a few others that I've gone and looked through [00:14:00] have these weird little urban infill things that you can go and find Cool and put an offer on.

There's a whole auction process for it once they're discovered. But the tooling for it are these fossilized GIS systems that are like really old CGI webpage that are you like click to zoom and the whole page reloads a little bit more zoomed in. It's like pretty painful to get through, yeah, that's, that sounds like the kind of thing that, if there was an API for that, I'd be doing this all the time. I would be finding these tiny little places and running a string of, I don't know, coffee shops or something, yeah, 

Alex Klarfeld: It's like that's our bread and butter. It's like the weirder the platform is, the better it is for us. It's a lot of stuff built in the early two thousands by the kids and consultants. No shame to McKinsey consultants, just like times have changed and like technology has improved, but those portals are bread and butter.

Mike Bifulco: Of course. Yeah. If we had all the tools we have now in the early two thousands, everything would be better. That's just the nature of the beast as these things get older. Are there any particularly creative use cases you're aware of where consumers of super goods APIs are doing 

Alex Klarfeld: there?

There has been a few, I'm trying to think. We, [00:15:00] like early days we were helping like small app developers, so there's, one woman who was building, she just had a baby and finding a nursing consultant. She basically built an app for like new moms who wanted help with nursing. And apparently there is a full government, or I think it's a federal or a state man run database of like lactation consultants.

That. Like moms can plug in their name and their information and then we'll pull up this like old janky website to find like lactation consultants nearby. So we built an API for that, just to make it easier for her to like embed inside of her application. That one was pretty cool.

That one was interesting. And then most of the stuff we deal with is it's cool to see how like the old industries are. Developing, like we support like a lot of like legal tech use cases. So I talk to a lot of like lawyers and people building for lawyers and I've always been impressed by just like how sharp, like lawyers are sharp, but I didn't realize like they're [00:16:00] using a lot of the new stuff that like you and I might know.

So I'm getting a lot of questions around like how they can plug their APIs into MCP servers that they can then use for open qua or something like that. Which. Is awesome. I just didn't expect like lawyers to be asking me these types of questions, so that, that part is also really cool. 

Mike Bifulco: Yeah. Can you tell me a little bit about the shape of a new customer for super good?

Like how big is the organization? Where are they in the, I don't know, building a business life cycle? What does their use case look like? I guess in terms of spend, budget developer profile whatever you're able to share there. 

Alex Klarfeld: Yeah, it's basically they're we support everyone from like seed stage to like multi-billion dollar companies like up to like banks and things like that.

Typically customers will use SuperGrid for one of two reasons. One reason is they're trying to use our APIs to plug into some orchestrator to automate a back office task. So it's like they have a BPO that logs into this portal to like. Register truckers for insurance, and it takes a bunch of time and it's a pain.

So they'll [00:17:00] ask us to build an API against the insurance portal, and then they'll build software around it to, to automate it. The next one is the only other reason is trying to, onboard new customers so that it's like, Hey, you live inside of this system. For example host is a POS that we may or may not yeah.

Have API support for. A lot of times like, like if you're building a restaurant tech and you're trying to like onboard a restaurant, toast system is not really easy way to do it. You should ask Toast for an API. Anything that I say on this podcast, you should ask the platform for an API first.

If they don't give it to you or don't want to give it to you, call me. But you should ask first. Of course. But let's say they don't then it's a good disclaimer. 

Yeah. If they don't how else are you gonna onboard like a customer's like restaurant system? There's like literally no other way to do it.

And that's typically when they call us. 

Mike Bifulco: Yeah. Okay. And so if I'm a developer listening to the podcast yeah. And I'm hearing about super good for the first time, what's an indication to me that I should probably head over to your website and super good.ai and get in touch? What what are your [00:18:00] next users look like?

Alex Klarfeld: Yeah, exactly. So it's, you have been tasked with building an integration with a platform that doesn't exist and your developer like, I don't know how I'm gonna do this. There's no API docs, I don't know what to do. The next thing that you've probably done is like Google, like how do people do this? And a lot of times you'll get pushed with browser automation.

So I think there's a lot of like really neat flashy demos that are like. Hey, add a browser automation thing. It'll do all the things that API can't can do. Spoiler alert, browser automation is terrible for enterprise use cases and like really doesn't make sense, but as a developer, you should try it.

Like I tell all like our new prospects and customers this, it's just try it and call me because there is like a time and place for it. If you're doing like low volume, you don't need. Things to be that reliable, like close enough for jazz is like good enough. Then go nuts with browser automation.

But typically once you've gone through those two things, that's when we get a call. And typically I tell people like, if you want our APIs, two things, one [00:19:00] of two things have to be true. You have to be able to, you have to be doing like a high volume task where it's like you need to make like thousands of calls a month in order for it to make sense.

Or you need to be doing like a high value task where it's something that like absolutely can't break. Or if it does break, you need to know exactly what went wrong, those two things. Browser automation is like really bad at it's really bad at high volume tasks. It's really bad at high value tasks.

It's meant for consumer cases, like kind of one-offs. But if you have one of those two things, you should call us and then we can essentially, spin up an API for that platform. And you, 

Mike Bifulco: yeah, that's pretty cut and dry. And in terms of, consumer languages your developer, consumers TypeScript, Java, like what are you producing SDKs?

What languages are you compatible with? 

Alex Klarfeld: So we are, we're totally agnostic. Everything is just

Mike Bifulco: yeah, 

Alex Klarfeld: normal, restful a HP calls, so people like, it's hosted through us. So for now, so this basically like folks will plug it into just about anything. Lot, a lot of python, a lot of type script. And [00:20:00] then just starting to get more folks who are plugging our APIs into mCP service. I'm not sure what exact language is, but like seeing agencies or APIs have been really fascinating lately. There is like clearly like a tool use gap that I've seen from like 

Mike Bifulco: yeah. 

Alex Klarfeld: Agents nowadays. But it is interesting to watch that part evolve a. 

Mike Bifulco: Got it. Okay. And so if I'm looking at this, I feel like you just qualified really well that a high volume or high value task also has some implication that this is someone who has a need for something that will derive value pretty rapidly.

What does that mean for super goods pricing structure? Is there like a free onboarding? Is there how do you onboard new customers and how do you get them in,

Alex Klarfeld: yeah, so basically make sure that we can put our money where our mouth is. So we offer free trial, we will build the APIs for you for free.

We will QA them for free. And basically you test them out for 14 days and if they work as we promised, they would work. It converts into a regular contract. And the way we actually, price is quite a bit different than a lot of other folks in this, [00:21:00] we actually charge a core platform fee and maintenance for the actions that we support on top of your API, but we try to make usage as cheap as possible. So the idea is it makes it much easier to scale with us. And we also charge cheap because we can a lot of times if you buy like a solution that is browser. Browser automation focused, they're gonna charge you like probably a couple bucks or buck 25 or something per call.

And it's because they have to, like browsers suck up like a ton of bandwidth. They basically like downloading whole pages to perform tasks that just

, 

Alex Klarfeld: Doesn't really make sense. So they might be like cheaper to start, but it just like breaks down at scale. We were like relatively same price set to start, but like the idea is you scale with us like pretty seamlessly.

Mike Bifulco: Got it. Okay. And tell me about your perceived, roadmap. What do you think is next for super good? 

Alex Klarfeld: What I would like to get to is getting, we have to do a little bit of filtering when we get [00:22:00] customers to make sure that the use case is like ethical and it's like something that we want to do because there is like inherent people want to reverse engineer APIs for all sorts of reasons, but Right.

Once we get to this, like KYB that we can onboard developers, we want to make the sort of like tooling that we have available to our existing customers. Much easier accessible to everyone else. So anyone can use our platform to both reverse engineer and deploy these unofficial APIs for target platforms.

And if it's a platform that we've already have built for, make it extremely easy to spin up. So you actually don't really need to use our tools. You can, piggyback off of some. Concept of code that we already have. One of the interesting things about our customers is everyone uses the platforms that we build for differently.

It's like the core, the same core pipes, like authentication is generally the same, and like moving data is generally the same, but like a lot of times you'll have like different schemas or like. Different developer ergonomics of what they need and for unofficial API, which is representative developers everywhere.

But that's another part is we make it really easy for you to like, use, set [00:23:00] like core building blocks that we have and bold them into the ergonomics and the API calls that you actually need. 

Mike Bifulco: Yeah, it makes a ton of sense. If you're building the right primitives, then, people can build what they need and use it as they need.

So tell me about what's next.

Are you hiring right now? Are you looking for people to join the team? 

Alex Klarfeld: Yeah, we have a small mighty team of three of us in San Francisco and one a person remote. We're onboarding customers like crazy, which has been awesome. And we're actually looking to hire our first non-engineering hire.

And I say that as like with an asterisk, which is like. The person that we bring on is likely gonna be like a former engineer or someone like highly technical, but there's a whole lot of like non-core engineering work that we need help with. So looking for someone who's just like excited about like this space and where things are going, and like the mission of just like making the web like truly interconnected.

And that's currently what we're looking for right now. 

Mike Bifulco: Got it. Okay. And I have one more question for you before I let you go. Yeah. Tell me a little bit about the we [00:24:00] talk a lot on APIs. You won't, Hey, this comes up fairly often. We talk about the sort of green angle of things, so the environmental impact of things that we do.

Yeah. I think it's really interesting to think through your product from an environmental angle because a solution built by consultancy in 2003 probably has a whole lot more implications on the way that energy has been used to build and develop that thing. But there's also the realities of building, developing and maintaining things with agents and LM workflows that has some implications, at least on whether or not you're building something that's efficient and a good thing for the planet.

Persuade me one way or the other. The right direction you're headed in is worth the expenditure,

Alex Klarfeld: for sure. I, so first thing I'll say is every code that we like LMS are good, but running them in production, like to do everything is wild to me. So like part of our pitch of like why you should use us for API is like, why have an L led like reinvent the wheel, like determinist to code that you're like actively monitoring and maintaining is a whole lot more efficient.

You don't have to use a single token once you write the code, you just need to [00:25:00] like. Continually monitor it. And like even when you're monitoring things, like you could do this, like most of our stuff is done heuristically, where it's like LLM only kicks in if it actually has to, but there's a whole lot of filtering that you can do in order to get things done.

So first thing is I think deterministic code is generally good for the environment. Not having LLM reinvent the wheel every time is good. The second thing is I think browsers are like a tool that's meant for humans and they're not a thing that's meant for machines. Like the amount of bandwidth that they suck up is wild.

It's like it's unnecessary and it's wild. It like truly blows my mind that people think that browser automation is like the future when it's like definitely not. Sucks up a ton of bandwidth, sucks up a ton of memory. Like you have to run Yeah, like a machine. And the other really interesting part is as the anti bot detectors and the caps get better the browsers have to actually start pretending to look more and more like a machine. So like a lot of times you could, beforehand, you could get away with oh, we're just running like headless chrome, whatever, like saves on compute. But [00:26:00] like you.

Can't anymore because the CAP two provider is like trying to figure out if you can render graphics in order to figure out if you can render graphics. It will have to render graphics like at some point, which is just like gonna be more and more expensive. So I think there's like actually gonna be like an energy suck of the capture providers making things harder and harder, and the LMS and the browsers need to ramp up their energy consumption in order to beat them, which just seems wild to me. Just it's like an unnecessary abstraction that's not meant for humans. Yeah. Or sorry, it's not meant for l oms it's meant for, 

Mike Bifulco: right, of course.

A really interesting part of that too is that a lot of people aren't familiar with how heavy it is to do something with a browser. A lot of people probably similarly, haven't used a headless browser or a, a. Programmatically driven browser to do something, it's slow and like garbage.

In comparison to send a fetch, get a response, like curl is a billion, million, trillion times better than that. And if you have never tried to write a test that uses playwright or one of those things to run through a, a like [00:27:00] user critical experience. It's really slow. It is very slow.

And that slowness is cost to you, cost to the environment. It's heat being expelled somewhere. It's bad news. The other side of this too is I forget what it's called, but there's this like theory of AI where once we really get to a GI we'll have a whole d different set of problems to get to, but along the way.

If we're giving AI rules where it's like your job is to do this thing in the most efficient way possible, they will eventually figure out efficient ways that we haven't thought of. And in many cases, the thing I always hear is okay, you tell this thing, here's how you get a high score in this.

We're playing a game. Your job is to get the high score as the agent. And if the agent fi figures out that it's hard to get a high score, it'll just turn the game off like. I a little bit think that will be the eventuality for browsers, right? Oh, it sucks. Yeah.

Hundred percent browser stuff. Yeah. It's fascinating. You have definitely persuaded me in that sense. And I think the nugget in the middle of that too is, look, deterministic code is just far better than waiting until the computer like uses the black box to figure out what comes out the other side.

Alex Klarfeld: Exactly. And no [00:28:00] more browsers. I think it's we'll just keep it for humans. 

Mike Bifulco: No doubt. Yeah, man, what a refreshing perspective to hear. I'm glad. Yeah I'm really into that, Alex. Cool. What's the best way for someone to get in touch with you? How does someone find you, Alex? Where's the best place to find you online? 

Alex Klarfeld: Yeah, so all over LinkedIn. We're always like posting stuff on there. Twitter is just my name, Alex Feld. And. You can also email me alex@supergood.ai.

I respond to everything, so just hit me up. 

Mike Bifulco: Cool. Sounds good. And obviously what's the best way to get to? Super good, 

Alex Klarfeld: super good.ai. 

Mike Bifulco: Awesome. Alex, thank you so much for being here. I really appreciate catching up with you. I'm fascinated to see where things go for you. You're welcome to come back and hang out any other time.

And I'm sure we'll have lots of stories to tell between here and there. Thanks a ton for joining. I appreciate it. 

Alex Klarfeld: Yeah, thanks so much, Mike. It was great chatting with you.