Founders of Defang - Building the easiest way to develop, deploy and debug cloud apps in minutes!

What became clear is the number one thing that people care about is simplicity. And Sharad, you used the word you're building something complex. You know, we have a lot of moving parts inside because we do, we want to make it very, very simple for the user. So the user experience is very simple, but the system takes care of all that complexity underneath the covers for you, right? And that resonates with All levels of users, whether they are early in career or working at a startup or even working at an enterprise, everybody wants things to be simpler, but still have various levels of control. But that simplicity, I think, is our number one sort of value proposition. One command and you're up and running in a cloud. And that's exactly what we have built.

Welcome to the Undefeated Underdogs Podcast, where I unpack and narrate stories of ambitious people who turn obstacles into opportunities. My goal for this podcast is to create a platform to narrate underdog stories and maybe play a small, teeny tiny role in inspiring you. I intend to highlight the underdog mentality and make authentic conversations with people who play the long game, take action with a chip on their shoulder, and convert obstacles into opportunities. Buckle up as I'll be bringing some authentic founders, VCs, community builders, and content creators who got underestimated their whole lives. And yet they beat all the odds to become insanely successful. Now today, I want to tell you a little bit about our awesome sponsor, acquire.com. Selling a business is as tough as building a business. As someone who went through this process once, selling my own startup, I know the pain it takes to get to the end zone. This is where our sponsor shines. Imagine this, you're a founder who's built a solid SaaS product and acquired customers and generating consistent monthly revenue. The problem is you're not growing for, for whatever reason— lack of focus, lack of skill, or just plain lack of interest— and you feel stuck. What should you do? The story I'd like to hear is you buckle down, somehow reignited the fire, get past yourself and the clichés, and start working on your business rather than just in the business. You start building an audience, move out of your comfort zone to do sales and marketing, and in 6 months you triple your revenue. The reality isn't as simple. Situations may be different for every founder facing this crossroads, but too many times the story ends up being one of inaction and stagnation until the become business— the business becomes less valuable or worse. Worthless. If you find yourself here, or your story is likely headed down a similar road, I offer you a third option. Consider selling your business on acquire.com. Capitalizing on the value of your time is a smart move. Acquire.com is free to list, and they've helped hundreds of founders already. Go to try.acquire.com/sharath and see for yourself if this is the right option for you. Now let's get into today's episode. So we as builders want to move fast so we can break things. That's been the mantra for us for a long time. The way we do things is to like break things, learn from them, make it better, build better products. And DFang enables engineers to develop, deploy, debug cloud apps in a secure, scalable, reliable way to your favorite cloud platforms. In short, they're going to enable you. They're going to give powers to you. You can deploy, develop, and debug using their AI solutions. Defang is part of Google for Startups accelerator and have raised money. Today I have the founders, Prakash and Leo, joining me to talk about their journey, the launch of their new product today on Product Hunt. I'm just going to give like a brief intro for people who don't know Prakash and Leo. They're veteran tech leaders with experience spanning over like some of the biggest brands like Microsoft, Workday, AWS. where they led engineering efforts on various projects. I don't want to name all of them because I can go on and on. But welcome, Leo, Prakash. Welcome to the show. How are you guys feeling?

Thank you, Sharad.

Very good. I'm super excited because I think, fun story before we dive into the conversation, Twitter is amazing. Don't you guys agree? Because I think Toki, uh, your developer advocate, posted something on Twitter. And one of my friends tagged me, you know, we kind of got into a conversation. I was like, this is dope. Like what you guys building are really, really helpful for builders. I'm all for builders, anything, any product that really helps enables builders move fast. I'm rooting default by default. So it's so fun to like go from posting on Twitter to like having a conversation on my podcast. So just want to mention that. And also to celebrate today's launch, I'm rocking part of Product Hunt's swag just to like help you, like, you know, rooting for you like on a different level. But so, so dope to like have you guys. It's so interesting to see what you're doing. I'm not a developer per se, you know, but I build products using no-code tools and solutions. But it is so fascinating to see that you're all for developers, so, or builders. Talk to me about like the first question I have for you both. You can go like one after the other. Yeah. Why this mission of helping builders move fast? Where did that, you know, come from?

Yeah, maybe I'll start and then Leo can, I'm sure, add more details. Yeah, this is our third time working together. Leo, myself, and our third co-founder, Antoine. We came to know of each other almost 15 years ago. when we were all at Microsoft building early cloud platforms and developer tools, Visual Studio, Windows Server, and that became Azure. And then after a while, when we all moved on to the next step in our careers, we did startups where we built applications on top of cloud, whether that's Azure or AWS. That startup got acquired by, as you mentioned, Workday. And we continued to build cloud applications there. And then for my side, I worked at AWS being responsible for a couple of their services. So we have a lot of experience building both cloud platforms, developer tools, and applications. And of course, cloud is very popular. Everybody uses it. It's been around for now 15 years, but it's also complex and getting more complex as more and more services are added. And so, you know, when we look back at our experiences, we were like, this is Great, but there has to be a simpler way to build applications, a simpler way to develop applications and especially to deploy applications, because that's where there's an impedance mismatch between what a developer knows. They know their application, they know how to write that maybe and debug it. We can help them there as well, but deploy is like a whole other ballgame. And so we were like, how can we make this really, really easy for developers?

Yeah, exactly. We've been both in startups, we've been in big companies, and the way big companies deal with the problem is they have dedicated teams that build tools, platforms for that company. And to us, after we left Workday, we had this realization, like, it doesn't make sense that every company is building their own version of cloud just because the, the cloud providers, the big ones, are not focused on it. They're giving you more and more options. You have to be a specialist, you have to be trained. In fact, they provide trainings for you to become like an accredited AWS cloud engineer, accredited Azure engineer, etc. And so, and each company deals with it by throwing like 50 people at the problem or Hundreds of people at the problem. And small companies can't afford to do that. So what does a small company do?

Right.

They are, they're building to using the tools that maybe one cloud provides, and now they're stuck. Now they cannot move to another cloud. They find out choices they've made early on do not help them scale. Now they're trying to change the engine mid-race and And we came to the realization this is a tooling problem. We need better tools. And so that's why we're building Defang.

Yeah, I love these stories, to be honest, because stories that really resonate with me are the ones like yours, which is you are building this for yourself. You saw a problem because you've done this multiple times. You're kind of like, you know what, this is too much. Let's—

yeah,

just like, you know, let's, you know, fuck it, let's build it. Because, you know, we've had enough. I think take matters into your own hands. And I've known many founders succeed in their own way by doing this or taking this path. I'm curious on like, I want to talk about the frustration. Like, when are you, when were you like so frustrated? Like you went to the peak and like decided to like, you know, do or quit your day jobs and like, I want to do this full-time. Can you go back, take me to that moment where you both are, you know, the 3 of you like You know what? We've had enough.

Yeah, maybe Leo, you should start this time.

Yeah. So definitely something was brewing and has been brewing for 15 years, right? We were there at the early beginnings of Azure when it wasn't called Azure yet. It was Bing Cloud or something. Prakash was closer to that effort than I was.

What a name. That should be a soundbite.

Yeah, don't quote me on that. But then, you know, I left Microsoft. I went into a company that was doing private cloud. Actually. So like data centers, stuff like that. Then went into a consultancy, but the third co-founder and I, we had our consultancy building products for big companies, small companies. We were just builders at that point, you know, guns for hire. And that's when Prakash and the two of us started talking again. Hey, like, I want to build an app in the cloud. And we're like, okay, cool. We, we kind of know how to do this stuff. So we started building that. And little by little, especially as consultants, we say, okay, man, every app has the same required requirements, really. They all want resiliency. They all need to take security into account, data recovery. They want to be flexible. You know, you don't want an architecture that only works on AWS because what if you want to change? What if there's requirements of the customer that wants to suddenly go to Azure for whatever reason? Might be cost, might be they have credits, might be a government contract. You don't know, right? So you want your application to be flexible and yet secure, resilient, all of those other artifacts that people need. And so we already came to this realization that, you know, there is a core set of functionalities that every app needs, but everybody has to figure it out by themselves. So that slowly started the seed of what we're now working on. And then we ended up in Workday. Prakash and I worked there. And I think there we have the real anecdotes where even big companies working with big budgets towards the cloud, having direct access to AWS experts because they have, of course, they have this consultancy contracts there, right? So you talk to the AWS teams directly like, hey, I wanna build this, what do I use? And then you get a lot of recommendations. And then still struggling with all those resources, with all those, and I'm not talking about money and just the relationships that big companies have with the direct relationships they have with the cloud providers. And they are still struggling. So a small company just has no chance to do it the right way from day one, right? You don't have the luxury to spend 6 months studying. which cloud, or once you figure out which cloud, now you have another 6 months, like, you know, what do I use of this particular cloud? And so that's where I just, the, you know, that's when it really hit, like, my God, it is a terrible shape cloud is in. We definitely need to work on this. And I think we have the experience, the team to be addressing this problem.

Yeah, and just to add to that, you know, Leo mentioned some of the dimensions where you have to consider, right? Whether that's security or observability or performance, scale, cost. And as developers, you know, you kind of make the best decision you can with the information you have. But what's painful is when those early decisions, as you get closer to releasing your product, you're doing testing, you're, you know, in beta. And you realize some of those decisions maybe were not optimal, or maybe even the app has changed in a way that now something else is optimal. Maybe you chose, you know, function as a service and maybe the cost profile or the response time or whatever it might be is not where you want it to be. And if you want to change that, you know, it's oftentimes a rewrite. So these are types of problems in the long run that in our roadmap we're trying to address where developers can write an app one way. And then over time, you know, the system can become more smart as to how to make those deployment decisions. So one thing we emphasize in the approach we're taking is try to keep the app described in as high level and logical a way as possible so that you leave all these kind of downstream decisions to a system that can make smart decisions, learn over time, improve. And we might not have all of those, you know, bits of functionality today, but that's where we're headed. And at the same time, I just want to say, like, you know, the hyperscalers, obviously they're investing tens of billions of dollars every year in building their infrastructure and building new services. And we want to make sure that more developers can access those. So we don't want to hide the underlying cloud platforms. We just want to make it, those cloud platforms easy to use. Make them, you know, if you're a hobbyist, a student, you might not even have a credit card to create an account, but we still want you to be able to take advantage of the power of those platforms and grow into them. Yeah.

I absolutely love that because I think that's, that's my next question where I got curious. Why do these big brands like AWS, They focus on builders, like, like how you mentioned, like the students who are coming out of college, they want to build something. They don't have this, this, you know, huge leverage of investing some money. And I think that's where your differentiator factor is, where you're targeting everyday builder whose hobby is, who wants to build something, put it out on the internet, make some money, just like rinse and repeat. So yeah, talk to me about that. That gap, why do you think the gap exists?

Yeah. And I think if you go talk to any of the hyperscalers, they'll tell you, yes, they are interested in enterprises using their platform. They're interested in startups using their platform. They're interested in students and hobbyists using their platform. They'll all say that. And they have some tools that try to make it easy, but obviously enterprises and startups, that's kind of where the money is. So When you have to make a trade-off, maybe some of those decisions go towards those bigger revenue customers, right? Anyway, we're focused on kind of starting at what we call the bottom of the pyramid— students, hobbyists, early in career professionals— make the clouds accessible to them. And then what we find is if we do that, then the next tier of startups and software studios who are building software maybe for others, They can also benefit from some of the same innovations and eventually, you know, we'll get to the enterprise as well, but it's kind of a progression for us where we're starting at the bottom of the pyramid, try to make it really, really easy. I think that's the one key focus for us is make it really easy to use and let the system take care of all the other sort of abilities, right? Whether it's performance, scalability, reliability, security, cost, because in the end— Interesting. Those apply to everyone, right? But we are just starting with that early in career tier.

Yeah. Talk to me about the 0 to 1 phase. Like you got the idea. I'm just wondering, you know, you're already building a complex solution to, I wouldn't say complex solution. You have to tell me about it, but you're tackling a complex problem. That means you have to build like a robust system. So yeah, talk to me about the MVP, the initial phases, how fast you're talking a lot about repeating about like speed is the first thing, easy is the first mission or the priority for us. So how did you build like an MVP to handle such a complex problem? What was that like?

Okay, I'll get this one. So our first private beta was last summer. So 2023, summer of 2023. And that really was at that point a tool that we would use to deploy our own stuff.

Hmm.

And so like, we've done this like tens of times before. You know what, you know, we know what the service we want to build, what it should look like. Can we have a tool that helps us get there and deploy the way we are used to deploying stuff, the way we have been deploying stuff in big companies according to the recommendations, secure, all of that, resilient? And so that first release of now like a year or 3 months, like 15 months ago or something like that, was really that like, okay, you know, We want to, we know what the output should look like. So what is the input? And we started like looking at what Prakash calls a logical description of your application. We want to build a tool that knows exactly what the physical manifestation of your application should look like. You know, okay, you're going to need these routing tables, these routing rules, this load balancer, that NAT gateway, these security groups. All of that, we know what that should look like. We want a tool that does that for us based off of a logical description. And so it was then that we decided, okay, you know, we're already used to using Docker Compose in our local machines for local development day-to-day. People use Docker Compose. Many teams actually use Docker Compose. And Docker Compose is a very small, short description of an application. Like, oh, I have an application with these 3 services. Mm-hmm. The services are listening on ports. They have some configuration or not. They are either built from source or not. They maybe either use a prebuilt image, very short description, usually about 10, 20, 30 lines. I've seen more complex than that, but many apps can be described in a very short fashion. And so that's when we decided, okay, why don't we take this as the input? And we know what the output looks like. And so that was our first MVP. Okay, translate this input to that output, you know, and that became our private beta. Since then, we've been adding like features that we need, features that the initial feedback had suggested, or like maybe, hey, this works for AWS, what about other clouds, right? So we started working on that. Hey, this works for a single service, what about 4 services? Hey, this, how about, how do I add data database? How do I add caching? And so slowly we're adding to capture more and more of the applications that are out there, right? We'll never do 100%, right? Everybody, there's applications that need very particular specific requirements. And yeah, so we're not going to build for them, but we are building to the 80% that's out there.

Yeah. And just to add to that, Leo mentioned the Compose file, which we've chosen as our, you know, standard. Compose is an industry standard and we've kind of standardized on that as how you describe your application. And the key there again is the Compose file by and large specifies what you want deployed. You know, you have an app, it has 3 or 4 services, it has a database, it has a queue. whatever, right? And it's a very succinct description of that what. And our system, DFang, translates that into the how. And so those 25, 30 lines can become hundreds of lines, if not 1,000 lines of infrastructure as code. And that's, you know, one translation for AWS, a different translation for GCP, a different translation for DigitalOcean. So nobody is the expert in all of this, right? It's very hard to be. And that's where a tool can be that expert. And this translation is all rules-based. So it's very predictable. Every time you have the same input, you'll get the same output. You won't have any surprises. And we can go through all the Well-Architected reviews and security reviews to make sure what we emit is very high quality. Right. Right. And that's our hope and vision is that this type of tool can remove the heavy lifting that people have to do to go from that app description to all the IaC, which they, by and large, most of them don't know how to do, or, you know, may make mistakes and leave security holes or scalability issues or whatever. And that we can standardize and then let the system improve itself over time, right? It can learn. And get smarter over time. Yeah.

Interesting. Yeah. Still can't fathom that you're building such a complex thing in an MVP phase, right? Which is like, you're so patient. You're kind of listening to the users do what they want. Also like kind of prioritizing what feels good or like at least makes sense to you. Yeah. I want to talk about or ask about a little deeper into that. Especially talking to users, right? How was, how was the first few iterations went to the public? What was like the go-to-market strategy was like, you know, how did you involve users apart from you? Because you have industry expertise, you've been doing this and it can be like a, if you think about it, it can be like a, it can be like a curse too, because you're in, you can live in your own bubble. So

yeah.

Yeah. How did you navigate that?

Yeah, maybe I can start here. Yeah, definitely. We obviously started with our own experiences and kind of Defang, if you think about it, is a reflection of the tool that we wished we had when we were building those startups in our past life, right? Yeah. But still, the industry's always moving. There are new tools, there are new platforms. So you cannot build to what you wished you had like several years ago or even a few years ago. But You know, when we started kind of thinking about what this should be, we did some user interviews. Togu talked to various people at big companies, at small companies, at, you know, early in career professionals and just students and hobbyists. What became clear is the number one thing that people care about is simplicity. And Sharad, you used the word you're building something complex. You know, we have a lot of moving parts inside because we do, we want to make it very, very simple for the user. So the user experience is very simple, but the system takes care of all that complexity underneath the covers for you, right? And that resonates with all levels of users, whether they are early in career or working at a startup or even working at an enterprise. Everybody wants things to be simpler, but still have various levels of control. You know, obviously in the enterprise, you want to have more control over what are those emitted, you know, configurations that you get to. But that simplicity, I think, is our number one sort of value proposition. It's like almost our challenge was like, you know, with Docker, you have that experience. Every developer that's used Docker has that experience of, you know, I just say docker-compose up and I can even ask it to build locally. It instantiates everything, just one command, and my whole app is up and running. Now I can test it. And kind of our challenge to ourselves was like, why cannot deploying to the cloud be

Hmm.

As simple, one command and you're up and running in a cloud. And that's exactly what we have built, right? With Defang, you say that same Dockerfile that you've used to debug locally, and now you're happy. Now you're ready to go to the cloud. You say defang compose up, and you can say, I want to go to this provider, whether that's AWS or GCP or DigitalOcean, or for people who don't even have a cloud account, we have like a playground environment.

Right.

Just to get started. So anyway, that's kind of how the user feedback has influenced what we build and how we build it. There's a lot more that, you know, we can talk about, Leo can share in terms of the develop functionality that we've added based on user input, the debug functionality that we've added based on user input. Those are actually a year ago, those were not as part of the product, but as more users used it, And they gave us feedback, we added those.

Yeah, it's kind of following the formula for a startup, right? So we released early, we got some feedback. For example, I think if you go back a year and a half ago, when we hadn't released our private beta yet, I think back then we were still discussing, are we a platform? Should we be hosting people's stuff? Hosting it the right way? You know, we know how it stuff should be hosted, what features we should expose, which ones we shouldn't, which ones we should, you know, be opinionated about or hide completely. And so that was an early discussion we had. Should we be a platform? And it's only like towards the MVP release that we said, no, let's focus on the tool. Let's not be a platform. There's many platforms out there. Of course, you have Amazon, Azure, DigitalOcean, Heroku. Now the newer ones, Fly, Render, et cetera. And so we consciously decided, no, okay, let's focus on that tool and let's not be yet another platform. If we can build a tool that takes care of, you know, then the platform doesn't matter anymore. You know, you can deploy it anywhere. That was one of the earliest discussions. And soon after, another maybe data point, how people said, hey, that's cool that You can help me deploy, but, you know, make sure I want to use my AWS credits. This was also a data point. I have— AWS gave me 50,000 credits. I can't use that if you're hosting for me. I want to use the credits. I want to be hosted in my account. And so this is also a data point where we said, okay, yeah, if we have a tool that deploys for the user, then they can choose to use their, you know, their credits. If they need to do an audit, early feedback, you know, my customer requires me to do audits. Yeah, if I'm hosting your stuff, there's no chance you can, I have to pass audits before you can pass audits. So now I'm blocking you, right? Okay, well, let's not block them. We deploy to their account, they pass their audits on their own timeline, right? So all of these were like early data points that made, that shaped the product into the deployment tool we have today.

Talk to users. That's the only way, right? It's like, listen to you, listen to the users, pay attention to them. It's like that Mandalorian meme. This is the way. So I want to talk about the growth aspect. I think hundreds of users are already using Defang right now. How do you think about what are the growth tactics that you've used, at least in the initial days, to go present Defang to the users?

Yeah. So we released a public beta middle of 2024. So it's been about 6 months, just under 6 months. And when we released it again, we said, okay, you know, we'd like to have 1,000 users by the end of this year because those users are giving us good feedback. They're testing or, you know, exercising various aspects of the platform and making sure everything works as we intend to make improvements, right? So as of today, we're well past that goal already. You know, we're

Nice.

Almost at 1,500. So, you know, a lot of that is word of mouth, but also working with especially these early in career professionals or hobbyists or students who are just trying to do maybe like a hackathon project or a weekend project or their hobby project on the side, right? And they For them to be able to access the cloud and deal with all the complexity is a very heavy lift. And we make the cloud, whichever cloud they prefer, accessible, way more accessible to them, right? So that's kind of where we're starting. And now, as we are releasing our V1, this is the first time you can pay for it and it's kind of ready for production use. We're starting to see that next layer of startups. software studios, individual contractors who do work on behalf of others saying, okay, this is a tool now that will make my life easier, right? I can, you know, when we say make things simpler, the way we measure is like, how much time would it take you without the tool and how much time does it take you with the tool, right? So, and our sort of North Star where we want to get to is like, if it, things should be like 10 times faster. With Defang than without. So if something would take you a week to do without Defang, it should take you like a half day with Defang. If something takes you a day to do, it should take you like a half hour.

Right.

And we're seeing that in our early users. Literally, they can go from, you know, I mentioned the develop functionality and the— and then of course we've talked about the deploy and then the debug. We can double-click into those develop and debug as well. But literally a lot of our users go from prompt to an application outline that we can generate for them.

Hmm.

And then they debug it a little bit on their local machine, make sure everything is the way they want. Then with one command, deploy to the cloud. And if there's any extra problems that surface because now you have moved to the cloud, we help them debug that. And the whole thing is up and running. Literally Leo shows that whole sequence in like within 5 minutes. But, you know, even if you say, Within a half an hour or an hour to go from prompt to fully deployed application in an AWS or a GCP or a DigitalOcean in the space of an hour. That is eye-opening for people, right? And we get these verbatim quotes like, what sorcery is this? I can hardly believe my eyes, right? Which, you know, it tells you that, okay, we've hit a nerve here that we've met a need that wasn't necessarily being served before. Right.

I love that. I love the speed and simplicity. That's what I think kind of should be your one-word statement. That's what brands do, right? Like when you talk about branding, it's all about, like, I think for you it's speed, how fast it needs to go.

Simplify. If you go to our website or slide decks, we'll say cloud simplified. That's kind of what we're trying to do, simplify the cloud.

I have a question for Prakash. Like, I got very curious when I'm doing some research and, you know, just going through some, some of your previous hats that you wore. You were a CTO at Microsoft for Asia Pacific R&D group. You were VP of Engineering at Workday. You were VP as well at AWS. Now you're a CEO. I want— I just got curious, and I think you both, and I think all 3 of you have very technical strong backgrounds. Question to you, Prakash, is what made you switch? It's like, well, how— what made you go from, you know, being such a strong technical person to like the CEO hat, wearing the CEO hat at DeFi? Yeah, and,

you know, I think that's a great question. You know, in the technology industry, you always have to be learning, right? Things are always changing. What was true 5 years ago, 10 years ago, or the skills you needed or the technologies people are using, it's always changing. So if you're asking in terms of career, for me, it's always been like, you know, kind of getting on one growth curve and growing with a particular trend, whether that might have been, you know, servers in the 2000s to cloud in the 2010s. 2010s and growing with it and then learning new skills as the next wave comes along. Right. So, yeah, each of those previous experiences, I learned a lot and hopefully shared that with others as well. But you get to at some point, like, okay, I need to kind of pop out, get back to the basics and learn from the very bottom. Right. And build something up. And I think that's a pattern you'll see in my career. And it's been fun to do it that way. Otherwise, you kind of get— you grow into leading a large team and you're not doing technical work anymore. You're not close to the product, you're not close to customers, and you kind of get stuck in a management role, right? Where most of your time goes towards other things.

Hmm.

So to me, it's always been great to— okay, you can do that, but then after a while you pop out and Go back to the bottom and start learning again because things have changed, right?

I love that. Yeah, go back to the basics, first principles, always. Yeah, let's talk about today's launch. So, talk to me about what you're shipping today on Product Hunt. If you want to just give, you know, listeners what have you done before, when, what made you do this launch, like what is that progression looks like?

Yeah, I will start and Leo, I'm sure, can add there. Yeah, as we said, you know, we've been in beta since July and we've got a lot of feedback. So today with V1, as we're calling it, you know, for the first time now you can use our product in production. So you can purchase the product and we are certifying our AWS target for production. So people can actually deploy production apps there. Go to our website for more details. And we're also announcing a preview on GCP. So we have already a preview on DigitalOcean and now we've added GCP to that list. So we're very happy. to really have a variety of choice. You know, choice is also a very important thing for us. So giving customers that choice, they can build an application once and then choose to deploy wherever they wish to go. Big day for us. You know, now it's kind of the real work starts to,

you

know, get production uses and support those customers going forward.

Yeah. I'll add a little bit of maybe technical detail to that. So when we launched our beta, and also the approach we took, like Prakash mentioned, is to be bottoms up, right? So we started talking to the hobbyists, the individual contributors. We started sponsoring some hackathons, some meetups, and we got early feedback from them, like tremendous feedback. All of those are, a lot of those are projects that people build for their hobbies, right? So they're, they have a project, an idea they want to build. Maybe it's a hackathon, maybe it's a weekend, you know, programmers just have ideas and they want to build something. Sure, knock yourself out. Defang is a perfect tool for that. And in fact, it was also part of the inspiration, like, like a hackathon 10 years ago, I built a project called Nounly and I've been wanting to keep that up and running production style since I built it 10 years ago. And so also those experiences are important to me. Like, can you turn a hobby into a real product, like into a project that is still running 10 years later? And so, and that's our promise of the V1, right? So no, this is not a toy anymore. This is not for your hobby projects, just for your hobby projects.

Right.

You can use this to build your startup. You can use this to build a product. You can use this to build a website that's still running like 10 years later, like Nounly. And so that, that's our V1 where we, where we say, yes, we have made the quality bar, the quality bar that we've set for ourselves. And we are assuring build your next startup with this technology.

Leo casually dropping 10 years ago side project is That's the highlight of this conversation, just casually. I love that.

That was a toy project and it's still running. And so I think that is pretty fun.

I love that. I love that. Couple of more things before we talk about, like, we wanna ask also about the future and we live in the, everybody's riding the AI wave. So I wanna ask about how are you harnessing the power of AI? What are some things that you offer from DFANG that are going to help builders use AI as well?

Yeah, Leo, go for it.

Yeah, I think it's important to emphasize that the core of the product is it's a predictable translation of the logical description of your app to the physical description that the cloud needs, right? So that is, Prakash mentioned, rule-based based on, are you going to need a load balancer, yes or no? Are you going to need a gateway, yes or no? All based on rules, perhaps with some input from the real-time metrics, right? So this service is not going to get called often, so we'll use a different topology for that. But we saw early on, okay, we have built a cool tool to translate your logical to physical, but it still has some requirements to get started. Like, okay, you need a Docker Compose file, maybe you need a Dockerfile. And some people don't have that, right? So how can we open up the tool to reach more users? And so we added a generative component to that first step. And that is the develop step. You know, okay, I want to get started. What do I do? And so we are leveraging generative AI there. So from a language prompt, we generate, the tool generates, Defang generates an outline of your application. That is to get you started. That already works, right? You can already generate that outline, deploy it as is, and 9 out of 10 times, it might be a subset of what you want, but it'll work. And that will get you in that iteration loop. And now it gets much easier to actually add additional functionality, change something, change a color, put a button, this kind of loop, right? It has been very useful there. And then what we saw, again, I think it's a nice anecdote. We hired interns early 2024. We started hiring interns to help us expand our sample repository. You know, we have a lot of samples now. By now it's more than 60, 70 samples that you can browse on our website or using the tool. And So the interns started building these samples and testing them with the tool. And they ran into maybe like problems they didn't know directly how to solve. And it could be a typo. It could be like a missing dependency, these kinds of issues that as an experienced developer, you might have seen these before. You say, oh, the service is not responding. We must be listening on the wrong port. Or the build failed. It must be a missing dependency. Or the version is old or something like that. You kind of have enough experiences to guide you and find the pain point. But for the interns, that was not the case, not yet anyway. They didn't have the muscle memory yet, right? And so we added generative AI in the debugging part as well. So now when you deploy something with Defang and the deployment fails, it actually triggers the AI debugger. And the AI debugger gets a view of your whole application, not just your source code. It also gets the logs from the cloud provider. It gets the compose file, the logical description of your app. It gets some build logs if they're available, right? And so having this full view of, you know, what just happened allows the AI debugger really to pinpoint, hey, yeah, you got the wrong port number, right? Your application is listening on port 3000, but your Compose file didn't mention that or stuff like that. Oh, hey, you're using a library that you forgot to install, right? And so this is how you should install it. And the intern productivity just went through the roof, right? So this is why we have now so many samples, because once they had this tool to help them, they were no longer bothering, you know, bothering me, for example, like, hey, why doesn't it work? And it's literally an accelerator. It's literally like a multiplier for them. And not just for them, right? Like everybody benefits from having like somebody watching over your shoulder and checking, hey, is this number exactly what you put in the other file? You know, there's dependencies. And so this AI debugger that really helps you interpret the logs has been a game changer.

Yeah.

And

just to add to that, the way we think about what we're building in those, you know, develop and debug modules is We're building an AI agent, right? Because we're not building the LLM. We use other LLMs that are out there. Obviously people have invested a lot of money to build those. But what we are doing is taking, for example, the prompt that the user gives us and going back and forth with the LLM to make sure the LLM understands that prompt in the right way, generates the right output. If it gets something that doesn't look right, we'll go back and say, you know, you got this part right, but you didn't get this part right. So we do a lot of sort of back and forth, right? And same for the debug part as well. So now going forward, you asked a little bit about roadmap. We're investing in making that smarter, that agent technology smarter so that we can take more complex prompts and have like not just a single service app, but a multi-service app where there are different components moving parts, right? So I think this is a huge area. Where we can drive a lot of innovation in the future. At the same time, it's important, like Leo started by saying, you know, it's not like AI is a hammer and everything is a nail. We have to know where to use it and where not to use it. So when it comes time to go from Compose file to your infrastructure as code, that's all 100% predictable rules-based. And I think it'll continue to be rules-based with, like Leo said, runtime feedback so that we can then optimize based on what's happening.

Is that how you differentiate yourself from competitors? How do you kind of handle that, show the users that, you know, we are better, we have better solutions? Again, going back to the simplicity aspect of it. Yeah, talk to me about like handling competition in this space.

Yeah, and you know, one of the things you learn at AWS definitely is part of their core principles is to focus on the customer, not necessarily on competitors, right? Just make sure customers You work backwards from what customers need and they're really delighted. Having said that, I think it's important to know what else is out there and how we are differentiated. I think the first thing I'll say is the fact that we use the Compose file as our app description format is fairly unique. You know, others use other types of, you know, app extensions or some things like that, but there's already a ready-made audience that uses Compose. And so I think we have a, you know, building on that, on that foundation is a good place for us to start. The other couple of things I'll say is, you know, Fang is multi-language. So we don't really care what language you use as long as, you know, we can build it and deploy it as onto those clouds. And it's also multi-cloud, right? So your app is literally cloud agnostic. And we can talk about how we handle things like databases and so on, which we do. We still let you use the best-in-class implementation on each cloud, but the app description is cloud agnostic. I think that's a very powerful approach to take where you might, as a customer, never use, never move from one cloud to the other. But just knowing that you have that choice is important to people, you know, especially now it's a very competitive landscape. Everybody's coming out with new features. Right. And you might want to have that option that I can go somewhere else if I want to use a special feature that a particular vendor has, right? We're, we're just trying to make it accessible to everyone. So I think those 3 things, like, uh, Compose as a standard, language agnostic, cloud agnostic, and then this full, full spectrum from, you know, develop to deploy to debug. I think all of those are fairly differentiated. Uh, Leo?

It's

like a,

yeah, uh, not much to add there. Uh, I, um, There is other people, other companies in the tooling space, but they all have a different focus. Some are more focused on frontend development. Some are specific to a language or specific to a cloud. So we really went from, okay, logical to physical. And then we are in charge of that mapping and we can get smarter. That mapping can get smarter. That mapping gets can get optimized per cloud. And so that's really where we are focusing on, what we're focusing on.

And some people ask, uh, Shura, just to clarify there, some people ask like, so are you— should we view you as a competitor to infrastructure as code vendors? And that's a good question. We don't view it that way. We use infrastructure as code. So DFANG is a tool that emits infrastructure as code, right? So we love that because we don't want people clicking around in consoles to make changes to their— so we're absolutely a fan of infrastructure as code. We just think it's complex to write that code, so we're making it easy by having the tool emit it.

Nice. And, um, you've, you both had so much experience, you know, been in the industry for, for a long time. Maybe I was a baby. I'm curious on what are some, you know, important lessons you've learned along the way as an operator, as a startup operator. Now you're a founder, both of you are founders and you're running your own startup. So talk to me about the lessons you've learned that you're implementing now, the dos and the don'ts. Maybe Leo, you want to start?

Yeah, that is the kind of question that I can have a lot of answers, I think. So yeah, Defang is my third startup. I actually had my first startup right out of college. I dropped out, one of those, dropped out. And I've definitely made mistakes, right? So I think the importance of selling, I think I, in the early days, I tend to focus on building stuff. And maybe didn't speak enough to customers. So that really taught me, yeah, you have to constantly have that loop going, right? What is the feedback that people give me? You can't stay in your office for a year, build something, and then go out there and check what people think of it. You might have wasted a year of your time because you built something that nobody is interested in.

Yeah. Build something people want.

And so that was, I think, one of the earliest lessons. For me was, yeah, keep that loop going constantly, the constant feedback.

Yeah. And I'll add like, you know, in terms of startups, I think number one thing is the team, right? So if you have the right team, you will find the right way, right? Or you will find the right problem to solve. So for us, having the group of founders that have different skills, even though we work with each other multiple times before, but we all bring something different. And having that understanding of how the other person works so that we know kind of how to make the team really function as something bigger than the sum of the parts, the founding team. And then as we expand and bring other people in, for us, it's always been a small team that's high quality can move a lot faster than even a bigger team where there's more communication needed or more— You know, just overhead, right? So keeping the team small, focused, high-quality people, I think lets us move fast and do more with less. You know, I think you mentioned the complexity of what we are trying to tackle and already the level of functionality we offer, you know, multiple clouds, develop, deploy, debug. And we've all done this. We've done all this with a relatively small team. So I think that's really, really important.

Yeah, I truly believe in lean teams. I think for some reason they just work. And because they're like a bunch of hungry, angry, hungry people, like founders, like trying to attack a problem. So it always works. And I think this question is both of you, whoever wants to go first, go first. But I want to talk about or ask about the future. Like, where do you think, not just about DeFang, but generally, I won't call it like deployment industry or like at least people deploying apps. So. early, like late '90s or 2000s, it's like FTP, you do it manually. And now then the cloud came and then I want to ask like where you see the movement is going and how do you think DeFi is going to push that movement?

Yeah, I think we're, we've touched on this a couple of times in what we talked about. I think we're excited about the system getting smarter over time. Right. This kind of— today you can say what we have built so far is better. DFang can do a better job at deploying your application than probably 80% of DevOps people out there, right? Because we've applied the best practices in the industry, whether that's towards AWS or GCP or DigitalOcean. We've gone through the security reviews, we've gone through the Well-Architected reviews. So already I think we are giving you an above average experience, but over time. As the system gets smarter, it's able to learn, it's able to roll some of that even real-time feedback from your application, how it's working to more optimal configurations. Again, this is not something we do today, but it's on our roadmap. I think that's where you'll start to see that it's just gonna be the way you would want to do things, right? Like let the tool drive and you focus on your app and the sort of logical description of your app, let the tool drive all the sort of downstream of how to deploy it, how to optimize it, how to make sure it's compliant, secure. So I think that's, you can clearly see that's the trend and you can see it from history. You can see it now playing out, but that's also where obviously we're headed.

Yeah. Yeah. I agree. I think having a logical description It's no longer an option in the future. That is how you describe your application. And it's a natural evolution of how we go from very low-level code to higher-level code, right? It happens in multithreading. We used to write to individual threads, like how many cores does my CPU have? And now you write asynchronous code. Okay, I don't wanna deal with CPU cores. Let the language runtime take care of that. You just follow that trend. Everything gets like to a higher level description of what you're trying to achieve. And to us, Compose is just that initial stepping stone. God knows what the logical description looks like 2 years from now, right? Maybe it's only language prompts, but that is kind of inevitable. The description of your application will get higher and higher level.

Love that, guys. Such a fascinating conversation. Generally, you know, I don't, I don't have people like you on my podcast. You're highly technical and you've kind of are, I would say, kind of, you know, pushing the future and kind of being part of that. So, so interesting, so fascinating, and appreciate you for joining. We're definitely going to include the Product Hunt link in the show notes and, you know, ask people to like kind of support and all that. But yeah, any closing thoughts before we wrap up?

No, we're excited for V1 and what our users, customers will do with it. So go check it out, defang.io.

Yeah, can't wait to see the next startup built on our technology, our tool. That'd be awesome.

Love that. Yeah, love that. All right guys, that's it folks. Thanks for listening and appreciate, you know, both Prakash and Leah for joining in, you know, and kind of like dropping so much knowledge from their experience of being founders before and operators before. So stay tuned for more conversations like this and take care and build. That's it.

Thank you, Sharath.