Podcasts Technology Screaming in the Cloud Elevating the SaaS Application Development Experience with Salman Paracha

Elevating the SaaS Application Development Experience with Salman Paracha

Published: July 20, 2023, 10 a.m.

b'

Salman Paracha, Founder & CEO at Katanemo Labs, joins Corey at Screaming in the Cloud to discuss his vision for the future of SaaS application development. Salman and Corey discuss what led him to take the leap into founding a start-up, and Salman shares how he believes the future of SaaS application development is at an inflection point. Salman also explains why it\\u2019s critical to focus on the outcome your customers experience over infrastructure, and shares his vision for future developers looking to build the next wave of SaaS applications.\\xa0

About Salman

Building high-growth, high-tech software products that affect the lives of millions of customers. 15+ years of experience in building successful products and highly effective teams. I am deeply interested in bringing the power of the cloud to end customers, large scale data problems, and delivering scalable services on commodity hardware.


Links Referenced:


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\\u2019m Corey Quinn. And this promoted guest episode of Screaming in the Cloud is brought to us by our friends at Katanemo, who is\\u2014when you talk to small startups, like, \\u201cWho should we talk to?\\u201d 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\\u2019ve 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\\u2019m going to go start a startup of my own. Presumably. I\\u2019m assuming that is the thought process that led you here. What\\u2019s 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\\u2019m actually trying to ship software out for customers. And so, I\\u2019ve 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\\u2019t 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\\u2019t 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\\u2019ve 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\\u2019s inherent complexity in sort of thinking through the various concerns of the shapes and sizes of your customers that you\\u2019re 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\\u2014I chatted folks like Twilio and Slack at that time, and I said, \\u201cI think there has to be a much, much better way.\\u201d 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\\u2019s it. I mean, I think the core thesis was, \\u201cHey, if I\\u2019ve 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?\\u201d And then I\\u2019m 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\\u2019ve 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\\u2019t think I\\u2019m getting any younger. My parents, my South Asian parents, perhaps they\\u2019re 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\\u2019s 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\\u2019m 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\\u2019re like, \\u201cWow, it\\u2019s doing an awful lot of fascinating stuff underneath the hood, and I really hope this works. If it breaks halfway through, I haven\\u2019t first idea where to look under the hood to make sure that this actually works and doesn\\u2019t break my application.\\u201d



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\\u2019ve done before, the places you\\u2019ve been, I don\\u2019t have to explain that to you. You have clearly spent your entire career in environments where mistakes matter because they\\u2019re going to show very quickly to an awful lot of customers if they wind up getting out there. That feels to me like it\\u2019s 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\\u2019re going to build.



Salman: You know, you\\u2019ll find builders, and you\\u2019ll 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\\u2019s an advantage that the team has, and we\\u2019re very fortunate on having that advantage, having seen things break. And I think we\\u2019re at this inflection point, perhaps now that there\\u2019s 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\\u2019re 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 \\u2026 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\\u2019s the most pressing question to answer, which is\\u2026Can you know who (your customers) are and what they\\u2019re doing in your system, and have the ability to shape their experience versus shaping the infrastructure?\\u201d



I think we\\u2019ll be in a much better state as an industry, we\\u2019ll be much happier developers, we\\u2019ll 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\\u2019s that part of the lessons and learnings and insights that we have and we\\u2019re 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\\u2019s building. You know, we\\u2019ve 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\\u2019s just a ridiculous static site. Maybe it\\u2019s some serverless-powered shitposting app. I have several of those in existence.



And every time it\\u2019s like, \\u201cOh, 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\\u2019s going to be the important thing to get done.\\u201d 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\\u2019s 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\\u2019s undifferentiated work that I don\\u2019t want to be doing.



Salman: I think that actually is magnified to a certain degree when you\\u2019re thinking about an enterprise-grade SaaS application. And my impression is it\\u2019s 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\\u2019s trying your product, teams that are relying on your experience that their workflows don\\u2019t break, or perhaps large enterprises who you\\u2019re trying to serve and upsell to. And that inherent complexity then gets baked into the choices on \\u201cHey, 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?\\u201d



And I think that\\u2019s the really hard nut to crack. And we\\u2019re 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\\u2019s magnified even more for the [unintelligible 00:10:01] dot community that\\u2019s 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\\u2019m 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\\u2019t sound that far removed from what it is that you\\u2019re proposing to build. Hasn\\u2019t this been done yet?



Salman: So, I think the way we think about this problem is it\\u2019s across multiple layers. And some components to this problem that\\u2019s 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\\u2019s 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\\u2014and a fine one, if you want to build a general purpose app that is just serving the consumer, perhaps. And we\\u2019re sort of taking a very different position. We\\u2019re saying we\\u2019re here to solve you if you\\u2019re building something that\\u2019s going to serve developers, teams, or organizations. So, we are very different in terms of how we\\u2019re approaching the market relative to what we want to go solve for.



That\\u2019s 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\\u2019ve 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\\u2019s no longer users using something you\\u2019re built. There are, of course, as I mentioned, teams, and of course, there\\u2019s 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\\u2019ve 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\\u2019s going to take over and maintain that piece of code?



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



Salman: I think that\\u2019s where developers tell us, this is why\\u2014you 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: \\u201cWhere do you store your username and passwords for your applications?\\u201d Like, \\u201cI don\\u2019t store them anymore.\\u201d Like, I think the reason why people have moved away from having these concerns is because it\\u2019s a compliance security risk, it\\u2019s 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\\u2019s 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\\u2019ve 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\\u2019ll 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\\u2019re 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\\u2019re going to get these teams really excited about their product and then they\\u2019re 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\\u2019s 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\\u2019t know what I don\\u2019t 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\\u2019m going to have to throw so much of it away and backtrack massively. And oh, I shouldn\\u2019t 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\\u2019s you\\u2019re 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\\u2019s inherent and unbounded complexity there. So, this is just for playing from the experiences and learnings I\\u2019ve had in the past, which is, yeah, this stuff is hard. It\\u2019s incredibly hard to get right, and just as, you know, the industry moved to hey, I can trust somebody else who\\u2019s an expert here, we\\u2019re 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\\u2019s a oh great, the old Model T story, you can get in any color you want, as long as it\\u2019s black. And it\\u2019s well, okay, that\\u2019s a path, but it doesn\\u2019t comport with our security requirements and our guardrails and our compliance objectives, et cetera, et cetera, et cetera. Rightly or\\u2014more often\\u2014wrongly, people tend to believe that they are bespoke unicorns whose problems could never possibly be realized by anything that wasn\\u2019t brewed in-house at their own company. I don\\u2019t find that to be true, but I imagine you\\u2019re getting a lot of pushback from that direction.



Salman: I think there are two pieces of feedback that we normally hear. \\u201cOh, hey. We built some of this stuff. How do we sort of untangle the mess that we have?\\u201d That\\u2019s 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\\u2019re in an inflection point where standards do establish a lot of innovation, specifically in infrastructure, and we\\u2019re 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, \\u201cYeah, I get it. I understand your surface area. I can construct these things at least privileged or coarse grained. That\\u2019s my choice. You\\u2019re 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.\\u201d



And they\\u2019re off the hook. They\\u2019re actually truly off the hook without having to think about, I think I can do it better because my customers are pi\\u2014or 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\\u2019s not necessarily bespoke.



Corey: I think that you\\u2019re probably right that there\\u2019s 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\\u2019re 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\\u2019s 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\\u2019s there and ready to go. Now, the counterargument, of course, is, as you\\u2019re building this out, you don\\u2019t 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\\u2019s a good question because Katanemo is built on Katanemo. It\\u2019s a very [mind-tingling 00:20:46] type of discussion, but the one principle that we took is if we\\u2019re 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\\u2019s 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\\u2019re 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, \\u201cHow do you [unintelligible 00:21:27]? I\\u2019m like, \\u201cWe use KMS for securing some of the things that we do on your behalf.\\u201d 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\\u2019re 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\\u2019s going to be a gaming community if we want to solve their problems. And that\\u2019s 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\\u2019t have to build it. And so, that\\u2019s the mission that we\\u2019re on. And we\\u2019re, of course, very excited about what we\\u2019re 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\\u2019re 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\\u2019re 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\\u2019s so much you need to understand. And it\\u2019s more or less a shipping of AWS\\u2019s 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\\u2019s too much burden that has been put on the customer and as a result, I think that there\\u2019s 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\\u2019s 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\\u2019re 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\\u2019re a gaming developer, or perhaps you\\u2019re 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\\u2019t focus on infrastructure. Infrastructure is not the outcome. The outcome is your customers are happy and you\\u2019re 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\\u2019re 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\\u2019s the ethos of our company and the spirit of what we are trying to go build. As I said, we\\u2019re humbled to be\\u2014I 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\\u2019m 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\\u2019t 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\\u2019re building something that\\u2019s resonating?



Salman: So, we have design partners, we call them because they\\u2019re shaping our product experience. And we don\\u2019t call them customers yet, just because we\\u2019re 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\\u2019re really early in their days and they need support across their business lifecycle. Hey, I\\u2019m just going to support three users tinkering of my product to 3000 customers in an enterprise.



But that\\u2019s one. We are very much engaged in the healthcare space because the healthcare is actually going through a very massive legal transformation through\\u2014well, what\\u2019s happening there\\u2019s 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, \\u201cNo, you cannot do that.\\u201d 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\\u2019s 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\\u2019ve 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\\u2019re 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\\u2019t necessarily thought through yet.



Corey: I think that one of the clear signs of someone who used to work at Amazon is that\\u2014I don\\u2019t even have to ask; I already know the answer\\u2014of are you talking to prospective customers before you start building things? Whereas start to finish everyone I\\u2019ve 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, \\u201cOh, we haven\\u2019t talked to any of those people, yet. Talking to people is scary and we\\u2019re here to write code.\\u201d It\\u2019s, \\u201cYou might be surprised by what you learn.\\u201d



And there\\u2019s 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\\u2019t 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\\u2019s 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\\u2019re like, \\u201cThis is a problem worth solving.\\u201d They\\u2019re like, \\u201cWe\\u2019re 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\\u2019s really, really, really important.\\u201d



So, you know, I think that\\u2019s just survival, Corey. Part, of course\\u2014naturally, 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\\u2019s 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, \\u201cYou know what? Don\\u2019t start there. Start here.\\u201d



And I think that\\u2019s obviously, just the nature of surviving in through the first few years of your company existence is\\u2026 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\\u2019ve 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\\u2019t 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\\u2019ve got the startup founders we want to just connect on the founder journey, we\\u2019re 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\\u2019ve 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\\u2019re 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\\u2019re headed with the venture. They can reach out to me directly on LinkedIn. Salman Paracha. I\\u2019m not super hard to find on LinkedIn. You search for me and say Katanemo or AWS and Oracle, I think you\\u2019ll be able to get to me. I\\u2019m 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\\u2019ll be hosting a drink up at Vol de Nuit at eight o\\u2019clock. You\\u2019re welcome there, as anyone who\\u2019s listening. And oh, it\\u2019s always a pleasure to go and talk to people doing interesting things and just talk shop. But that\\u2019s the reason I throw the drink up.



Salman: Ah, okay. I\\u2019ll take you up on that. And good, we\\u2019ll 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\\u2019ll say that to you, and LinkedIn if you\\u2019re just a chat. And there\\u2019s just so many ways to get to me. On Twitter, I\\u2019m @salmanparacha, and it should be a bit easier to find me.



Don\\u2019t 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\\u2019re building. And especially if you\\u2019re 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\\u2019s early days for us there, but we\\u2019re 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\\u2019re going to live in is not only going to just be deterministic responses from APIs; it\\u2019s 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\\u2019m 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\\u2019ve 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\\u2019m 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\\u2019m kidding. I assure you I\\u2019m not. That\\u2019s the scariest part is that I\\u2019m often being completely serious and people think I\\u2019m 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\\u2019m 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\\u2019ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you\\u2019ve 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.

'