Transcript

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. And this promoted guest episode of Screaming in the Cloud is brought to us by our friends at Katanemo, who is—when you talk to small startups, like, “Who should we talk to?” They invariably look around the room, figure out who they should throw directly into the grist mill, and in this particular case, they have selected Salman Paracha, who is the founder and CEO. Salman, thank you for joining me.

Salman: Hey, thanks for having me. Second time.

Corey: It is. And every time we talk, it seems like there has been an interesting progression in your career. Originally, when we first started talking, you were the GM of the serverless application repository at AWS, and of AWS SAM, the Serverless Application Model that most people know because of the giant psychotic squirrel running around the expo hall at events. Then you went to be a group VP at Oracle Cloud, and now you look around the landscape and decide, you know, what I’ve done my entire career? Worked at big companies where everything is, you know, convenient in certain ways. And that sucks. I want everything to be three times harder, at least, so I’m going to go start a startup of my own. Presumably. I’m assuming that is the thought process that led you here. What’s the actual story behind why you decided to leave giant corporate entities and go to a small startup?

Salman: Thanks for that intro. The primary reason to sort of pursue this dream was something was pulling at me for the past four to five years. As a person who considers himself a builder, the most happiest I am when I’m actually trying to ship software out for customers. And so, I’ve been pulling on this thread for a very, very long time, that the world of the modern reference architecture, as it goes more microservices and explodes in the face of developers, has gotten to a point that we are now being inundated with all these micro-primitives, if you would, on infrastructure that actually slow the rate of innovation down. And why hasn’t there been a move and reversion to the other side?

And so, as I looked around, and at my time at Serverless particularly, where we were trying to champion this idea of serverless compute where you don’t manage your servers, I kind of was ruminating on this notion of how do you get to zero infrastructure? And the idea that how can we actually orchestrate out all the complexity behind the scenes and you can truly focus on what your application does. And in that part of the journey, I’ve been chatting with developers across swath of industries and varying degrees of sophistication if you would, and the thing that emerged is that the most complex, perhaps the most complex piece to build in the cloud is a SaaS application. And there’s inherent complexity in sort of thinking through the various concerns of the shapes and sizes of your customers that you’re serving, the security and safety controls that you have to give them, the operational burdens that you take to serve a very large customer versus a very small customer who is perhaps in your free tier.

And so, I was pulling on this thread for a very long time, even at my time, somewhat, at AWS, having—I chatted folks like Twilio and Slack at that time, and I said, “I think there has to be a much, much better way.” It cannot be more; it has to be less, and that less is actually getting us closer to what we believe is the future of cloud infrastructure, which is no infrastructure. So, that’s it. I mean, I think the core thesis was, “Hey, if I’ve operated at this intersection of hyperscale cloud infrastructure and SaaS applications for the past 20 years, what is the compression algorithm that I can apply and give to developers so that they can truly focus on building something phenomenal without having to worry about the complexity of the infrastructure, the security of the scaling of the operational, and the access logs, and all that stuff that they have to today focus on?” And then I’m very fortunate to have had a phenomenal team that have joined and humbled me in my journey here.

Since last year, we have folks across the spectrum who have built these things at scale and at Lyft, at Dropbox, at Meta, at AWS, at Cloudera, and et cetera. And so, we’ve been really fortunate that we have a very firm belief of where we want to take the future of infrastructure and who we want to serve in that market segment. And I said to myself, I don’t think I’m getting any younger. My parents, my South Asian parents, perhaps they’re going to be more happy to see me sort of fight it out and battle it out versus just naturally climb the corporate ladder. Nothing wrong with that, of course.

Corey: It’s not too late to go be a doctor. I say that as someone who grew up in a Jewish home where there were certain expectations and pressures placed upon me that I continue to disappoint four decades later.

Salman: Yeah, so anywho [laugh], on that front, so I think I’m kind of living to the expectations I had for myself 20 years ago when I joined the workforce, and I now have the great fortune to build alongside these amazing builders and see what we can unlock for the developer community.

Corey: One of the challenges with the approach that I found historically has been Heroku did something very similar and then everyone tried to build the next Heroku, except for the company that bought Heroku, they were content to let that thing sit and never think about it again, for whatever reason. But another example would be something like NPM, the Node Package Manager, where it abstracts away stupendous complexity. You tell it to npm install for some project and it just starts scrolling huge amounts of text past and doing all kinds of work and your computer fans start screaming, and you’re like, “Wow, it’s doing an awful lot of fascinating stuff underneath the hood, and I really hope this works. If it breaks halfway through, I haven’t first idea where to look under the hood to make sure that this actually works and doesn’t break my application.”

The problem that I have historically with the things in this space is it requires a certain element of trust. That said, looking at the things you’ve done before, the places you’ve been, I don’t have to explain that to you. You have clearly spent your entire career in environments where mistakes matter because they’re going to show very quickly to an awful lot of customers if they wind up getting out there. That feels to me like it’s a significant competitive advantage versus, not to be disparaging, but a couple of founders fresh out of a boot camp who have never worked in the industry before, but they have an idea, gosh darn it, this is what they’re going to build.

Salman: You know, you’ll find builders, and you’ll have builders surprise you. And I, you know, salute all those who come out and start something new. I have a whole bunch of respect for that, just the courage that takes it. But there’s an advantage that the team has, and we’re very fortunate on having that advantage, having seen things break. And I think we’re at this inflection point, perhaps now that there’s been an incredible amount of effort done in the open-source community relative to [dis-established 00:06:56] standards.

Like if you imagine, what, 25+ years ago, when HTTP and HTTP 1.1 came out, that created an explosion of people hosting these web services and HTTP-based applications. I think we’re at the point where we can preserve the developer experience, preserve the operator experience, but never have to sort of have you tinker in the bowels of the infrastructure … to build a SaaS application. And I think that the interesting part of this is knowing how successful these projects can be, but also how complex they can be to manage. But if you (the developer) can just focus on dev experience and operator experience and ask what’s the most pressing question to answer, which is…Can you know who (your customers) are and what they’re doing in your system, and have the ability to shape their experience versus shaping the infrastructure?”

I think we’ll be in a much better state as an industry, we’ll be much happier developers, we’ll just be in a much higher place than we are today. Where as I said earlier, which is the modern reference architecture of microservices perhaps gives you some powers, but it really explodes the amount of choices and results in this massive drag on innovation. And that’s that part of the lessons and learnings and insights that we have and we’re going to compress that, hopefully, on behalf of developers as we build out Katanemo, particularly, you know, going towards this future of no infrastructure, zero infrastructure. So yeah, all respect to everyone who’s building. You know, we’ve had the good fortune and we hope to pass that fortune back in terms of a product experience.

Corey: This feels like a problem that never really goes away, at any scale, for that matter. I want to build out something new. Maybe it’s just a ridiculous static site. Maybe it’s some serverless-powered shitposting app. I have several of those in existence.

And every time it’s like, “Oh, you have a great idea for an application. Cool. Step one: do a whole bunch of infrastructure provisioning nonsense along the way first because that’s going to be the important thing to get done.” And then, only then, do you get to start getting into the application logic and the rest. And it always feels like boilerplate, but it’s specific boilerplate, in that it has to be right for this environment with this constraint and this use case, and it just feels like it’s undifferentiated work that I don’t want to be doing.

Salman: I think that actually is magnified to a certain degree when you’re thinking about an enterprise-grade SaaS application. And my impression is it’s magnified of perhaps an order of magnitude more. Because in any modern SaaS experience, you would have to think through the list of concerns relative to your small customer base that’s trying your product, teams that are relying on your experience that their workflows don’t break, or perhaps large enterprises who you’re trying to serve and upsell to. And that inherent complexity then gets baked into the choices on “Hey, should I have more nodes or should I have more concurrency or should I have more isolation boundaries? How do I think about security for multiple customers within my system?”

And I think that’s the really hard nut to crack. And we’re focused there first because we believe we can serve that community really well, get off on the get-go, and then create the right level of experiences, perhaps for general business-to-consumer applications as well. But this problem, I think, it’s magnified even more for the [unintelligible 00:10:01] dot community that’s trying to start off with a developer-led motion but naturally wants to upsell to teams, organizations, and enterprises with their suite of services, perhaps a next-generation ChatGPT, if you would. So yeah, I’m with you. I hear you, and I think the problems amplified, in our view, to that other community that sort of struggles with this and has to hire specific talent to build that stack out.

Corey: I have to ask, because I alluded to, it seems like every company has been trying to build the next version of Heroku, which when you distill down what the value would actually deliver doesn’t sound that far removed from what it is that you’re proposing to build. Hasn’t this been done yet?

Salman: So, I think the way we think about this problem is it’s across multiple layers. And some components to this problem that’s worth talking about. Of course, when you say zero infrastructure and no infrastructure, what does that even mean? Like, I think people naturally get confused. So, three weeks ago, we actually launched what we call our first set of capabilities on behalf of this community as we break things out in components, which is zero-trust capability.

So, if you think about the space, there’s a whole bunch of these undifferentiated essentials that you need to build something meaningful and serve users, teams, organizations, and enterprises. And Heroku is this approach was an abstraction—and a fine one, if you want to build a general purpose app that is just serving the consumer, perhaps. And we’re sort of taking a very different position. We’re saying we’re here to solve you if you’re building something that’s going to serve developers, teams, or organizations. So, we are very different in terms of how we’re approaching the market relative to what we want to go solve for.

That’s just number one. And B, as the thing that we recently launched, is how do we break this problem down on behalf of the community and be targeted to solve a particular problem? So, when I connected with developers in my journey for the past six to nine months as we’ve been in business, is that they felt that the modern state and fragmented nature of identity and access management is really complex for their application. Why? Because now you have this very interesting usage patterns for your applications.

There’s no longer users using something you’re built. There are, of course, as I mentioned, teams, and of course, there’s an enterprise component to this. There are machine keys for your APIs. And all these vectors now of uses all naturally become a threat vector that you have to protect for and they have to be neatly thought through from a access management strategy. And so, what we’ve set out to do is, like, how do we unify this experience today, and solve a real problem, which is you can effortlessly onboard any customer of any size and upsell through zero-trust capabilities like role-based access control, attribute-based access control, and give your customers the ability to achieve least privileged access?

So, meaning how do you safeguard the most protected resources off your SaaS application and make sure they will be safeguarded, but if your users want to create for more sharing and collaboration experiences, you have the means for them to go achieve that without having to build custom logic, custom code, and perhaps spend, many months cycles and perfecting it? And that engineer that built it, and when it left, who’s going to take over and maintain that piece of code?

Corey: Not to mention you’re going to get it wrong, and as a result, mistakes there have security implications that can be dire.

Salman: I think that’s where developers tell us, this is why—you know, I was talking to one potential developer the other day and the thinking was, hey, you know, it was really hard for us to, perhaps, let go of these security controls because we want to build them ourselves. And I asked them this question: “Where do you store your username and passwords for your applications?” Like, “I don’t store them anymore.” Like, I think the reason why people have moved away from having these concerns is because it’s a compliance security risk, it’s a threat vector. And there are others who have hired teams and staff of experts to make sure that thing never breaks, on their behalf.

And similarly, I think as you think about this multimodal identity experiences, this permissions experience that we have built for developers, we are the experts in this domain. We have advisors, past advisors from AWS IAM, perhaps people know that’s a very popular. It serves billions of transactions a second, and securing cloud infrastructure at this rate of $100 billion worth of workloads. And so, we’ve got the expertise to help think through, like, what do developers need to create these safety guardrails, but with a phenomenal developer experience? And I’ll give you an example of that, Corey.

Like, in order for you to, sort of, interact with Katanemo, all you need to do is capture your API surface area in an OpenAPI specification or a GraphQL specification. And that submission of that specification means we know your resources, we know your resource model, your data paths, your access control mechanisms from the HTTP methods that you’re exposing, and then we create the entire identity, customer identity, and finding permissions experience that the developer can expose to their customers in a self-service way to construct their own roles, construct their own SSO, construct their own access log controls, if you would, and just move past this, like, can we get to an enterprise-grade experience instantly as we serve, users, teams as effortlessly with us, and through their business lifecycle. Like, no developer is going to serve necessarily an enterprise on day one; they’re going to get these teams really excited about their product and then they’re going to have an upsell motion. But having to build these by bespoke experiences on onboarding and safety for each different cohort of the customers that they want to serve, that’s just time away from stuff that they can build, cool things that are differentiating for them.

Corey: One of the things has always sucked for me about building applications, even from an infrastructure perspective, has been that I don’t know what I don’t know. And I always feel like I am making a bunch of decisions now that make perfect sense, but when I start scaling or having to take this into a more serious environment, I’m going to have to throw so much of it away and backtrack massively. And oh, I shouldn’t roll my own authentication subsystem and whatnot. But finding the right path forward that matches the current state of the art from an industry perspective really feels like a crapshoot, it’s you’re looking at all the horses, wondering which one you want to bet on and it carries a cost to get it wrong.

Salman: In my time at Serverless, at EC2, even my time at Oracle, the whole idea was to make sure that we reduce this crapshoot behavior on behalf of developers. Of course, at AWS, at Oracle, it was very wide and horizontal in its appeal to any type of developer, but we have felt that if you sort of flipped on its head and go with a verticalized approach, and particularly target one persona and their use cases and their needs, that actually helps us, sort of, look at the problem very holistically and solve that thing just for them. And as I mentioned, we sort of focused on that SaaS use case, particularly, because we believe there’s inherent and unbounded complexity there. So, this is just for playing from the experiences and learnings I’ve had in the past, which is, yeah, this stuff is hard. It’s incredibly hard to get right, and just as, you know, the industry moved to hey, I can trust somebody else who’s an expert here, we’re saying we complete that story. And we look to the modern ways people access your applications through APIs and API keys, or users, or teams, or SSL, whatever, and we compress it, saying single API call to us and you get those capabilities out of the box so you can focus on what matters: moving fast, closing customers even faster.

Corey: I think that is the grail that people are chasing. The problem I found, especially in the enterprise space, has been that it sounds great in theory, but in practice, it’s a oh great, the old Model T story, you can get in any color you want, as long as it’s black. And it’s well, okay, that’s a path, but it doesn’t comport with our security requirements and our guardrails and our compliance objectives, et cetera, et cetera, et cetera. Rightly or—more often—wrongly, people tend to believe that they are bespoke unicorns whose problems could never possibly be realized by anything that wasn’t brewed in-house at their own company. I don’t find that to be true, but I imagine you’re getting a lot of pushback from that direction.

Salman: I think there are two pieces of feedback that we normally hear. “Oh, hey. We built some of this stuff. How do we sort of untangle the mess that we have?” That’s fine. We can help them we have some components that easily wrap around their experience and give them the ability to sort of move to a better state.

But if we build this stuff as a meaningful framework using open standards, like OpenAPI and GraphQL, as the only way you interact with us today, that means that your customers can now build, have a framework in which they set their own security standards against your service, against your application. And I think that makes you getting out of the business of defining the security posture to giving them the ability to construct their security posture is using open standards so their teams can plug down their own SEIM tools if they have to. But you have that framework powering your security and safety experience, your identity and access management experience, without having to build it.

Going back to the earlier thing that we talked about, we believe we’re in an inflection point where standards do establish a lot of innovation, specifically in infrastructure, and we’re going to leverage as much as we can on behalf of developers to bet on those standards. Like I said, OpenAPI, GraphQL, AsyncAPI, so that their customers can say, “Yeah, I get it. I understand your surface area. I can construct these things at least privileged or coarse grained. That’s my choice. You’re going to give me access logs so I know what I did, or who did what, when, and how, so, you know, I can confirm for my compliance requirements.”

And they’re off the hook. They’re actually truly off the hook without having to think about, I think I can do it better because my customers are pi—or second, their customers put these requirements that take them and create [sort of 00:19:29] Rube Goldberg type of scenario in terms of their own stack. So, we think we have something to really serve the market and make it such that it’s not necessarily bespoke.

Corey: I think that you’re probably right that there’s a lot of opportunity to develop those things. I mean, you spent enough time at Amazon, for example, to have benefited from the realization of some of this. One of the nice things I have to imagine, about building a product or a service at AWS is so much of the infrastructure work has already been done. You’re not going to convince me that individual service teams have to sit there and come up with, well, we need to implement a global, highly available block store. S3 already exists. It’s right there. You can use it.

Same with authentication in the form of IAM, et cetera, et cetera, et cetera, a bunch of internal infrastructure stuff that’s there and ready to go. Now, the counterargument, of course, is, as you’re building this out, you don’t have that, I guess, luxury anymore of big company, massive, awesome infrastructure there and ready to go, other than what is available to the rest of us mere mortals. So, I have to ask, is that the big part of what sucks about building SaaS these days or are you finding the friction and challenging parts somewhere else?

Salman: So, it’s a good question because Katanemo is built on Katanemo. It’s a very [mind-tingling 00:20:46] type of discussion, but the one principle that we took is if we’re going to build something on behalf of the community, then our product and service has to consume it as well, and specifically in talking about identity and access management for our SaaS service. Because there’s nothing in the market that neatly solves this problem today. And should we rely on the cloud infrastructure and build on top of AWS and perhaps others in the market like Azure or GCP trying to do? Yeah, absolutely.

We’re not here to reinvent the primitives that are there for low-level infrastructure. We have a very strong non-religious belief that hey, we should leverage what we have, so we can move faster into market. So, we have a whole bunch of usage on, you know, openly speaking, we, when customers ask us, “How do you [unintelligible 00:21:27]? I’m like, “We use KMS for securing some of the things that we do on your behalf.” We have architected around the complexity on [unintelligible 00:21:34] groups and pools and multiples and trying keys and all that stuff. And so, we are trying to use as much as we can, but as I go back to this earlier notion, we’re trying to develop a purpose-built experience that dramatically simplifies for that developer community.

And tomorrow, as we go in towards our [unintelligible 00:21:51] infrastructure future, we will then design something very particular for that next community. And perhaps it’s going to be a gaming community if we want to solve their problems. And that’s going to be the ethos of the company. It has to be purpose-built, it has to be developer experiences phenomenal, not just digging any large cloud provider, but that is a missing component tree and how to think about it, and make sure that we can compress our infrastructure and systems knowledge so that they don’t have to build it. And so, that’s the mission that we’re on. And we’re, of course, very excited about what we’re doing and very fortunate to have both the team and the backing that we have so far to pursue this a little bit further.

Corey: You’re putting your finger right on a very painful spot that has been resonating with me for a long time, which is that it feels like building something on top of AWS natively is a lot like going to the Home Depot and building a cabinet. Well, you go walk up and down the aisles and you pick the exact wood you want, the exact stain for it, the fasteners, et cetera, et cetera, et cetera, whereas sometimes you just want something to store some bowls, so going to Target is going to be the better solution. But now you’re so forced to go and build these things yourself from parts. And that just feels like it has been such a heavy lift for folks because there’s so much you need to understand. And it’s more or less a shipping of AWS’s internal product culture.

But containers, databases, networks, compute, et cetera, are all things that any customer building even a Hello World app has to think about. But that falls across five different talk tracks at re:Invent, for example. It’s too much burden that has been put on the customer and as a result, I think that there’s a lot of value being left on the table. I spend roughly equivalent amounts of money every month on AWS and on Retool. For AWS, I spent about 450 bucks to get about 450 bucks worth of infrastructure services.

Retool, which is basically a WYSIWYG app that designs in-house applications charges me about 400 bucks for which I receive probably about 20 cents worth of infrastructure services, but the value it presents by stringing those things together for me means I am happy to pay it. I really feel like there’s a massive untapped value in being able to deliver not building blocks, but conceived solutions that get out of the way and let people build the differentiated thing that they’re in business to build.

Salman: We feel the same way. I think part of this realization is developers who are building these things continue to stumble upon the explosion of courses and certification material and all that stuff to train themselves to do something. As of course, naturally, AI comes into play and the way that you know the future of applications continues to press upon, you have to build something quickly, you will see that this notion of just [hugging 00:24:32] your primitives or hugging these low-level infrastructure primitives is going to go away because the world is moving at an incredibly breakneck pace. And that will be true, but there is truly now an inflection point where everyone wants to move even faster.

And our talk track with, I guess, our customers is, focus on what really matters to grow your business. And if you are a SaaS developer, or perhaps you’re a gaming developer, or perhaps you’re thinking very specifically in terms of vertical industry that you want to unlock, like, a healthcare company, for example, you should focus on great patient care, you should focus on great gaming experience, you should focus on great X, Y, Z. Don’t focus on infrastructure. Infrastructure is not the outcome. The outcome is your customers are happy and you’re going to serve them.

And your customers are not all equal size, equal shape, and never will be, but you need to give equal shape, equal size, type of price performance or great experience to them. Because you’re not necessarily going to spend the effort to make sure that your free tier is the most highly performant place for you serve your customers and leave your perhaps platinum or enterprise customers hanging dry, as an example. But yeah, I mean, I think that’s the ethos of our company and the spirit of what we are trying to go build. As I said, we’re humbled to be—I am humbled to be surrounded by folks who are much smarter than me and been better builders, and customers who are so excited about our journey. So, this is a good time for us at the moment.

Corey: I understand the grass is always greener when it comes to looking at the road not taken. For me, I see one of the advantages of running a services business as I do, in that, well, I can start a services business on Monday and by you know, Friday or so, I have my first client lined up and I’m ready to start performing work and get paid immediately. SaaS on the other hand feels a lot more like a real estate adjacent, where you have to go ahead and buy the land and get everyone lined up and sink the massive investment into it to get it built up, and you won’t know for years in some cases whether this is something that is going to catch on, much less even justify the cost of building it in the first place. Where are you on that journey as far as validating that you’re building something that’s resonating?

Salman: So, we have design partners, we call them because they’re shaping our product experience. And we don’t call them customers yet, just because we’re in sort of the early stages. But we have designed partners across four critical industries. One of them which is AI, as the booming next-generation AI company is going to be API-first, we have that use case that we can target really well. They’re really early in their days and they need support across their business lifecycle. Hey, I’m just going to support three users tinkering of my product to 3000 customers in an enterprise.

But that’s one. We are very much engaged in the healthcare space because the healthcare is actually going through a very massive legal transformation through—well, what’s happening there’s this HL7 FHIR standard which is actually making healthcare records more interoperable. So, you actually can get patient records if you go from one doctor to the other and not be blocked by the healthcare Gods to say, “No, you cannot do that.” And that is actually creating a very net-new experience in the healthcare space, so we have very customers excited about how we can self-solve their problems in terms of identity and authorization. We have customers in the Web3 off-chain space.

So, on-chain is all permissionless and it’s a whole bunch of different type of development experience, but off-chain has very much of the same characteristics that you will find on a traditional SaaS application. They [need 00:27:56] about safety, you think about privacy, you think about users and teams and API keys and a whole bunch of stuff that sort of baked into it. And the general developer tools who are going from an open-source experience to perhaps a cloud service experience, they’ve got a really great project in the GitHub, they got a bunch of stars and they now have to think about how to provide a better value to customers? And they have to go through a journey.

So, in those four general sort of in buckets is where we are operating right now. We’re very excited about that. And, you know, this opportunity to talk to you is to connect with more folks, especially as we, as I travel in the to AWS New York Summit, or perhaps just meeting up through one-on-ones through Calendly, or whatever have you, and figuring out how we can unlock more value for customers in these use case verticals, or perhaps something that we haven’t necessarily thought through yet.

Corey: I think that one of the clear signs of someone who used to work at Amazon is that—I don’t even have to ask; I already know the answer—of are you talking to prospective customers before you start building things? Whereas start to finish everyone I’ve ever met at AWS is highly focused on the customer experience, whereas when you talk to people building things who have not been through that, a depressing amount of the time, your question is, okay, so what do your prospective customers think about this? Like, “Oh, we haven’t talked to any of those people, yet. Talking to people is scary and we’re here to write code.” It’s, “You might be surprised by what you learn.”

And there’s no immunity to it. When I started this place, I thought I knew pretty well what people thought about their AWS bill, and it turns out, I was way off. There were nuances of the way customers talked about it that I didn’t fully understand. So, to that end, in fact, we can prove it relatively easily. What is something you have learned about your space since you started the company from customer conversations?

Salman: Oh, we actually made a pivot into this space that we are in at the moment because customers told us that’s something that they do not want to focus their efforts on. Repeatedly. We did not write a single line of code all up until November of last year, but once we got the signal from our, as I said, as I mentioned, design partners, they’re like, “This is a problem worth solving.” They’re like, “We’re going to get to work for you. You have these use cases, you have these scenarios that are coming up in your conversations with your customers. Let us be that accelerant for you and be an extension of your team in some ways, so that you can focus on what’s really, really, really important.”

So, you know, I think that’s just survival, Corey. Part, of course—naturally, of course, you work backwards from customers and that was the framework I used when I joined Amazon back in 2012. And even in my time at Oracle, that’s been the ethos of my, I guess, my personal self. But in our case, particularly, we actually talked about a very different idea, we wanted to start, but then customers told us, “You know what? Don’t start there. Start here.”

And I think that’s obviously, just the nature of surviving in through the first few years of your company existence is… getting people to say yes and getting people to say no, and then no, is actually really valuable in many cases because it tells you what to adjust to. And so, we adjusted here as a result of those conversations.

Corey: That may be the best answer to that question I think I’ve ever gotten. That is a phenomenal way to approach things. We started building a SaaS product here and two months later, we sunset the SaaS product because it turned out that what we were building and what customers wanted were not necessarily aligned. I like you said didn’t even write a line of code until last November, just because of the conversations were still shaping what was actually needed in the marketplace. You would be astonished how rare that is.

Salman: I guess. The startup founders that I have the privilege to call peers, they actually taught me some of the stuff. So, we’ve got the startup founders we want to just connect on the founder journey, we’re happy to connect. Just, but yeah, I think that the strength of the team is sort of making sure that we have our ears to the ground. Get out of the building. You got to get out of the building. And we’ve been trying to get out of the building as much as we can with Katanemo. And I think that journey just continues. The learning journey, the evolution of what we’re doing on behalf of SaaS developers continues, and we hope to delight them.

Corey: I want to thank you for taking the time to speak with me. If people want to learn more, where should they go?

Salman: So, they can go to katanemo.com, which is where our website is, and they can learn a little bit about what we do today and also where we’re headed with the venture. They can reach out to me directly on LinkedIn. Salman Paracha. I’m not super hard to find on LinkedIn. You search for me and say Katanemo or AWS and Oracle, I think you’ll be able to get to me. I’m also going to the AWS New York Summit, which happens on July 26, I believe. I might run into you there.

Corey: Oh, yes. The night before I’ll be hosting a drink up at Vol de Nuit at eight o’clock. You’re welcome there, as anyone who’s listening. And oh, it’s always a pleasure to go and talk to people doing interesting things and just talk shop. But that’s the reason I throw the drink up.

Salman: Ah, okay. I’ll take you up on that. And good, we’ll get to see each other face-to-face after some time. You can reach out to me, as I said, even basic email, and I’ll say that to you, and LinkedIn if you’re just a chat. And there’s just so many ways to get to me. On Twitter, I’m @salmanparacha, and it should be a bit easier to find me.

Don’t hesitate to reach out or search or connect with us. We are eager to talk to folks who are trying to solve or crack this Gordian Knot on terms of the what they’re building. And especially if you’re building towards the next-generation AI application and think through safety, we believe we are years ahead in terms of thinking about safety in that space. It’s early days for us there, but we’re obviously interacting with customers and developers who are trying to think through, how do I now take what was understood to be a table stakes, okay, API-first experiences, [user seems 00:33:31], keys, all that good jazz, and provide safety for that? But I think the new world that we’re going to live in is not only going to just be deterministic responses from APIs; it’s going to be probabilistic responses from large language models. And we got something going on in that space, particularly. We feel fairly bullish on it. But more, customer conversations before we write a piece of code is important. So, just connect with us. I’m salman@katanemo.com, on LinkedIn, Twitter, and I will be quick to reach back out to you.

Corey: And I will, of course, put links to that in the [show notes 00:34:02]. And I’ve also filled out the contact us form on katanemo.com because I have a couple of problems it sounds like this might absolutely be a way to solve. Because otherwise, God help us all. I’m writing another login page.

Salman: Right. So, just see Corey Quinn just signed up for our access. So, I will give you access. So.

Corey: You think I’m kidding. I assure you I’m not. That’s the scariest part is that I’m often being completely serious and people think I’m making a joke. Thank you so much for taking the time to speak with me. I really appreciate it.

Salman: Hey, thanks for the time. I appreciate the opportunity.

Corey: Salman Paracha, founder and CEO at Katanemo. I’m Cloud Economist Corey Quinn and this has been a promoted guest episode of Screaming in the Cloud brought to us by our friends at Katanemo. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice, along with it insulting comment talking about how difficult it was to build that platform yourself from scratch because of all the infrastructure moving parts before it would take that insulting comment.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.