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

Episode Date: July 20, 2023

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’s 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. About SalmanBuilding 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:Katanemo: https://www.katanemo.com/LinkedIn: https://www.linkedin.com/in/salmanparacha/Email: mailto:[e-mail]: https://twitter.com/salman_paracha

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. 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 Catanemo. When you talk to small startups, who should we talk to? They invariably look around the room, figure out who they should throw directly into the gristmill. And in this particular case, they have selected Salman Paracha, who is the founder and CEO. Salman, thank you for joining me. Hey, thanks for having me. Second time. It is. And every time we talk, it seems like there's 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? 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 have now been 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 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 of 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 a 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 this 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's 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 touched out with folks like Twilio and Slack at that time. And I said, I think it 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 is no infrastructure. So that's it. I mean, I think that the core thesis was, if I've operated at this intersection

of hyperscale cloud infrastructure and at 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, and the scaling, and 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're 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 are 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. 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 for decades later. Yeah. So anywho, 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 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.

One of the challenges with the approach that I've 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 have the 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, and this is what they're going to build. You know, you'll find builders, and you'll have builders surprise you, and I 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 established 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 that 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's the inside part of this is knowing how successful these projects can be, but also how complex they can be to manage. But if we just focus on developer experience and operator experience and ask what's the most pressing question to answer, which is, can you serve your customers? Can you know who they 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. Whereas I said earlier, which is the modern reference architecture or microservices perhaps gives you some powers, but it really explodes the amount of choices and results in this massive drag and 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 Cod and Emo, particularly going towards this future of no infrastructure or zero infrastructure. So yeah, all respect to everyone who's building. We've had the good fortune,

and we hope to pass that fortune back in terms of a product experience. 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 shit posting 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. 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 in perhaps an order of magnitude more. Because in any modern SaaS experience, you would have to think through

a validity of concerns relative to your small customer base that's trying your product, teams that are relying on your experience 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 from the get-go and then create the right level of

experiences for perhaps the general business to consumer applications as well. But this problem, I think, is magnified even more for that 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 chat GPT, 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. I have to ask, as 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, it doesn't sound that far removed from what it is that you're proposing

to build. Hasn't this been done yet? I think the way we think about this problem is across multiple layers. There are some components to this problem is across multiple layers. And there's some components to this problem that it's worth talking about. Of course, when you say zero infrastructure, no infrastructure, what does that even mean? 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 these things out in components, which is our zero trust capability. So if you think about broadly 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, which is an abstraction. And a fine one, if you want to build a general purpose app, 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, organizations. So we're 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, 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 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 new built. There, 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 usage naturally become a threat vector that you have to protect for. And they have to be neatly thought through from an 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 privilege access. So that meaning, how do you safeguard the most protected resources of 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?

Not to mention you're going to get it wrong. And as a result, mistakes there have security implications that can be dire. 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 him this question, where do you store your username and passwords for your applications? Like I don't show 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 that thing never breaks on their behalf. And similarly, I think as you think about this multimodal identity experience, 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 have 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 Cod and AMO, all you need to do is capture your API surface area and an open API specification or 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, the customer identity and find and 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 and effortlessly scale with us through their business lifecycle? Like, no developer is going to serve necessarily an enterprise from 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, it's just time away from stuff that they can build cool things that are differentiating for them. One of the things that's 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. You're looking at all the horses wondering which one you want to bet on, and it carries a cost to get it wrong. 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 and Oracle, it was very wide and horizontal in its appeal to any type of developer. But we have felt that if we would sort of flip that 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 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 an inherent and unbounded complexity there.

So this is just 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 the industry moved to, I don't want to store passwords in some Kluge database, but some solving mechanism, and into sort of saying, 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. I think that 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, 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.

I think there are two pieces of feedback that we normally hear. 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 is 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 that security posture

to giving them the ability to construct a security posture 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, and 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, how. So I 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, or second, their customers put these requirements that take them and create for a 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. 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 counter argument, 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? So it's a good question because Cardonimo is built on Cardonimo. It's a very mind-twangling 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 try 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, and openly speaking, we've been, customers ask us, how do you design systems? Like we use KMS for securing some of the things that we do on your behalf. We have architected around the complexity on community groups and pools and multiples and client 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 are trying to develop a purpose-built experience

that dramatically simplifies for that developer community. And tomorrow, as we go back to this earlier notion, we are trying to develop a purpose-built experience that dramatically simplifies for that developer community. And tomorrow, as we go towards our zero infrastructure future, we will then design something very particular for that next community. 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 experience is 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. You're putting your finger right in 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 still 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, etc. 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 reInvent, for example. It's too much burden that is being 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 spend 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 200.20 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 on-tap 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 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 where you know the future of applications continues to press upon, you have to build something quickly. You will see that this notion of just hogging your primitives or hogging 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 a 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 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. Are you going to serve them? And your customers are not all equal size, equal shape. It 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 performing 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 that's the ethos of our company and our in the spirit of what we are trying to go build and we as I said, I'm 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. 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 Friday or so I have my first client lined up and I'm ready to 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? 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 the early stages. But we have design 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 on my product to 3,000 customers in an enterprise. So 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 what's happening there is 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 our 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 it's a whole bunch of different type of development

experience. But off-chain has very much of the same characteristics that you'll find on a traditional SaaS application. The need about safety, you think about privacy, you think about users and teams and API keys and a whole bunch of stuff that's 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

that they now have to think about how do I 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 this opportunity to talk to you is to connect with more folks, especially as I travel to the 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. 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. 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?

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 up until November of last year. But once we got the signal from our, as I said, as I mentioned, design partners, we'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 been the ethos of of my i guess my personal self but in in our case particularly we actually talked

about a very different idea where we want 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 of your company existence is getting people to say yes and getting people to say no and the 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 that might 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. Like you said, you didn't even write a line of code until last November just because the conversations were still shaping what was actually needed in the marketplace. You would be astonished how rare that is. I guess. The startup founders that I have the privilege to call peers, they actually taught me some of this stuff.

So if there are other startup founders who want to just connect and found our journey, we're happy to connect. 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. We've got to get out of the building. And we've been trying to get out of the building as much as we can with Cardonimo. 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. I want to thank you for taking the time to speak with me. If people want to learn more, where should they go? So they can go to Cardonimo.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. Just search for me and say carlinema 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 26uly 26th i believe i might run into you there oh yes the night before i'll be hosting

a drink up at valdenui at eight o'clock uh you're welcome there as is anyone who's listening and oh it's always a pleasure to go and talk to people doing interesting things and just talk shop that's the reason i throw the drink up ah okay i'll take you up on that and we'll get to see each other face to face-face after some time. You can reach out to me, as I said, even basic email. And I'll share that to you in LinkedIn if you're interested in chat. And there's just so many ways to get to me on Twitter. I'm Salman Paracha, and you should be able to find me.

Don't hesitate to reach out or search or connect with us. We're eager to talk to folks who are trying to solve or crack this Gordian knot on terms of 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 table stakes, like API-first experiences, user seams, 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've got something going on in that space. Particularly, we feel fairly bullish on it. But both customer conversations before we write a piece of code, it's important. So just connect with us. I'm Salman at Katanemo.com on LinkedIn, Twitter, and I will be quick to reach back out to you. And I will, of course, put links to that in the show notes. And I've also filled out the contact us form on catanemo.com because I have a couple of problems that sound like this might absolutely be a way to solve.

Otherwise, God help us all, I'm writing another login page. Right. So as you see, Corey Quinn just signed up for our access. So I will give you access. 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. Hey, thanks for the time. I appreciate the opportunity. Corey Quinn, and this has been a promoted guest episode of Screaming in the Cloud, brought to us by our friends at Cadanemo. 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 an 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. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill 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.