Software Huddle - Enterprise-grade Dev Environments with Ivan Burazin

Episode Date: May 7, 2024

Today’s guest is Ivan Burazin, the co-founder and CEO of Daytona, an actual creator of the Shift Developer Conference that he sold some time ago to Infobip. Ivan has tons of experience building developer tools, he has been working on dev environments for over a decade. In this interview, we talk about another company he founded called CodeAnywhere that eventually led to the founding of Daytona. Daytona is a dev environment management platform. It sits between your IDE and the cloud, taking care of standardizing your dev environments, regardless of whether you're building on your desktop or deploying to production. They're taking the best of what leading technology companies like Google, Uber, and Meta have built internally and bringing that to the rest of the world. Software Huddle ⤵︎ X: https://twitter.com/SoftwareHuddle Substack: https://softwarehuddle.substack.com/

Hey there, Sean here, one of the hosts of Software Huddle, and we have a special treat for you today. Alex and I were recently in Miami at the InfoBip Shift Developer Conference doing unsigned interviews, and this was the first one in that series. If you're watching the video version of this, things are going to look a little bit different than our usual setup since we recorded these actually in person with the guests. And first up is Ivan Barazin, the co-founder and CEO of Daytona, an actual creator of the Shift Developer Conference that he sold some time ago to Infobip. I've known Ivan for years. He's a super smart guy, has tons of experience building developer tools, has been working on dev environments for over a

decade. In this interview, we talk about another company he founded called Code Anywhere that eventually led to the founding of Daytona. Daytona is a dev environment management platform. It's just between your IDE and the cloud, taking care of standardizing your dev environments, regardless of whether you're building on your desktop or deploying to production. They're taking the best of what leading technology companies like Google, Uber, and Meta have built internally and bringing that to the rest of the world. I love talking to Ivan, so I think you'll enjoy this interview. We'll have a few more like this coming from the event. If you ever have questions or suggestions for the show,

feel free to reach out to me or Alex, and thanks for listening and over to the show. Hi, welcome to Software Huddle. Thanks for having me. Yeah, awesome. So we're here at the InfoBip Shift Conference in Miami, which is a conference that you actually started, and now you're here as a participant, speaker.

So I guess, guess like does it feel weird to be the person who's like created the conference originally organized it and now you're kind of just here you've handed it off you're not like actually doing it anymore i feel that so this is the second conference in the series um so the main one is in uh in europe on the mediterranean much bigger you've been there a couple times. And so going to that one last year was weirder than this one. This is like a new foray into the US. It's much smaller. And so it's also quite similar to last time.

So it is kind of odd, but I have to say that one, which has been going on for like 12 years, that one's more sort of like hits home and sort of. Yeah, you probably have a ton of memories. Yeah. Yeah, exactly. Painful ones. Well, at least now you probably have a ton of memories. Yeah, yeah, exactly. Painful ones. Yeah.

Well, at least now you probably don't have all the anxiety. No, absolutely not. Now I'm a speaker. Yeah, and you can make fun of them when things don't go right. Yeah. So I want to talk about Daytona, your new company, but I think it also would be useful to give some sort of history and context for some of the stuff you did in the past because i know

daytona is doing things uh you know beyond what you were doing at your other company code anywhere but i think there is some relevant history from that experience so can you talk a little bit about like code anywhere and the original project of php anywhere and where is that project now yeah sure so definitely planted the seed and the reason daya existed. Like if there was no code anywhere, originally, if there was no code anywhere, there would be no Daytona, basically. And so it started in 2009 for like some of the people that might be listening might be very early, but it not existed. So this is pre-Web 2.0, this Web 1.0. And so my co-founder,ran we were he the company I owned then was Bank was a client and he was a CIO and he was like working on the

hacking through this idea about creating a browser-based editor it was a text editor with an FTP connector as you did things in 2009 yeah and I'm like oh this is awesome we have to start a company like screw everything we're doing we're going to do this they said you're an idiot I'm like no oh, this is awesome. We have to start a company. Like, screw everything we're doing. We're going to do this. And he said, you're an idiot. I'm like, no, no, seriously. I've read it on TechCrunch. TechCrunch was there at that point. But it was still, TechCrunch was a side project for Mark Arrington.

What's his name? So it wasn't the full thing yet. Even TechCrunch wasn't successful. And he's like, fine, like, here's half of whatever this is. And, like, let's make something of this. And that was sort of the, sort of where we kicked off of creating a cloud-based IDE. So we originally called it PHP Anywhere, or Benjamin did,

because he was a PHP developer and the idea was. Well it's 2009, like, what were your options? Yeah, ASP.net, ASP, 90.net. Yeah, 90.net. And so that was it, And so BHP was born. And so we worked on that as like a side project. Like you couldn't do anything. There was no web 2.0.

You couldn't do syntax highlighting. We actually tried to do it in, I was like pretty proficient in Flash than ActionScript. So I was like, I was going to try, we're trying to build this out in like ActionScript, like a syntax highlighting. Likely we didn't get it very far.

You know, Ajax came up, which was, you know, all the stuff that you do on the client side. And we were able to create like a syntax highlighting in your browser. And so when the technology was there, we actually said, okay, let's do this full time. And we rebranded it to Code Anywhere. I sold my previous services company.

He left the bank, and we started doing that. And so the idea was similar to now that developers can just click a button, everything automatically works. At this time, Google Docs became a thing. Everything went to the browser. It's like, oh, why doesn't software development come there? Little did we know that, no, it's not going that way.

But anyway, it became somewhat successful i think like almost two and a half million people signed up um there was a bit of investment in the product as well um at one we worked on it till 2016 17 i want to say really hard and it basically got to a revenue point that it could not expand from uh the users were individual users, there was no enterprise expansion. Because you were constrained by a browser-based editor to access this dev environment,

it was very hard for developers in a enterprise setting to want to adopt it, and also for people, for companies to buy it, because it was very much a SaaS-type product. So there's no security compliance, run it behind your firewall type thing. Anyway, we didn't even know how to do that. Anyway, we ended up at one point saying, oh, this is not going very far. We paid back all the investors and basically one person was left running it and we went off to do other things. Hence, Shift was born. We did Shift. And so, sold Shift, fast-forwarding,

sold Shift, or InfoPay acquired it and ran a developer experience department for a couple of years. But what was interesting, about 16 months ago, 18 months ago, whatever, time goes super fast, we started getting pull from the market about development environments. So, your analysts, you know, Gartner, Forrester, IDC, you know, RedMonk, CB Insights, they wanted to be briefed about this thing. They didn't have the correct name, but they were interested. We actually got people calling us, so we were interested in that. Then we had some ideas.

We started poking around again with technical solutions for what people are asking for. We got some interesting flagship design partners, which are customers now. Can't say them yet, but like super well known companies. Not tech companies, but like they've been around for a long, long time. And like, oh, okay, these big companies

are interested in this. And we also got acquirers, so like people wanted to like buy whatever we had at that point. So we could have actually sold it in January of last year, the thing that was there. And so it was like a small, but it was like single digit million thing. We could have actually sold it in January of last year, the thing that was there. And so it was like a small, but it was like single digit million thing. We could have sold that.

And we discussed, so me, Vedran and Goran, who's the third co-founder and was the person managing Code Anywhere, and the two of them, I was actually okay to sell it. And they were like, we did this once, we can do it again, really? And they were like, no, we're not doing this. They wanted quite a bit more.

And they're like, no, we're not doing this. I'm like, okay, if we're not doing this, then we're actually doing this as a company again. We did a bunch of research as well, so it wasn't a flim of the, when we did PHP Anywhere or Code Anywhere, it was basically like, we're talking now. At the end of the conversation,

I was like 50% owner of this thing research right while these this sort of happened from 18 months ago six months in like we were building this we did our research we found that like tech companies Google Facebook LinkedIn Shopify into it event right like all these tech companies have built something internally because of this huge pain problem painful a point. The problem sort of also starts happening above 50. You start feeling it. Over 100, you certainly feel it on the engineering side of the efficiency of developers, the satisfaction.

And also, of course, the DevOps or platform engineering team has to help solve all of these problems. So, oh, this is a big issue here. Security, as I mentioned in the talk, like a lot of companies are using terminal services to solve these development environments. It's like, okay, there seems to be pull from the market. People

want to buy it as customers. People want to purchase it as acquirers. Analysts are interested and there seems to be a market problem and we know who the ICP is now. It's like, oh, okay. I didn't even know what ICP was the first time. So I was like, okay, we're doing this. And so I quit my job at Infobip.

Actually, I gave my notice on shift last year. So that was fun. I left some stock on the table as well, but I think it was a big enough sort of thing to pursue. And so, sorry, it went a little long on that story, but that's how we came to it. Anyway, so you're saying a lot of companies are building their own internal in-browser editors?

So to define it, not the in-browser editor. So that's the part of Code Anywhere that's the least important. What's important is within browser editor, you still had a development environment that you essentially like a container that you had to spin up for the person. And so that container that was spun up and orchestrated, that service is what these companies

are very much interested in. So some sort of like easy dev prod parity that I can have. Exactly. So it's very much, this is very much an infra tool. So we spin up and manage all the infra for the dev environment versus what you have right now for your prod Yeah, very similar but you in in dev basically have those same issues Except for the scale in the sense of the amount of hits you have on the product everything else is identical

Yeah, and then for code anywhere. Do you think that you know? Why maybe didn't you were able to have it like take off the same way? was why maybe didn't you were able to have it like take off the same way uh was partly was it like just too early or were you kind of maybe attacking the problem uh maybe it's sort of the wrong interpretation of the problem because you're focused on sort of the like you said like the least important part which is the in browser, but like really what people value is this like dev environment. For sure. I think we did everything wrong. So one thing, yeah, we didn't understand. So again, when I get to ICP, so when we look at Daytona now, the user is the developer, but the buyer is not the developer. The buyer is the

engineering manager, platform engineering manager, CISO sometimes for security, but the developer is just the user. And I say just in the sense of not that they're least important, but they're not the one that's going to make the transaction. So that's why when we did, and I'm getting ahead of myself, when we decided to do something open source, we open sourced everything of value to the developer because there's no monetary value in that.

Everything that's valuable to the engineering manager or cso that is what's charged for but you as a developer don't care about that like that you're not missing that in the open source part um anyway so on one hand we didn't understand who we were essentially we were trying to sell to the developer right wrong yeah wrong that's a tough tough one yeah not getting that um the other thing is we were early, so there's a lot of things that were not unlocked. So IDEs, so JetBrains and VS Code, now support, or over the last few years, support remote dev environments as if they were local.

That didn't exist. So you had to either use terminal services or a browser. There was no other way to do that. Also, remote development was not that much of a thing. Now, like 50% of developers work remotely, either because of, you know, larger language models they're trying to train, data locality,

like they have to be close to a data source. So like if you have a large bunch of data, by the time the data gets to your laptop, that just like takes a bunch of time. You'd rather have the environment like in the same data center so it travels really fast. Or again, security or geolocation, so I have to run it.

I'm an EU company, have to be in the EU, or I'm the Department of Defense of the US. It has to run like in this very specific place, right? So, yeah. Like what, like you talked about how like, if you're a 50 person organization, you kind of like start to feel the pain, hundreds like later.

What is that pain? Like, what is the problem that, like, these remote dev environments actually, like, solve for companies? So I'll just say, like, it's not just remote dev, but, like, the automation of all dev environments, so both local and remote. So what Daytona does, and I talked this a bit in the call,

is that we very much were inspired by Shopify that started, well, the way they started is that they, before a laptop would get to the engineer, the team that was managing dev environments actually installed everything that you need on your laptop. So then when you got it, you could just get off to the race and start working. And so they had a whole team that would help you spin up and manage these local dev environments. And then at one point, they said, oh, the laptop is too small for these projects that we're working on. We have to create a remote development environment.

And then they started from scratch and then noticed they were doing the same thing twice. And so they created this one experience that allows the developer to create a dev environment, completely automated, and it always works local or remote depending on use case, size, whatever. Because if you're doing a front-end marketing landing page, there's no point in spinning up a meter on AWS or you don't need anything. And you always have a fraction of a lag in a terminal

because it's not in your local host. And so why would you not run that local? There's no security issues, like why not? But you still don't wanna have a different way of work than you're working when you're doing remotely. So I digress the question, I forgot what it was. Basically one problem is like the remote dev environment solving for these different companies.

Oh sure, so that's what I was gonna get to too. So the problem, there's a couple of problems. And different companies have different ways they weight these problems. So I'll take the easiest one, which is first, which is the productivity of the developer. Whereas, like, developers spend half their time wasted on either troubleshooting or managing the dev environment itself. And if the three of us are in a startup, like if I have an issue, like you'll come to my laptop and you'll help me fix that.

And so as you add people, that becomes more and more complex and harder to do. So you're a thousand person organization and now you have a new engineer. It takes them on average two weeks to get their first code deployed, right? Versus if there's the three of us,

we'll get it the first day. And so how do we get it back to that first day? The other thing is that developers in these large organizations, and especially non-tech, like what I call tech is, you know, the Ubers, Googles, Shopifys of the world. So we're talking, I'm not trying to pick on names, but banks, insurance, whatever. Not necessarily engineering first. Yeah, not engineering, but they still have 10,000 engineers.

And so in these organizations, a lot of them don't even use Docker locally, right? There's a level of sophistication that comes with these tech companies that have not, that has not trickled down to these large enterprises. And so there's a longer burden for these teams to get to that same level.

And so with the automation of this they get without having to learn teach or have anyone help them out they get the same level of automation and the same type of development environment that you do in these yeah i mean i think when you're sort of like steeped in the tech world like the three of us you start to you generally make assumptions about like where the rest of the world is and in terms of like you know everybody's on the cloud but the reality is only like 20 percent of you know businesses are on the cloud or you know everybody's using this like modern modern stack and stuff and it's just not they're not yeah and like you know when last year i was at a conference about APIs and I saw a large bank in Europe that

was presenting and their big thing, their big like innovation investment that they made in the last year was they're now running on APIs. And it's like, well, good for you, but that's like not necessarily new news, but that's like the reality of the business. So how can you help shorten the gap essentially from the, what, you you know google or something like that is doing versus like you know a bank or or maybe some other type of yeah really and some of the things some of the conversations we're having is also for the ones that are trying to modernize um their their environments like they don't even they don't use containers microservice like nothing it's like even a service like i'm not saying daytona but even a service like daytona helps

them sort of get a step into that because they don't have to think about that part of it. They can still work the same stack that they're doing, but now we sort of take care of the quote unquote packaging of that dev environment for them. So it is not, you know, cloud native as it should for real, but it is sort of getting them into that way of work. Where are the tools like Codespaces and stuff like that not live up to this expectation of some of these companies? I know that the tagline I think you guys have is Codespaces for the enterprise or something like that. That was our first tagline for the enterprise product and it still rings true.

So basically what there was a, I forgot who the quote was. It was like Mark Benioff or someone else. It's like, what happens if Google comes into your market? Well, then you've succeeded, right? Because then there's someone that wanted to, then there's a proof point that the market exists. And so Codespaces was something that was missing when we were doing Code Anywhere. Like if that had happened,

probably there would have been a bigger sort of jump. Codespaces does a really good job of being integrated inside of GitHub. And if you use github.com, there's one button and it'll spin up the dev environment for you. It's an amazing experience and we very much look to that, what they did. But there's a couple of fundamental problems with that. One is it only works on GitHub.com.

So not GitHub Enterprise, not Bitbucket, not GitLab, not GitLab On-Prem, not. Right, yeah. So you're basically vendor locked in to that. Not even the vendors. Like even if you have GitHub Enterprise, you can't on-prem. If you have a GitHub Enterprise on-prem, you can't use it at all. So that leaves you, that's 74% of the market cannot use it. I'm not saying, like if everyone wanted to use it,

I'd use github.com, still 74% of the market can't use it. So that's one. The other thing is that it is inefficient from a cost perspective because they basically charge you for a full VM for each developer, which you might not want to do. When you're a developer writing code, you're writing it in your IDE,

you're not using 32 gigs or 64 gigs. You're essentially just using it when you're running the code, not when you're not using 32 gigs or 64 gigs. You're essentially just using it when you're running the code, not when you're typing the code, right? So that is a huge, for them it's great. It sells Azure, right? So that's there. But also it is, from a security perspective, it's also just a SaaS. So one, so not just security, but it's a SaaS. So a lot of companies can't use it. The companies we're talking to, enterprise, they all want to run it on their infra, be not just security, but it's a SaaS, so a lot of companies can't use it.

The companies we're talking to, enterprise, they all want to run it on their infra, be it their cloud, their air gap cloud, or their completely on-prem. Yeah. But also, not even that, if you're a large company, you usually have credits that you have to use or contractual spend of cloud. So a couple of companies I know, they have like 10, 15, $20 million a year that they have to spend. And so if I have to spend that and it's hard for me to spend it,

like why would I spend another, whatever, 100, 200, 500,000 in Codespaces versus when I can have a service like Daytona or someone else, have that same experience, but I'll retire credits that I have to retire anyway. So those are a couple of reasons why I feel that Codes code spacing isn't quite there but

they have been sort of a spearhead in the headspace of developers that this is actually an okay thing to do yeah I mean they've helped like create the market absolutely yeah that's the exact point so it's great you've created the market and now when we come it's like we're not idiots like which people have told us before it's like oh yeah that's totally cool but i can't use it for whatever reason it's like yes you can here you go so what does that look like to onboard a new you know a new new customer comes in they have all these applications what does that look like to get started with daytona so that you can push these remote environments so if there's a um installation script basically a terraform script that they can install on their infra.

They should get it up. We had a POC yesterday. They were super fast. They got it up in one day. Awesome. We've had some people that takes like a week or two. Our team takes an hour, but to each his own. So they get it up and running.

The developer essentially can, mid-project, just check out the repo they've been working on and start working. So for the developer, there's essentially, I like to say, almost zero transition cost. There is in the sense of your mind has to be like, oh, now I have to write this command, Daytona create versus whatever I was doing up until now. But it's very, very little.

It's as small as can be transition from what they were doing now to using a Daytona. And am I tearing down the environment every night when I log off? Or am I keeping up my environment? The thesis is that they're ephemeral so that they basically die. The

admin product, by default, you can change these defaults. If you're not working on it for half an hour, it'll just go to sleep, not to waste resources. And if you don't use it for two weeks, it'll kill it. But you can change that. Some companies want them long lived, so some companies essentially have their laptop in the cloud.

So it's just like one, and it stays there forever, which is an option that you can do as well. Yeah, absolutely. You mentioned sort of like you open sourced the developer parts, but you've kept the other parts. What is that delineation? What are those different components? Sure. It took us a while to figure this out.

So we started with an enterprise product first, and we really wanted to create an open source product. Competitive companies have open source products, but what they did, and this is what my CTO was very adamant that he didn't want to do, is they open sourced the entire enterprise product. And so when you look, that is valuable in the sense like security and compliance, people can take a look at the code.

We probably will source available our enterprise as well just for that reason. But you're not actually helping the open source community because if your problem as an individual is I want to check out

this repository and just do a few commits, make sure it works, then I'm not going to spin up a cluster to do this. It is an oxymoron. It's harder than what you have right now. And so we're like, okay, so how do we make something that will help the individual developer?

And so we did look at the way GitLab did OpenCore, because fundamentally we are OpenCore. But what they did, and we did look at the way GitLab did open core, because fundamentally we are open core. But what they did, and we did it a different way, we'll see if that ends up being a pain for us, is that they have one repository, and then you have different licenses in different folders, essentially, right? So when you check out GitLab,

there's an MIT part and there's a proprietary part, but you get the whole thing, which is just, if I'm trying to contribute, if you're trying to contribute to the source code, it's just more confusing or complex for you. So what we did is actually Daytona has on a top level, sort of like a control plane where it has all the security features, audit logs, RBAC, SSO, whatever. The value there is for the security. Underneath that is the orchestration

of multiple development environments. So like hundreds of thousands of dev environments are spun up and down every time, different sizes, different locations, whatever. And that helps the DevOps team or platform engineering team or whatever. It takes a load off their plate, right? And then inside of each of those dev environments

is what we call the developer experience, what I demoed partially on the talk, which is just one click, it spins it up, it executes all the code, it connects your VS code locally, or JetBrains, it adds reverse proxy, all these things that you sort of interact with the developer and we sort of pulled that out and finished it and created its own sort of product out of that.

And what we created is a really, really small repository. And we also compiled it into a single binary. So you download it, you run it, and it just works. That's it. There's no complication. And we've got, we had contributors. We open sourced it like a month ago. Like we had a contributor 30 minutes in.

Wow. Yeah. Because it's like i assume it's a good problem probably did an okay project but also that it's really simple to figure out what you need to do there so user developer like oh this makes my life easier what what we essentially gave is like a code spaces sas like experience and it runs locally on your machine it also runs remotely obviously but you get get a SaaS experience on your local machine, which we think is very unique to the market.

So once a customer gets their dev environment defined through, you said like Terraform or something like that, right? Yeah. Terraform is the orchestration of the enterprise product. The dev environment, we use Kubernetes as an orchestrator, and you get a micro VM as a dev environment. Okay. Yeah, it's all sorry So if I does that mean I have to be like running on Kubernetes and I'm just like run these pods No, no, no, so the enterprise product so you as a developer you don't have to you don't know what's on Kubernetes

Yeah, you don't know that. Yeah, the platform team does but you don't so and also Inside the dev environment you can spin another Kubernetes if you want to. okay? Yeah, so if I have like let's say like a Like a Ruby on rails app and it needs a my sequel server someone on my platform team is gonna like configure What this app looks like and all that stuff and then I as a developer I just run Daytona up Yeah, so if you have like if they configured like a darker compose with all that in there Yeah, you check out repository with that inside of it and Daytona will spin that all for you, yeah. And then, so once I have that set up, then does, like, essentially, how does the IDE connection,

like, I know, like, JetBrains, CS Code, a lot of these support out-of-the-box, like, connections to dev environments. Is that now sort of standard for all IDEs, and is that essentially the workflow that you're seeing developers use? Or are there other like configurations that they have to do?

No, they don't do any. We take care of them for them. And that very much is the way we work. Like even if you're working today on your local machine with a Docker container, VS Code is essentially working remotely. Like you can see that it's a remote connection, even though it's on your machine, but it's a remote connection.

And that same standard is used for these development environments as well. So the only difference is that it's not physically running on the hardware that you're using right now. Okay. And then, so in terms of some of the companies that had done this originally, like Google, Uber, I think Meta, all these big tech companies have essentially separately solved this problem. Do you know what they're doing there? Are their engineers working on some, are they using essentially native IDids running on their on their machines or are they using some in browser coding experience or some combination as far as i know almost all of them

are using vs code like in this in that sense to get it up and running i'm not sure what google i think google has their own thing they're very specific well they have cider which is their in browser but most from my experience there, most people are actually using IntelliJ if they're Java, on Java, and then that is connected to the developer environment, and CIDR is more for like, hey, I don't have access to IntelliJ, and I need to make a...

I think the IntelliJ is also like streamed, the way they do it or something like that. So if they have Chromebooks and it's streamed, they make it work really well, and they're very specific, but it was interesting. So I talked to one of the persons at Uber, one of the people at Uber that did it and they actually made everything work through VS Code. Like even the mobile apps, they code through VS Code.

So they've made it work in that way. And everyone that I've introduced, so I've interviewed half the people that have created this type of product internally and almost everyone uses like VS code or JetBrains Okay, and so that's how they're working. Yeah, how does like mobile development work for the data? Not really. Not really. Yeah, so there's there's a lot of things TBD for that. So one is we only support dev environments that are Linux based currently Yeah, so that's something we're working on right now where you can have any basically machine. So it can be a Windows machine,

a Mac machine, whatever. So you'll be able to do that as well. But mobile is definitely not the best way to do it. And I remember talking to the person over at Uber. Like they had,

it was a very complex setup for them. So they have the Mac machines remotely, but they also had like a farm of iphones and then connected to that originally and then they did a lot of magic yeah to make that remote dev environment for a actual um you know ios mobile phone work i think where we are in the market and

where the market is right now uh the benefit of us trying to create such a thing is sort of still on the edges. So we're still going to focus on the majority of where things are. Yeah, yeah, sure. I mean, what about offline? So offline, yes, offline works. So with, and this is a security free,

so because we've created very uniquely this ability to run a development environment, both locally and remotely, if security allows you to you can have that dev environment like you can check it out locally and have that same experience and just continue working on an airplane or whatever it may be and of course if you have the size of the machine that it can fit otherwise there's no way to work offline i also don't think it's that much a problem like nothing works offline anymore so there is that argument like it doesn't work on an airplane but i can't do anything if i don't

have internet on my airplane so like if i have it i do like i don't have email i don't have anything but yeah i have internet on most airplanes now so for sure and then what's what's like the deployment model so is there like for running like Daytona, am I running that within my cloud environment? You're running it on your infra, whatever you want it to be. So GCP, AWS, it could be Hetzner, it could be whatever. It could be actually, we have a client that has actual like HP servers in her data center and we're installing that. So we're very agnostic to where you want it to be run.

Will you run it ever on your own infra or are you just like, hey, it just makes sense for now? Like for now it's not in the roadmap. I think it's a very, we do it just from a go-to-market perspective. We feel that their code spaces and other competitors are competing on the SaaS part of it. And so it's very crowded.

But also I think that's where the lowest amount of value is because there you have the single developer where we've given an open source equal to that. And you have the SMBs, which essentially don't feel that problem that much. So our thesis now is that there's a huge overhead of both cost and management and services to create a SaaS. There's a lot of competitors in that space and the return on investment is still very low, so we're staying away for that

for the time being. Since you're going after this problem, it doesn't have to be true enterprise if you're starting to feel this pain acutely with 180 years, but it's a decent sized organization. Are there, you know, specific product investments that you end up having to make of probably like from security perspective, privacy perspective, like, like what, what are some of those decisions that you had to do in order to be able to sell into those kinds of companies?

Sure. I mean, the product is, we don't call it a V1. It'll be V1 fairly soon but it is deployed you know in production for a lot of customers but one thing that we found consistently is that these real as you've got a real enterprise large ones they have a lot of table stakes features that are basically security and compliance yeah so they have nothing to do with the product the product experience whatever that is all like there um and i have to say like our plan on like the r&d roadmap for the next year is on one hand the open sourcing getting that like experience better the other hand is just like security just like a bunch of them like like an enormous amount of them so yeah so there's

customers that we can deploy to like right away works right away. There's customers are like, oh, you do need, you know, X, Y, or Z. And then it's like, do you need it tomorrow? When do you plan? The good thing is, or the lucky thing with these very, very large enterprises, they're never buying today for today. They're buying today for like two quarters out. Right. They're buying your roadmap.

Yeah. And so that's totally fine. And that gives us time. Okay. We have to prioritize these features because, and the interesting thing, it's usually not specific to that customer. You'll have three customers later on that'll ask for the same thing.

And you have experience in this, I'm sure as well. Yeah. Was that a new area for you? Like selling to the enterprise and figuring out how that worked? Like what was that like learning there? Very new, very new. Yeah.

It's like, oh, we have this product. Like just go install it. It works. They're like, oh, first here's like this stack of paper. Like, please fill all of these things out. Like, what is this? Oh, this is like who you are. they just go install it works they're like oh first here's like this stack of paper like please fill all these things out like what is this oh this is like who you are all these things like what is your entire processes are you certified against all these things um the neat thing that we figured out is that when we don't manage the service and the majority don't want us even to

manage it like they want that we have zero access, then a lot of the compliance requirements are just like not applicable. Which makes it so much easier for a small startup. Yeah, because you're not even the data processor. Yeah, we have no data access at all. So then you don't have, it's a nice to have like all these certification things, but it doesn't really matter. It's not a no-go.

You're not not compliant. You're not applicable, which is great. So you have a smaller subset of features that you have to be compliant you're not applicable which is great so you have a smaller subset of features that you have to be compliant against and just like focus on those yeah but your go-to-market is also going to be substantially different like today are you mostly doing like founder-led sales in order to get into these these companies yeah it's it is mostly inbound and then founder-led i started taking that yeah so that's basically it. So we have a go-to-market, which has been basically just creating content,

which has created about 50 leads a month. Then we launched the open source, which has skyrocketed to 50 leads a week inbound. And the quality of the leads are all over the place. But you have this inbound constantly of people coming in. And now we're adding, obviously, BDRs and sort of getting that sort of sales promotion. Yeah, they're like, you know, proper sales.

Proper sales. Yeah, exactly. And then, like, with the open source, you know, I mean, I think, like, one of the big values of open source, besides it being potentially, like, a lead generator, is it's great for creating, like, fast feedback cycles so you can, like, if you only have 10 customers, like there's only so much feedback you can get. Whereas open source, you get a lot of feedback, but it can also drown you.

And I guess like, how do you balance sort of like listening to the community investments that you're making to the open source product? What also like, hey, like we're a company and we need to pay the bills. And we have people who are like real clients that are signing checks and balance the bills and we have people who are like real clients that are signing checks and balance the requirements

that they have so I have to say like that has been the launch of the open source and getting that inbound and a bunch of like issues and PRs has been like

a accelerant in the company so Toma one of our engineers which you should have met yeah like the excitement the amount of work

they push out now so they push out two releases a week now on the open source project, product project. And that was, the excitement was basically what you said, the feedback loop, because the feedback, we have a handful of enterprise customers.

And so the other ones that are coming in is like, oh, you have a call, then, you know, you have another call, then you have a demo, then you have a POC. Then by the the time it gets the actual engineer using it like you're talking about like nine months later yeah and then you just get a fraction of the feedback because it goes through multiple hoops to get to you um but when you're in the open like out in the open it's like every day like every day which has actually been for us it's been absolutely great like there has been nothing bad in the sense of detrimental like you guys are off course whatever

like there's things that don't work which is fine bugs but like generally it's been really really positive and energizing for the team and so how do we split time between the two or roadmap so one thing we tried to describe on our readme and our contributing is that this is our roadmap, our roadmap is public, and the roadmap serves the product, which serves the company. Hopefully we created this open source because we think it's a problem,

and you all shouldn't have this problem. I want you, this problem, to be done in the world. You type Daytona Create, that's it, start working. So the way we wrote it is if you want to contribute, here are the things on the roadmap. If you want to contribute like here are the things on the roadmap if you want to take one of those feel free if you want to add something that's not in the roadmap like let us know we'll obviously accept things that are not on a roadmap that don't take us off course so the interesting thing is like we have support for every git provider

like even get t i didn't know that was a thing. They have like 25,000 stars on GitHub right now. So G-I-T-E-A, and we support that now in the open source. That doesn't take away from our main course, and if it's in there, fine, I'm totally okay with that. We have users that want to use that, great. So those types of things, and so we try to be very transparent.

If you want to work on the projects that are like on the roadmap by all means go ahead if you don't want to do those you have some other ideas like let us know but there's also a third option which we're launching we hinted to it we're also launching a plugin system as well so like if you want to build something for you like build it as a plugin so it doesn't take away from right yeah if you need something specific for your company or project or whatever right yeah you can build it so that's how we're thinking about that and then you you mentioned earlier that you did like everything wrong at code anywhere i have like deepest empathy for also i feel like my first company i did everything especially the first year absolutely everything wrong that you can do. All the cliches, we did all those things.

So given that this is like your second time around, like what are there specific lessons that you learned from that experience at Code Anywhere that now from the mistakes that you made that you're not making at Daytona or like some of the, what are some of the things that you've done strategically in the basically year or so since you've really been doing this full time that are different uh a couple of things um one is for sure the first thing i mentioned is actually doing your research and figuring out does it make sense or like are you crazy or not like you know what you're doing is there a market i also learned that from shift is like is there a market for what you're doing so the first shift was actually a startup conference and it lost money for three years

because there was no, in Eastern Europe, there was no one interested in paying for sponsorship or tickets for creating an entrepreneurial conference. I ended up switching it to a dev conference because of Code Anywhere. And then I figured out, oh, there's developers that actually have salaries, not poor founders, which I was one of them,

that can pay tickets. And sponsors want to sponsor this thing. Oh, cool. Okay, I get this now. And then I did multiple events, different cities, different things, and sort of figured that out. Same thing, like, you know, Daytona, I was like, oh, this is the buyer, this is the market, this is their budget.

Like, obviously these things can be wrong, but there's like a thesis behind it. Like, there's some data points that you have. That's the first thing. Other thing, like definitely like people-wise, I'm very much more through the multiple companies that I've had. Like you want to, and we talked about this last night as well.

It's like, you want to hire two more people because you want to move fast because you're like breaking. But also if you don't hire the people that fit or they're not at, they don't have to be necessarily like lower quality, but like the quality or the place that they're coming from doesn't produce high quality in the environment of a startup.

Then that you're basically taking a discount of the stuff that you can get done. But the worst part is as you add more people, then that hurts even more. So you get a lower quality of output in general and so that's something i've been like for sure um tickering with the other thing is very much this sounds like a cliche but adaptability um which i learned because of covid for sure um so when it hit this also started the conference like we were at the largest point ever investing in new conferences. And then the pandemic came and we almost like went bankrupt.

And so we basically, we could have died. A lot of them did die, but we basically pivoted to virtual conferences as did everyone. But we, I don't think we did it first. We did it like two weeks after the pandemic. So basically now also when we're doing, when we're building Daytona, it's like we had a couple of theses. We were first thinking of doing a SaaS, then we figured out, oh, it's only on-prem. Okay, no SaaS, delete that.

There's excess work in the code base that enables us to spin up Daytona as a SaaS right now. It's like, doesn't matter, we're not doing it because of this, okay, we're switching to this. Okay, these are where the customers are, this is what we're doing. Open source, what are we doing? Like we didn't do it until we found that like this helps the market.

This does this. And so not sure how to explain that to someone, but like be very open that you should have a plan, but that plan will probably change. Yeah. And sort of then quickly adapt to that because that can create leaps and bounds of difference than had you stayed on your original trajectory. Yeah. I found from being part of like multiple startups, like that kind of like resilience to change and being okay with like, hey, I just invested like, you know, two quarters in this project that we decided to like throw away because it didn't make sense strategically for whatever reason.

Like that's not a comfortable place for many people to live in but uh so you you need to have a personality match to not only skill match to be successful i think in the startup i think that's the way that is a problem of like people in general like how many times have you heard like i put so much time in this i'm not giving up now it's like maybe you should again sometimes it's hard to know because sometimes the one that pushes through is the one that actually like succeeds but sometimes like this thing doesn't really yeah because you hear so many stories about like you know that company that struggled for eight years and then was big so it's like i think as a founder you're constantly balancing like in my language it's just

on the edge of like breaking through or should i like give up and do something new? And to that point, how did you think through with Code Anywhere? You actually had something that was generating money. You had people that were engaging and using it. And then you had to walk away from that to go do something new that's hopefully bigger. How did you think through that choice? It was really hard. That was really hard. choice it was really it was really hard that was really hard

and it was interesting like one of um a vc i was talking to like uh two three weeks ago like very deep in dev tools um might even be listening he's like he's like explaining like you guys did this and you were just on the cusp of it you were just like you were right there and you didn't get it like just i digress there's a company called replit yeah which is essentially it's worth a billion dollars 10 years later um same so maybe we could have been like if we just add a bit more but also there's something of like um the the pace at what you're doing like our pace wasn't there anymore like yeah you know 10 years in or five six years full time like you didn't have that pace anymore um so we had to pull the trigger in the sense we never killed it, which maybe we could have.

Maybe that would have been a stronger thing, but then Daytona wouldn't have existed. So it's a weird thing. But it's like whatever we do, the way we thought about it is like the growth graph, whatever levers we pulled, it was like a ceiling. We couldn't get. There was nothing to be done.

And it was like, you know, we tried like, you know, promo codes and conferences and reaching out and doing all these different things and, you know, lowering prices and hiring prices and no free and only free and all the, whatever you did, there was like no thing. I have to note for people

listening, killing free like jumped revenue 20% and then it stayed at 20% high so it pushed it up 20% once and stayed there so like there is something to the world when you're not like a high growth VC backed company that you can do non-free

yeah and I also think that sometimes like there's people if something's free they kind of discount it like from a quality perspective sometimes. Like sometimes having like, like, you know, also from an engagement perspective too, like if you pay for it, you're probably more likely to actually like use it. Some investment on there.

Yeah. Right. Yeah. So, and then if you're, you know, running lean, you only really want to be able to pay attention to people who are like paying for it. And that goes back to also like who you're selling to. So like if we knew that the buyer was not the developer, we never would have charged for that.

But since it was, it was the only thing to do. So yeah, anyway, it was a hard choice. But like it was like the obvious one was like there's nothing, whatever we did, there's nothing to do. And so basically at that point, I had got married and I did a three month around the world honeymoon. So yeah, that was, it's like contemplated. In terms of like adjusting your vision, I know you said you talked to analysts and you talked to like people that had done this at Uber and then also customers. Like, did you feel like analysts and people that had done it before were useful sources of advice in terms of like what people will pay for and that sort of stuff?

Or was it really like, hey, we have to go to these end customers, potential purchasers themselves to get that good advice? I think I did. I think the combination of all of them makes more sense because when you talk to analysts, like analysts have ideas which are their own, which they've structured. And sometimes they're right. Sometimes they're wrong. And so what was interesting for me is like, oh, they gave me some, they were the ones that reached out originally

and sort of kicked off interest. Oh, seeing the idea. Yeah, seeing the idea. But when you talk to someone, when you talk to the person, Sylvester at Slack, who runs their internal team, and when he says like,

it's not mandatory in Slack to use our dev environment product but 85 of developers use it every day so then i was like oh okay it's not it's not just that they mandated it so it might be but like developers actually like the thing yeah it's really my choice yeah so like if you have a company that's willing to invest i don't i forgot how big his team is like six ten twelve people, 12 people, full time, to build and manage this thing. And 80% of your, that's not a small investment. Like what's the average salary of a developer

in San Francisco? Probably 200K plus. Yeah, so you're talking like one to two million a year, at least every single year to pay for that, and 85% of your developers are using it. So I say, okay, this is somewhere where I feel we can fit in. Yeah, makes sense.

All right, well, as we start to wrap up, we have some quick fire questions for you. So, all right, first one, if you could master one skill that you don't have right now, what would it be? Master one skill, flying. Like an airplane. Okay.

Yeah, I mean, to be able to actually fly. That's not what like to find out. I like to find out. What wastes the most time in your day? What wastes the most? Emails, meetings, and my OCD to have an inbox zero, which is a very hard thing for me in the sense of trying to figure, oh, this is the thing I have to do today versus, oh, here are all things and so i waste a lot of time on that like clearing your inbox and if you could invest in one company that's not your own company what would it be one company that's not

my like what's that give me some constraints to that well i would say no public companies because like you can't invest in it but like say like a private company that you're like pretty bullish on yeah i mean i mean this sounds like if i had to like risk my money like the the simplest one would be say like i'd invest in open ai right now it just seems like silly that they're not going to expedite their value in the next couple of years so um that seems like an easy one yeah yeah what tool or technology could you not move without tool or technology superhuman the email client oh yeah which gets to my first which person influenced you the most in your career which person which person influenced you the most in your career there's been a lot

of people that have influenced me in my career uh the most probably, he really recently passed away. He was my first sort of boss at the first job. The only job outside of employee that I actually had. So owner of a bunch of companies and basically taught, like the way he thought about business

was very much led me into entrepreneurship. And then five years from now, are we going to have more people writing code day to day or less? I feel that historically, everything that we've done actually ends up bringing more work. And so I read an article once

and it even isn't true. So I read an article once that the only job ever that was displaced completely by technology was, do you know what article once that the only job ever that was displaced completely by technology was, do you know what it is? The only job ever. I wasn't going to say completely, but like farming, you know, it's obviously gone down like a huge amount. Yeah. But just still technically. So you know what it was in the article? So I can't remember what it was, was elevator drivers or the people, but elevator. But that's not true.

I was at a dinner party in New York the other day and there's like a person. First in the elevator. Elevator manager, whatever it's called. Yeah, if you take the Muni in San Francisco and you take the elevator, I was telling Alex this recently, I discovered this because if I go with my kids

and then I have a stroller and I take an elevator and there's someone in there that logs all of it and they press the button for you and stuff. And I think part of it's like to make sure people aren't doing anything, you know, drugs or alcohol. I mean, there's different reasons, but I don't, and I also was in, I don't know, um, in Dubai or Abu Dhabi where it was, and there was people in like shopping mall elevators, but that's sort of to show off in that sense. But I mean, even that job is not done. I'm not, I digress a bit,

but I found that most jobs that technology displaces, there's just like so many more jobs. Yeah, new jobs. And so even with like software development where we are, and this is like AI generating the code, I still think, I think that's where we sort of play a part as well, is like you're going to have AI creating a bunch of code agents creating a run for code

But you're also gonna have to look at that you know Make sure that code makes sense sort of commit a comment on that or edit it or change it or send it back and you Have to be able to run that as well And I think there's gonna be a lot more things Generated because now imagine that every single person can now start writing code in the sense of like oh I want to do this product or project can you go out and sort of build this thing for me so I think there's gonna be more people in general more higher skilled people that are doing that and that's also another thing too

the way the market is going for anything for like restaurants or laptops or food is that you're going to have people on the one hand, which you're going to have a lot of automation and be lower price, more accessible. But then you're going to have the artisans on the other side. So highly skilled people like best chef of the world, you're still going to have awesome software engineers that can do things that other people don't. Like that's my general take on things. yeah yeah makes sense well all right thanks so much for joining us this was really fun always a pleasure thank you