Episode 9
· 01:09:23
Nitay Joffe (00:01.846)
Ivan thanks for joining us here today on the pod here with Kostas It's great to have you. Why don't we start with just give us kind of just some brief background and your experience.
Ivan (Daytona) (00:07.153)
Great to be here.
Ivan (Daytona) (00:13.521)
So many things. My name is Ivan, co-founder and CEO of company called Daytona, which is an infrastructure tool for automating dev environments. Before that, I founded a developer conference called Shift, which is still going pretty strong. There's that one in Croatia, one in Miami. About 4,000 people in person come. It's vertical agnostic.
Before that, did a company called Code Anywhere. Before that, I did a bunch of other stuff. And so as you can tell by timeline, I'm fairly old as well in the entire startup dev tool ecosystem. Commute between Croatia and New York every single month. And so yeah, that's me.
Nitay Joffe (00:57.448)
You sound like a very busy person. So let's go back maybe to the beginnings of the code anywhere in Shift. Tell us a bit about kind of what led to the starting of that, what did the world look like back then, and what did you guys create?
Ivan (Daytona) (01:09.477)
It was such a long time ago. we founded code anywhere in 2009. And so you all here on this podcast actually might remember that time. And so this is pre web 2.0. Like that thing, that stuff didn't exist. Right. And so we were, my co-founder then friend and he was my friend and he was working for a client of a company that I owned at that time. Was showing me this white screen in the browser on the left-hand side. was like an FTP connector on the right-hand side. was like a notepad.
And I'm like, holy shit, this is awesome. Because at that time, know, Google acquired rightly, everything was going to the cloud or the browser. And I'm like, you know, coding is the last thing that this has to happen, you know, 15 years later, still hasn't happened, or it's happening now. So we were way ahead of that. And so we did that as a hobby, because we couldn't do a lot of things in the browser, we were actually thinking of using
Flash and ActionScript for the people that remember this and we were actually building like syntax highlighting in that. Luckily we didn't get very far because know Web 2.0, all Ajax, all these things came out. We can do all these things in the browser and we basically with CodeAnywhere created like four versions of our own whole ID because to create an ID experience in the browser, we had to build everything like nothing existed. There was nothing off the shelf. So the orchestrations, the container, the containers, we use some
I forgot some open source project was just not Docker way back when the IDEs like there was no LSP. was like nothing, nothing existed. We had to build everything from scratch. So we learned a lot of things with Code Anywhere way, way, way back. And we were super early. think two and a half million people signed up to it, signed up to it at some point. So it wasn't complete failure. It's interesting that people still know about it and some people still have used that. And so that was my beginning in sort of startup Elan.
Nitay Joffe (03:02.348)
And give us a sense, we love hearing kind of the roots of things here. So that's really awesome to hear. Give us a sense of like, even just a simple question of like, why code ID in the browser? Why should people want that?
Ivan (Daytona) (03:14.301)
I mean, things have changed back then. Like, we had a more naivete look at things, when we were building it way back when. And I think that's one of the reasons why it ended up become so successful because back then it was just because we wanted things easier. As a reminder, like this isn't probably video, but laptops then were like this thick. It was like, it was like really big. and yeah, like huge battery packs and it was like a pain in the ass to carry these things around. And so like,
wouldn't it be cool if you could just log into any computer and just continue working? And so we thought of it in the same way as email, like it was super easy to do. But back then, like people did use text editors and sense of sublime text or ultra edit or texts. What was it called? Plus plus. I forgot what it was called. Anyway, they did, but a vast majority of developers still use things like Eclipse and Visual Studio and all these like actual IDs.
And the reason they were actual, I call actual IDEs is because they were actually integrated development environments. Like everything was in these things. You actually open it up, you typed code and you hit run and the thing worked if the code worked. Right. and that was how things worked back then was much simpler. Now fast forward today, like we all, we all, again, not everyone, the vast majority of people use text editors. The vast majority of people use VS code because the dev environments that we have now with like
multi-service architecture and all these things, you have to go as a developer and figure all this stuff out, install all these dependencies and make things work, which is a vastly more complicated thing to do now than it was way back then. And so today having automation around the dev environment and essentially giving developers that experience that we had 15 years ago, where it's like, hit a button. The dev environment is up and running and you type code and it works if the code works.
That is something that is an actual pain point for very, very large, especially very large enterprises. Now that wasn't back then. So back then we had the idea as like, this is going to be cool and super easy to use. And then developers will buy this. mentioned this before, you don't sell to developers. Like even a developer tool does not sell to developers. And so who are we selling to now with Daytona? You're selling to engineering managers, CISOs, CTOs, which have different requirements, be it...
Ivan (Daytona) (05:30.301)
developer productivity, be it security, be it compliance, whatever those things are. And those things have budget and people are willing to pay for these things while making life better for a developer.
Kostas (05:41.516)
Yeah, that makes a lot of sense. But before we get deeper into what you are doing today with Daytona, I want to ask you about, you mentioned like the term dev environment, right? And what is the dev environment? Because it sounds very obvious. But as you were talking about it, and especially as I was reflecting how these things have changed, because you mentioned some names that...
probably triggering PTSD in me because I'm also old. Yeah, like Eclipse. What was the other one? NetBeans or something else? was like, yeah, yeah. Or trying to build UIs in Java with Swing and anyway, let's not trigger more PTSD here. Yeah, yeah. But how the development environment has changed in these 10 years, right? Since Code Anywhere.
Ivan (Daytona) (06:12.167)
Sure, for sure, for sure, yeah.
Ivan (Daytona) (06:19.067)
Net beans was there, there was net beans, I remember them, yeah.
Ivan (Daytona) (06:29.09)
Go
Ivan (Daytona) (06:39.825)
I think a lot. it's also like the definition of what is the development environment. Even the wording is weird. And so I have this argument with the team inside of Daytona as well, where like the debt, we're like a dev environment manager. That's like what we are. But like when you spin up the Daytona, it spins up a workspace. It's like, what is this now? Like, what is this new label that's there? And there's different labels. And we did a bunch of research in companies and some people call them dev boxes. Some people call them sandboxes, people call dev environments, some people call it workspace, some people call them different.
things, essentially what we define as a dev environment sometimes is one machine, sometimes it's multiple machines, but it is, and sometimes it's not even, it's like connected to a service that's on AWS because you have to connect to that to get the whole thing up and running. it is a bunch of, it is either one or multiple.
things that you need to be able to run the code which you are developing on. I haven't thought about this definition very well, but you're good to put it out and we should put it out there because, that's the trickiest part when creating such a product that we're doing right now is when it's a simple, so it's like when it's a mono repo and basically you need to spin up like a Docker container, just one, if you want, or you're running a Linux, you can do it like natively on your machine. Cause the vast majority of people now, if you're not doing mobile apps, you're running it on some sort of Linux container anyway. If it's, it's just like,
check out a repo, install whatever dependencies you get up and running, it is fairly easy. And that is a lot of dev environments are basically that. But if you're looking to who is using versus who is buying, which you said earlier, the people that are buying are gonna, they're the ones that have a bigger issue. And their bigger issue means that these in dev environments are complicated AF. Like they are very, very, very complicated. I was talking to one customer two, three days ago.
And, or say potential customer. And they're like, for the, for the monorebo ones, this is easy. Like this works. It's fine. But we have this super complicated, like long read me, it takes developers two weeks to get up and running. They have to spin up five different containers on their local machine. Then they have to spin up these services on AWS. Before that, they have to ask the DevOps people to give them access. They have to connect this stuff. Then we have this little proxy they have to install to connect it all together. So the, so all the routing works and then they can actually start working. And so.
Ivan (Daytona) (09:05.433)
What is a dev environment today? It's whatever services or service you need to actually run the code you're creating at that moment. I think that is the definition we could use.
Nitay Joffe (09:16.282)
And what's the, just going off of that, what's the kind of best practices that you see to your point about monorepo kind of, you know, microservices and so on. lot of people are using like, you know, kind of telepresence and those kinds of things where some containers are here, some containers are in the cloud and it's quote unquote seamless. Obviously there's all these networking issues. Like, so what, what, what is like, what works, what doesn't like, what have you seen?
Ivan (Daytona) (09:29.222)
Yeah.
Ivan (Daytona) (09:35.933)
I've heard, I've seen so many and it's actually surprised me how many different variations there are of them. And one of the things that we are hoping to solve with Daytona is basically create sort of standardization around quasi standardization around how these things work. So that basically it'll fit into three different like pillars of setting things up. So it will either be, you know, some sort of Helm or know, Kubernetes, which we'll use to be able to do these things or
You will use a sort of Terraform type thing where you will define everything you need in there. And that will work inside of our project system and it'll make it seamless to the developer. Because what we found is so many different ways of work. And so the ways of work that are right now is either, I have to think about this, but either you as a developer run everything in a local machine. So you have like, you can have multiple services. They're all running a local machine and you very quickly come into constraints there, especially if you're in a bigger system or there's just some things that
or it cannot run your machine. Then you have ones and that's developer owns the whole thing. It runs on the machine. Then you have the developer owns the whole thing, but some of them run on their machine and some of them run remotely. So you can think of some services are running on your local machine and some of them are running on AWS, for example. But, but it is a complete replica for every single developer. Then you have the option where developer owns everything, but everything's remote. Right. So like all the services are on AWS and that's completely it. Then you have versions where.
the developer has something running locally and they have shared versions, shared services running remotely. So you can think of, have three services running, you have three services. and on AWS we have like the shared services, like the database or whatever, and that has its own problems. And then it, then there is, and that's, I think the last variation of them that I went through. Anyway, so that is what people are trying to do. And there's different constraints or issues with different ones. So if,
You are the developer running everything and something's remote, something's local. Networking issues, always a problem getting it up. If it's all remote, less networking issues, but it costs more. So imagine you have like 500, a thousand, 5,000 developers and they're all running, you know, all these services on AWS all day long. Like that is a pretty big bill to pay. But it's sort of the best version that you can get for the developer. Whereas if there is like a shared version of these things,
Ivan (Daytona) (12:03.547)
sorry. The shared was something local shared remote, all the ones that work on a remote and shared is also remote. And what the shared does, it lowers costs because we have like whatever services we have, it's all spinned up once. And we all sort of share against those, but networking issues are the largest there because we all have to connect to those. And there's different versioning issues because there's only one version or two or whatever running. It is not for every single person that I'm doing.
So we found that these are the variations in where people are working and the vast majority of them that we've talked to, they're not using something off the shelf. The vast majority are trying to figure things out. when they're using teleperson, something reducing something else, something I've created their own things. And it's very unique to every company that we've been talking to, but it seems that that's the overlay, right? And so what we're trying to get to is a place is like, we, as a company can give you.
These are the three versions that we're going to give you, not all five. This is how you can configure it. We also have all this observability and compliance and management of what people can do, but you have to fit in these things. And I think it'll fit in like 80 % if you at the distribution curve of companies doing this. And so that is sort of our hope in that sort of direction where we're going to. And sorry, I talked about Daytona more than your problem. So I apologize, but that the whole prism of the problem, I try to look through how do we solve that?
Kostas (13:27.02)
Yeah, so you mentioned the difference between the buyer and the user, which is great. And I think we got at least some indication of why the buyer cares about something like Daytona. And you mentioned the difference, let's say, archetypes of deployments there and so let's say development environments. But I want to ask you, what's the user
from all these different ways that the projects, let's say, can be structured, right? Each one with their pros and cons. One is, let's say, turns your laptop into something that can fry an egg. The other is you get connectivity issues because networking was hard, is hard, will always be hard. But from the user perspective, it's what you've seen. What's, let's say, the
Ivan (Daytona) (14:10.045)
Mm-hmm.
Kostas (14:25.986)
best as developer experience. What is the more delightful experience at the end of the day for the user and what the user is looking for, right? Again, they are not buying, but still they have to love your product, right? Otherwise they will just like complaining all the time. So yeah.
Ivan (Daytona) (14:40.453)
Yeah, that'll be complaining. Yeah, I'm going to just caveat into that, into the issue beforehand. so, so when we created Code Anywhere, back in the day, and even when it was like going in the right direction, we assumed that the buyer was the user. Like we assumed the buyer was a developer. So it was like a very much a single, there's teams obviously, but it's like a single user comes, swipes their credit card, uses it. And so we thought, okay, just like the buyer would be the user and that's
who you look to. And that's very specific to developer tools and even the sector in the sense of like from an investment perspective, like there was nothing called DevTools back then. I think it sort of happened after Microsoft acquired GitHub and like, know, 7 billion. It's like, okay, this is a thing. Like we can have a thesis around investing. don't need to, I can ask you about that more than the rest of us here, but I think that's when sort of DevTools became, I think. And so we were just trying to figure it out without like genuine PLG like.
whatever service, you know, think about it like Slack, Miro or whatever it was like a single person will use it, swipe their credit card at five bucks a month. And then, you know, it sort of scales. And so with developer tooling, it's kind of different where you're trying to get developer love. that what's your point is like when the top down motion comes, like we want to implement implement this, the developers don't hate it and boycott it, but they actually like it. And so
I feel that with developer tools, you're trying to do two things at once. You're trying to get buy-in from the developer and get them to use that as a thing to make their lives easier. But then separately, you're trying to convince the buyer, which is CTOs, know, VP of engineering, DevOps engineering, whatever it is to say, Hey, this solves your set of problems and you're going to pay for this while you're solving these sets of problems for developers. And you're going to get this.
for like, you're not paying for it either way, right? And so we're doing that. And so we did not know that with code anywhere. And that's probably why it wasn't among other things, super successful. And when we were trying to do this company, it was like, how do we distill who is a user, who is a buyer, what is the value for the user and what is the value for the buyer? And if you don't know those two things, I think it's going to be very, very hard to become a successful company long-term. And I think this is, we can touch on this. let me know is like where the
Ivan (Daytona) (17:03.293)
You know, I say NaviTig and for like open source founders where the vast majority of open source founders are probably not founders to begin with. They're like trying to solve a problem. this is a cool thing. And they get a bunch of traction on GitHub and then like investors come, Hey, do you want like 1 million, two for whatever it is? And it's like, sure. Yeah. Like they didn't understand the license. They didn't know what they're doing. They're not trying to, they don't know how to sell it. And they think that just because people are using it, you know, build it and they will come. And that is
cannot be further from the truth for developers, I think. That's what I found.
Kostas (17:36.1)
100%, I totally agree with that, like from my experience too. But how do you, I mean, and this is a question that's a little bit more relevant to founders, I would say, but how do you build this dual motion? Kind of reminds me a little bit in the way of, you know, like marketplaces where you have demanded supply and you have to build both, but they are different, right?
Ivan (Daytona) (17:59.004)
Yeah.
Kostas (18:00.268)
It's not the same per se, but you do have two sides there and you have to satisfy both. can't just go and say, you can do many things, but probably aren't going to be optimal or like your chance of success are not going to be that high. But ideally you want to balance these two, right? And when you start first, you as a person, you probably, you come from one or the other, right? You gave a great example of,
engineering first-time founders that they get the GitHub stars and then they're like, and now what? mean, what's there? What's next? But even if you are a second time founder, balancing these with the very little resources that you have, it's hard, right? So how do you do that? And how do you balance making sure that both the buyer and the user at the end of the day are going to be aligned?
Ivan (Daytona) (18:54.909)
mean, as you said, it's really hard. think everyone has to figure it out themselves. And it's also hard internally. mean, we're not a large company by any means. Like we're 12 people in the company. Might be 13 now. even internally, the engineering team is seven people. And we sort of split it up into who's working more on the open source and who's on the enterprise side. You'll even hear arguments internally from the enterprise. Like, why are we doing this open source?
revenue there, there's no like whatever, like you'll get these things internally that are very far from like, you know, fighting whatever, but you know, people are like, why are we spending resources on this? We have so little resources. Why aren't we doing this? And so it's not only an external battle, it's an internal battle to like do this. And you as a founder, I believe have to have the sort of vision to say, this is what we're doing. And this is how these things sort of come together. Whereas most people
on your team won't have that. And then you have to like constantly believe in yourself. And then when things happen that are successful, you have to actually, you know, take a moment and tell people like, or it fails, like we did this and this is why we did it. Cause this is now very successful, right? And this is why we did these things. An example for us would be like open source is bringing in a bunch of people, but no one is like calling us or no one's like selling it or no one's interested in buying.
But what had happened for us was we didn't have a way to show people using the open source that there is an enterprise, which we found out later, which is a great problem to have. We found out that very, very large companies by accident, I talked to them for some other reason, they're like, yeah, we tried your thing. We love it. But just because you guys don't have enterprise features because the last six months have been focused only on open source. Like the entire web, everything's open source. There's no enterprise thing on it right now. And I'm like, yeah, we actually do.
here's the documentation for it, here's this, and they're like, shit, well let's try this out. So what that meant for me, and when I showed it to the team on our like weeklies and monthly, it's like, look, people are using it, they like it, but we didn't message here's how you onboard to the enterprise thing, right? So that is a, I think, good problem to have, rather that it's better than, you know, people just don't care. And they're like, okay, great, that makes sense, and now everyone's of onboard internally. But also to your questions, like how do you do these two things?
Ivan (Daytona) (21:17.725)
What we decided to do at one point is we had, started with enterprise, added open source afterwards, after we figured out what we could actually open source without pulling back the license 10 years later, or at least that's what we now believe that we can do. And so we've also found that we have, you know, we have a handful or two handfuls of customers, but like very large customers, we'd often get into sort of blockades because we're missing, you know, ESO 27,001 or SOC 2 or some like...
reporting or something not developer experience. Like the product's there, it works. But some of these things, which I call compliance or security regulatory. And then we said, okay, great. Let's focus outwardly on open source the next half year. Get this really successful, get it people's hands. In the meantime, we in the backend, sort of like we solve the enterprise and then we launched the enterprise out publicly. so that's how we are currently doing it. And that's coming to the end where
Because it's very hard even to message the world, like we do all these things, right? We do this and this and this. like, what are you doing now? We're doing this. And then when we get to that point, we will, okay, this is what Daytona does. And this is what we can sort of add on top of that. And so it's also narrative. It's engineering product, narrative, go to market, all those things. And sort of how do you align that to do quote unquote at the same time, because you can't actually do everything at the same time, I think, or at least not well.
Nitay Joffe (22:40.782)
And it's really interesting the point you made there about where kind of second time around you actually started from the enterprise side and then kind of added the open source. You know, one of the things I've seen with a lot of companies is people say, when open source company in reality, there's that means a spectrum of things, right? On one end of the end of the spectrum, you have a company where it's like, here's the code, it's on GitHub, do whatever you want. We're open source friendly, but we don't really care about the community. We don't give a shit. We're just doing it to show we're open source friendly. And on the complete other end of the spectrum, you have like, you know,
deep Apache projects and community building and like, you know, lot of your experience, like starting the shift conference, right? That kind of thing. And so given that you've seen kind of, I'm sure a lot of that spectrum where with, with, with they tell none when where like, as you go into it thinking and from what you've said, coming from that enterprise sales side, how do you think about like what level of open source for IDE, you know, in the browser kind of things, what level of open source is the right one and why.
Ivan (Daytona) (23:35.549)
So I can talk a lot about open source. Like we did a lot of research. So as to your point, we started as an enterprise product, right? And so our product, like the browser ID is like not even important now. It's basically the infrastructure underneath the automation. But we like, we said, okay, like we're building a business. The buyer is like, these are the enterprise. These are what we got inbound and we're selling to them. And that's how we started open source, sorry, enterprise first. But you quickly come to the conclusion that selling to...
large enterprises outside of like the regulatory and compliance things that you have to have in there. It is also a much longer sales cycle and it's also much longer because no one knows who you are and you have competitors that have been out there for like five, six, seven years, right? You are the new kid on the block. You are really young. Like the company is like 15 months old. So like we're very, very, very, very young. And especially in like, we're talking like Department of Defense, big bank conversations, like we're like,
They have business, they have like yearly plans that have been around longer than we have. Right. And so when we got to that, sometimes you're like, okay. How do we get the awareness around Daytona so that people actually know what it is in a cost efficient way, you're a small startup. Right. And so we're thinking about open source for a while. It's like, maybe that helps. Also, we were, we were warned by a lot of people and some of them are angel investors. It's like,
doing open source and enterprise, like these are two different products, is like getting lightning to strike twice. It is very hard. Like be very careful of what you're doing. And so we thought about it for a long time. We looked at like all the licenses, we read through all the licenses. It took us like nine months, not full time, obviously, but nine months since we decided to do it to figure it out. How do we open source this thing? And so the way we thought about it was one from a value proposition of the
buyer you have the persona that's going to use it. And the other was from the legality aspect of how you're. So like first is what are you open sourcing? The second is how are you open sourcing? What you're open sourcing? I mean, by a lot of companies will open source the whole thing is like, this is our product. Here it is. And then you put a license on it, right? When we were thinking about it, who do we serve? Like the whole product of Daytona has, I basically built it up into
Ivan (Daytona) (25:57.883)
It has value for three personas for the developer, for the DevOps and for the sec ops, basically. can call them those three, right? And so open sourcing, the whole thing will not help the community. It will be actually a pain in the ass for most of the people, because if the community is the single developer, that is the user, that is the person who's not going to pay, but that person still has an issue with setting up dev environments. Can we carve out that value for the developer?
And give that as open source. And it took us a while to figure it out. And we, when we figured it out, okay, we can, we can put a sharp line, like a line in the sand where anything that is not for value for the DevOps person or the sec ops person that is not in the open source. Right. And we created this little, very simple. You know, project, which is a small repository. It's it's easy to set up and it's easy to contribute because it's really, really small and
With that, we decided to do, I don't know how many people decided, we actually decided to split it into two repositories. That was also your question earlier that I sort of forgot to answer. And so we were a mono repo and now we are actually like two mono repos. It's like, that is what Daytona enterprise is. You have the repository of the open source, the repository of the enterprise features, and then they come into one product to be the enterprise product later on. It is a bit more complicated for us inside the company, but what you've gotten
is that we were able to open source in quote unquote true open source license that project. So it's Apache 2.0, like legit open, like no one can say that it's not open source. Like anything else outside of MIT, there's always discussions. And I've been to a couple of these open source events. I don't know if you have with founders and people are like, you're open core. You're Apache, you're AGPL. Like there's like people don't like these things, but like for Apache 2.0, it's like,
double thumbs up, really great. You get more love around that. what we ended up to the long answer is we carved out what gave value to the person that needs it and will never pay for it. And then we created that as pure open source, which then helps you get contributors, get love around it, build a community around it, actually solve people's problems. And hopefully they are your evangelists when you end up selling the enterprise stuff, which they don't care about.
Ivan (Daytona) (28:23.261)
Anyway, right? And so this seems, think, super like straightforward when I talk about this now, but like that was really hard for us to figure out. And the more open source founders I talk to, I see that the vast majority also, and this is not a one size fits all, like different types of companies have different ways and probably can't, all of them can't do that. But that is how we found it the most optimal way that we don't have to call back the license 10 years down the road because all the quote unquote paid for value is built on top of that.
And we have where we hit 10,000 stars yesterday or day before, and we launched this in March. So it's like, we've surpassed almost every single competitor. The one we haven't will be next month. That'd been around for like more than half a decade in like nine months. So because of all these things that we did, we believe that these things help the consumption of the community and engagement of them.
Kostas (29:18.02)
That's amazing. okay, the user, which is a developer finds the open source project, right?
What are they looking for and they find that project? The reason I'm asking is because it's very, it's kind of obvious that, okay, like if you're a developer, you definitely need an ID. So you're going to look for somewhere to write your code or you read the compiler or you need some link there, like that kind of stuff, right? But the environment is a little bit more abstract. So what are these people looking?
Ivan (Daytona) (29:54.65)
It is.
Kostas (29:57.57)
And they end up finding Daytona at the end of the day. How these things are connected. And I have a follow-up question because I think one of the really hard parts of doing these open source
Kostas (30:19.022)
play with something that delivers a lot of value to the user, but at the same time, give space for you as the vendor to monetize when go to the business, is that many times what the developer has to do and what they are looking for is very tightly related to what they're doing at their work, right? Not everything can be like a hobby project, for example, which is something that GitHub built upon many of the...
Ivan (Daytona) (30:40.455)
Sure.
Kostas (30:48.008)
a new, this new breed of databases as a service serverless like databases do is sure here spin up something like for your hobby project, right? So how, actually not how, but tell us exactly like about Daytona, like what's, how it works, why people find it and how it's so clear that they can do it for things that they don't need approval from someone at work, right? Like to go and use it.
Ivan (Daytona) (31:17.917)
Sure. So maybe more explanation actually makes things easier to understand. so we also didn't, again, we didn't understand how to make that cut for a long time. And so now that we did, seems obvious, but back then it wasn't. And so what does Daytona do as an open source project? And so someone joked about that it's a wraparound Docker. Like that was the joke, right? And so it does what Docker was supposed to do in the context of dev environment, not in the context of production, right? So.
What Daytona does is it's a CLI tool. You basically type Daytona create and you point to a repository, any repository. And what Daytona will do is the following. It will, and so also it can create different environments locally and remotely. So it can connect to an EC2 or a digital ocean or on your local machine, whatever. And so we hit Daytona create, depending on where you pointed it to run, it will either just spin up a Docker container on your machine or it will spin up an EC2 instance somewhere or droplet, right?
After that is done, it will check out the repository. It will check if there's a infrastructure as code configuration. So if there's like a dev container, a Docker file, Nix, whatever, it will then create, there's a builder that will build that entire dev environment against that configuration. Then it will connect to your IDE. Like even if it's remotely or local, it always works the same. So it can connect, you know, VS code, any of the JetBrains, cursor, ZED, like it connects to all of these.
it will, you know, exchange us as a cheese with these, even if it's remote or local, like you don't have to do anything. It just opens it up. It opens up the read me it execute. Everything's built right, right away. And it sort of just like works out of the box. It also has a reverse proxy in that, which means there's a preview environment. You're which means your dev environments, your preview environment. Essentially there was a meme. don't know if you guys seen it when my cursor came out where someone's like, like
there's like an SMS, they're like in messenger memings like, created this, Kirstj was awesome. I created this thing and the guy and the person says, show me. they send like, HTTP 127 001. Like here you go, like look at it. And then like you can't preview, like the person doesn't understand it's not a developer, right? And so what Daytona does is like, it actually gives you a preview URL, even if it's running your local host or if it's running somewhere else. So you get all of that right out of the box. So it's like a SaaS like code spaces like experience.
Ivan (Daytona) (33:43.709)
but it runs on your machine or your EC2 or whatever it is. So it just takes care of all that automation. So that's like seven things, right? And that's what the open source product does. And we're adding more providers who can connect to other hosting and whatnot. There's things, nuances in there to make your life even easier. But it's basically those handful of things. And I wrote an article about this on the Daytona website.
Like if you're not an experienced developer, it'll take you like 45 minutes to get this up and running, right? You're need to do this, to get your SH keys, you're gonna spin it. If you want a preview environment, you're gonna use ngrok or whatever. Like it takes a bit of time. Like if you're really good, it'll take you 10 minutes, but this is done in like 45 seconds. It's like done. It just works. And so we gave that out for free and that is what we gave to the open source, right? How do people find that? That is actually a tricky question because how do you define that?
If I tell you like the dev environment manager, you're also like, what the hell is this? Like, what does that do? Like, I have a dev environment that's for itself. So there's a lot of ways that I've learned through previous companies of how to create awareness around the product. And then when people find this, like, okay, let me try it. Okay, this now makes sense. But we are also trying to get the wording out there because as you said earlier, what is a dev environment? That is a very abstract thing, right? So that is what we do in the sense of the
open source. And so I believe your question was like, how do we, why do people find it? And then what is the value afterwards? And so, well, as I mentioned, the, the values for the developers, that's for the developer and how did they bring in the company? So they can bring this in the company because no one really cares, but because it's basically doing what the human would do is just automating all these things. So it's not installed. It's client, the open source is client only. it's on your machine.
And then it will go out. So if you're working in your company, you can connect your Bitbucket on-prem, but it's essentially going from your laptop to theirs. It's not going through Daytona servers. There's no login, there's no nothing. So there's no one to say you can or you can't. And if you're even working, so if you're working at a company that they give you, know, EC2 instances or whatever, your DevOps person will give you, know, your, your keys or whatever it is. And then you just add them in Daytona and it spins it up for you. So it just automates those things. And so in that sense,
Ivan (Daytona) (36:02.489)
No one really cares in the sense of like security and nothing is leaked to Daytona anyway. There's telemetry, but you can turn that off. It's very transparent. It's it's true. turn it on. We have telemetry on. If you want to turn it off, here's the button. And so a lot of people turn it off as well. And so it doesn't, because of that, it makes the developer's job easier, faster, better, whatever, but they still have to bug the DevOps people for their AWS. They still have to bug them for all the keys for anything. They still have.
security team cannot run audits or any logging on the Docker container running on their machine. Like none of that stuff is there. And so what the enterprise does is it's actually a very, very different product in that sense. The developer feels the same, but it's mostly the dev environment management is that if it's the enterprise product, the DevOps team doesn't have to do anything on create.
Daytona is the DevOps. It will go and spin up an EC2 or create a pod or make sure it turns off and make sure turns on. And it will do that all inside of the compliance constraints that the security team and DevOps team put there. So it takes away work from them. Not sure if that makes sense.
Nitay Joffe (37:15.694)
That makes a lot of sense. was going to tie this to, you said something interesting early on that like, you know, back in the code anywhere days, the technology wasn't there, the kind of the market wasn't necessarily there yet. And it sounds like now both the technology has come a long way and, know, obviously since the days of flash and so forth. And you guys have figured out a lot in terms of like kind of the open source enterprise hybrid and so forth. And so I'm interested in like,
What is it that you're seeing now in the latest trends that is either, and this ties to kind of your, exactly what you just said about like you're exploring that go to market and like, what do you even call this thing? How do people think about it? Is there like this trend shift that you see to doing more of this like collaborative coding, if you will, or collaborative kind of IDE? And then how do other things like, obviously there's, you know, now AI and LLMs kind of, you know.
stepping their way into every single aspect of things. So what is the trends that you now see today that is kind of today's version of what you know, you'd stop back then for Coto anywhere, but now it's completely different.
Ivan (Daytona) (38:21.777)
Well, I think one of the things that's happening is that more and more developers are actually working remotely, which then, and which adds all these complexities where you're looking for a solution. Because if you're working with local hosts and doing some front end app, like you don't really care. It's fairly straightforward. It's like super easy, whatever. But now like, because you're trying to do something with AI, the vast majority of people need much bigger machines than they have. like, as soon as you need bigger machines,
Like you have all these startups now offering these sort of like layers on top of AWS specifically for AI. and you have to connect to these things and now you have to connect. There's like a whole layer of complexities. Like there's networking, there is like, does my AD connect? How does my linter work? Like how does my debugging work? How does all these things work? Where are they located? What's the addresses and blah, blah, blah. And so with this, we're seeing more and more people developing off their machines. think the last that I read.
was that 49 or 51 % of developers in 2023 have worked remotely. So that doesn't mean like a CD, the dev environment manager type thing. could be just like a remote server somewhere they connected to, but like half the people worked remotely in, at some point, it doesn't have to be the whole year, at some point last year. That is like way more than you would expect when just like, like, cause when you ask the developer where they work, it's like local host, that's it.
but it's actually true that like half of them work. And I think that's numbers gonna only go up because of what the compute constraints we need. Even if we have, you know, M4 chips, we're gonna need more. The second thing with AI that's actually very interesting, I wrote an article about this the other day, is that because of, there's a couple of things here. One is that if you believe that the world is going to AI assisted or AI,
Autonomous coding this is where I get super interesting in the sense of orchestrating multiple dev environments Why well if you look at like cursor which is doing a fairly good job people like cursor like you could have your own opinions of it But what cursor does it's actually very interesting is they wrote a blog post about this is they actually have an invisible? Window an electron window, which is actually has access to your code like the files in your in your repo
Ivan (Daytona) (40:44.943)
And as you're typing, the AI is trying to figure out what to serve you. Like they're trying to figure out what works, what doesn't work, whatever. And then it serves you whatever it thinks works after that. Right. And that's what you get, but you don't see that that's happening in the background. Right. And so that is only level one. And I don't think we're going to get to a place where that code is actually really, really helpful. Unless the AI, instead of just having files, they can have the entire runtime.
So imagine the AI has the entire dev environment, replica of what you have, and it's spinning out variations of this thing. It can give you much higher quality results and spin that back to you, or it can be completely autonomous and do that on its own. If you look at the autonomous ones like dev and AI and whatnot, they all have their own dev environment fully automated for these things. But where it gets really interesting is if you have a time constraint,
but you don't have a financial or you do have a limited financial constraint. And this is actually very important for like venture backed companies. What if you could ask the AI to start spinning up these dev environments and when it has variations, it spins up replicas of more of these, essentially parallel universes, spinning them up and it'll spin them down after he gets the ones that don't work out to get to the best solution and then sends you back the best solution. Like you don't have to wait, just the way it works right now with even the fully automated ones, they have one development environment like a human. And if they screw something up,
They have to roll back internally and fix it and whatever. And that's like a whole different problem. But if they can create multiple for every variation that they want and just kill off the old ones, or if they screw up, they kill off the old ones. If you do that really quickly and automated, you essentially have a very, very large need for a standard and simple orchestrated dev environment management sort of solution that the, that AI will use even more than humans will use.
but in a sense that they have the same environment so that when you run that code, you have the same environment as the agent and vice versa to you. And so that's sort of where I see this whole place or way of dev environments being pushed in the future with AI coding.
Nitay Joffe (42:56.194)
And you mentioned this now, you mentioned a couple of times before as well, this kind of notion of many variations, multi-versioning, et cetera. It seems like there's kind of like some magic moment there. us a bit more about like what's the heart problem there?
Ivan (Daytona) (43:08.477)
So there's a lot of hard, speed is a big problem. So I was like, how do you like create a snapshot of A and then it can spin out two versions of that or one version is like, I'm gonna go off and do this thing. But what if we do this other thing? Like can we just snapshot that really quickly and spin that up really quickly so that I can start doing the AI, can start doing another variation of that. I think the snapshotting and spinning up.
at speeds, so you don't have to wait 30 seconds for each of them because that would take a very, very, very long time. Or there'd be huge delays on that. It would essentially only work for fully autonomous instead of working with you. And the other thing is what you're trying to do is cost, right? And so if you think of it expanding, you could sort of think of a graph of a git, almost, or a multiverse, as I said, in Marvel Universe, how these things expand, but you'd actually kill them all off. So if you could spin them up
and have an orchestration around that. This is something that we're looking at at Daytona right now is once the AI has got from version A to two versions or three versions of B, kill off version A, like kill those machines right away because you don't want to have hundred machines running at the same time. But if you have like two or three or five and you're just like killing off the old ones, the compute time is going to be very low. Even though you've spun up throughout the course of like 10 minutes, you spin up like whatever, 20 of them.
but it's not gonna be like three hours of compute. It's gonna be whatever it ends up being like 15 minutes of compute, which still is very acceptable to the vast majority of people.
Kostas (44:43.594)
Ivan, I hear you talking about like this new way of writing code and the problems there to make it work. And one of the things that keeps coming back in my mind is for this to work, we kind of need also to change the way that the developer writes code at the end of the day. And why I say that, right? When you have the IDE, and let's say we talk about cursor, like cursor, there is a reason that it feels like autocomplete. It's because
It tries to be as, let's say, native to the way that the developer works, right? So as I write codes, I get suggestion. Sure. It's much smarter suggestion. Wow. But there is the concept of latency there at the end of the day. When someone writes code, you are in this kind of flow going through, like you can't.
Ivan (Daytona) (45:30.749)
Hmm.
Kostas (45:38.596)
just sit and wait and that's one of the problems that I've seen at least from my experience with this agent kind of experiences is that sure now I have this agent I have probably what I'm going to do is like 10 p.m. at night I'll ask something and in the morning I'll see if it failed or not because it has to go through all these like variations as you said spin up things around and even
And it's not just the AI side, it's also what kind of, let's say, compiler infrastructure we need. We already have people complaining about how long it takes to compile things, right? Now add to that also the latency that the agent adds there. And this is an experience that doesn't sound very helpful for a developer. So my question is, do you see like a world where...
we just get the latencies down enough that we don't have this problem or when the new way of actually directing with the machine like human computer interaction part the shift in a way where the developer completely changes the way that creates code or like knowledge, value, whatever we want to call it.
Ivan (Daytona) (46:57.853)
Yeah. I mean, I've thought about this for a while and I see a lot of, and I talk to a lot of these AI agent companies and there's a couple of trains of thought. so one is like the extension of the editor as is, or the ideas is so you'd like plugins for VS code or cursor. I cursor is the fork of VS code. So it's essentially a, like a plugin in the sense of the interface. then you have the ones that have completely new interfaces, like the world will change because we'll have a new generation of developers and we don't need.
like get, we don't need all these things because of blah, blah, whatever. I'm sort of wary of those. and there is the ones where it's like, you create a PR or a geo ticket and it goes out and does the thing. And then it comes back with whatever solution I am currently I'm currently, and I might change this. I'm currently in the belief that we will have two modes of work and what, and that are very similar to how we are right now.
And one mode is the extension of the developer where it's like essentially right now, like it's feeding you suggestions. It's like auto-complete on steroids, right? Like that type of thing is actually happening. Whereas the other sort of where it's like an agent doing thing, it's not going to be a new interface, a new ID, because building IDs is like really hard. Like it's really hard. Very few companies have done this well. And I mean, Microsoft has done it because
they had the budget to do it and they spent a lot to get that up and running. Very few have actually done that successfully over time. So I don't see that happening. But the flip side is if you have these autonomous agents which can like solve a issue on GitHub or a Jira tick or whatever, where they're actually gonna go out and do the thing, it'll take whatever time it needs. And that goes back to what I was saying in like, maybe it can spin up multiple and be faster, but it's not gonna be
like this instant and you don't need that instantaneous feedback because that's the same as having another developer, but it's not a developer because even if, you know, the three of us are working together, you're not going to solve a JIRA ticket in like three seconds. You're going to solve it like by the end of the sprint or whatever. Right. And so can this AI autonomous agent make something good enough to commit APR like in a day or nine hours or two hours or like even three hours, three days, whatever that I think has actual value.
Ivan (Daytona) (49:23.353)
And there can be latency in the sense of like, it's not instantaneous, right? But you still have this ability to create what people are talking about for a long time is like this billion dollar unicorn with one person, right? You are the person creating direct tickets and you have like these AI agents go and commit. Whereas if you're going to, you know, review the code or check out or do edits, then you will switch into or switch. You'll be in your like VS code type IDE.
which will have your sort of co-pilot things in there. So I'm in sort of the train of thought that in the foreseeable future, so we're talking about five years, like don't know what's gonna happen in 10, like chat GPT is two years. Like I think that is where we're going and all of these quasi interfaces will actually die off in the meantime. Also on that is actually very interesting is like who can actually win in this co-pilot race if the number one platform for all these co-pilots is Microsoft.
And that for me is like the most interesting question is like, how do you create, I diverged this really, not a person, I'm really interested in this topic is you are a extension company. And I know a bunch of these companies and they're doing really well, but long-term, if your interface is locked into Visual Studio Code, which is Microsoft, which has a competitive product, which has access to these, all these models before you have.
how do you compete and win in the long term? I think that is a very, you know, an interesting question. And we can ask the VC in the group here what he thinks of that, but I'm actually very interested in
Nitay Joffe (50:58.882)
I think that ties to the question of, like essentially you're saying kind of what's the future of a company like Cursor, for example. And I think you called out a few interesting things here. One that I agree strongly with is, think you're gonna see, what you essentially called out is there's a synchronous and an asynchronous path. And I think people mistakenly bundle agents and co-pilots into kind of the same thing.
Whereas in reality, in my perspective, they couldn't be any more different. Yes, obviously there's underlying technology that underpins both of them being LLMs and so on. Yes, obviously that's similar. But it diverges very quickly from there, in my opinion, because the entire product experience is different. The agent side, and for anybody out there that has worked at one of these like Fing companies, for example, Google, Facebook, et cetera, I think all of them have witnessed this already, even pre-LLM days.
where they go to work, they do a bunch of work, they go home, they come back the next day, and it's as if there's one of my friends that I called it, Magic Pixies, that enter the code base, and they wake up in the morning, and the same code that they wrote the day before is just better. Something got refactored, something changed, et cetera. Why? Because both there's automation, and there's just thousands of developers that literally are refactoring everything all the time. And so you come back literally the next day, and the code is different. And that's that asynchronous agent path that you're talking about.
Ivan (Daytona) (51:59.783)
Mm.
Nitay Joffe (52:21.624)
But in the synchronous flow, like the agent half the time might bother me more than be useful. And so the co-pilot really has to just be out of the way and just be truly supportive, not interrupted. So that's one aspect of it. The other aspect of it that I think that a company like a cursor is showing is I think there's an interesting question of like the rebirth of, to your point early on, of developer tooling as a business. Because I think what we're seeing is the...
Ivan (Daytona) (52:27.174)
Exactly.
Nitay Joffe (52:51.746)
The value of the final workflow and owning the product experience, I think can be huge. And so yes, sure, Microsoft may own the underlying model or OpenAI or Anthropic or whatever, but that's gonna be one particular kind of value, right? On top of that, you have the specific application or tool that you are using day in, day out that essentially owns your workflow. Owns it, I mean, in a good way, right? Like you love it.
love the developer experience, the workflow that you're using. There's a lot of value to that. And I think that it's interesting to your point that cursor forked VS code because just being a plugin wasn't enough. They had to do things at a much lower level and the experience really is significantly better. I have personally used it a lot. There is a lot of magic moments there that feel like, wow, this is really cool. This is really like next level auto complete.
that in my opinion has very little to do with the model. It's just the product experience is good. The underlying model, the underlying prompts they finally generate at the end of the day, I don't think is that differentiated necessarily. I'm sure other people can come up with that. But the deep level of product integration and understanding which context to stitch in and all the cleverness they do around recent files and all these different things. And like you said, knowing the local files, I think there's a lot of opportunities with that.
Ivan (Daytona) (53:51.461)
Yeah, for sure. It's a product experience. Yeah.
Nitay Joffe (54:15.33)
And that ties to one thing I wanted to ask, which ties back to the thing you were saying around, given we have kind of more developers are working remotely, I'm interested in tying this back to you. said something early on that was very interesting around kind of the different ways that companies work, right? You have kind of the how much is local versus remote and you have how much is owned by neither developer versus shared. Do you see that alongside AI and in general with kind of the...
modern world of IDEs that companies are all shifting in a particular direction and should they be? And is it, example, Daytona's job to move everybody to like, hey, there's this happy world where you have most things remote and most things shared, but we take care of all the pain for you. And that's actually the happy path.
Ivan (Daytona) (55:01.585)
I mean, that is sort of what we're trying to get to. Like your question is, yes, that's what we're trying to get to where the happy path is like, you don't have to worry about all this stuff. Whatever you decide of the variations, like it'll always work. It'll probably be, we push most to remote, although Daytona has like a local option where it can spin up a local container for you as well under the same sort of rules and regulations that apply to the remote as well. And so that's what we're trying to get to.
And sort of like, where do we sit on the AI part? Well, the interesting part is for the ability for your AI to do something. And so this is also question of which we talked to lot of companies that are building AI tools as well, is that there are specifics that you would want and regulation. think like role-based access control, whereas Yvonne will have his AI.
You know, and it's, will have his AI, but they are, they're logged in as the AI and anything that the AI creates that's outside. this is again, the synchronous asynchronous part, but like, if I created a task with my AI to create something, it has to spin up that same environment. But when it commits code, it will be flagged as that person and the access that it has to resources will be regulated by my DevOps or security team, which adds new complications. I digress slightly, but these are sort of things.
that are not out of the box that no one has solved, but are actual issues that are happening in these larger companies. Whereas if you want to give any access to AI, you're giving it as you, and then they have all the access you want, but you do not necessarily want that AI to have all the same access that you have as a person. But before I stop there, just, it's who is to exactly who takes the accountability. And so you want to limit,
Nitay Joffe (56:48.428)
That's the question of who takes the accountability at that point.
Ivan (Daytona) (56:55.549)
what the AI can read. And so my AI might be different from yours and what they can access and also what they can spin up. Can they spin up on AWS, can they spin up 32 EC2 instances? Can they spin up only one? Like at what size, in what region, what can they access? It can be the same as you as a person, but it may not be the same. Like there may be situations where you don't want it to be the same. I just wanted to head back, which was interesting that you said what was interesting about the way cursor did things.
And I think that's great, but one thing that Kerscher did is they took all the knowledge and work of VS code and built on top of that. And so how long can they continue working off of VS codes work or Microsoft's work before they have to start picking up the Slack for themselves? When they stray too far, there is a lot of work to keep that up and running and working there. And I want to like my thought on that. just.
I think that's a live viewer take on that is the only way I see a successful outcome for the handful of companies that are doing this. mean, they're going be successful in the sense of like they get acquired after whatever evaluation, whatever, but I'm talking about like, this is the new way of work. This is the VS code of the world. Like super successful is that the, of the hyperscalers acquires one of these and they have their parallel VS code, GitHub, you know, all these sort of things. Otherwise I believe they all die at some.
Like they can have successful outcomes for like founders and VCs, but I don't think they exist in long time. That's just like my thought. just wanted to go back on that because I find that super interesting.
Nitay Joffe (58:30.796)
Yeah, I mean, look, DevTools historically, I to your point, it's an interesting space because there is single points of amazing success that people think, the business is amazing, but actually there's a lot of failures as well, right? So GitHub was amazing. But to your point, if you look specifically at the IDE space, I was having this conversation with somebody the other day, there's actually not that many IDE companies. There's a lot of IDE tools, a lot of IDE products, but like a successful IDE company, the main one I can think of is JetBrains.
Ivan (Daytona) (58:52.944)
Yeah, no.
Ivan (Daytona) (58:57.949)
There's one. One. That's it. There's no more. There is no more.
Nitay Joffe (59:00.95)
Right. And so, but the biggest, I mean, you asked it, so I'll answer a little bit. The biggest mistake you often see people making is, you know, thinking the history repeats itself, thinking, well, it's just the same story time and time and again, DevTools is a bad business. DevTools is a bad business. I do believe that it might be the case that with AI, there's enough of a shift in the tooling that's going to happen that maybe opens up business models under there.
So for example, the notion that you pay something, a tool that you're searching with ultimately for information, that you pay them a monthly fee or yearly fee, that historically consumers would not have done. Now, OpenAI has billions in revenue because people are doing exactly that. That is a shift in a trend.
Ivan (Daytona) (59:26.971)
Maybe, yeah.
Ivan (Daytona) (59:42.107)
Yeah. Yeah. It does a bit more, it doesn't about propensity. For example, it's one of your, that's like essentially like a search type of thing. So yeah, true. Yeah.
Nitay Joffe (59:50.764)
Right. Right. And so I think there is a question of, is there a whole new wave of tooling? And to your point, and I think it's an important point, is that tooling have so much ingrained value in it that has real cost and real tangible support behind it, like a model or like a whole platform of infrastructure or so on being maintained for you, that it becomes worthwhile for you to pay for it.
And even back in the day, like you mentioned a few of these editors, like Sublime and so on, a lot of these editors had paid versions. Now they never became huge, but some people, there was like a cult, if you will, of people that loved the tool so much that they were paid just because that editor, they loved it so much, right?
Ivan (Daytona) (01:00:28.879)
No, and then they were, they, exactly. And they, and they lived very well off that, but like we're talking about companies that have raised like 50, 60, a hundred, $200 million. That, that is a different, yeah. I don't think the sum of Sublime's revenue was like 200 million. Like I don't think the sum ever went. Yeah. Yeah. So.
Nitay Joffe (01:00:38.04)
That's right, different ballgame.
100%.
Nitay Joffe (01:00:46.286)
100%. No, I agree with you. But I think there's an interesting bet to be made that these cursor-like things can become the new platform. like, I think it's interesting, for example, what GitLab did in a way on top of GitHub. They didn't build on top of it, but in terms of as a business, they took GitHub beyond just collaborative coding to entire CI, CD, and now GitHub is adding all those features too.
Ivan (Daytona) (01:01:00.167)
Yeah.
Nitay Joffe (01:01:07.986)
But they like expanded the universe and what it means to be a we're going to manage your Git for you. Turns out we're going to manage a lot more than your GitHub actions.
Ivan (Daytona) (01:01:13.799)
Sure, but to your point, there's also, there's also realistically only three Git providers, sort of like you have GitHub, GitLab and Bitbucket, which is like the least of the three. And so like in like technology sector, it's usually winner take most. Like that's sort of how it plays out in the end. And so again, it's always been interesting, like when I'm looking at where I'm building and focusing, and this is sort of my thought, probably like I know nothing and like who knows what's gonna happen, but it's interesting to play out.
Nitay Joffe (01:01:24.589)
Mm-hmm.
Nitay Joffe (01:01:30.146)
Mm-hmm.
Ivan (Daytona) (01:01:43.079)
these scenarios and where they go. And again, from like an investor standpoint, depending on when you get in, if you get in like a seed round or pre-seed or whatever, and so you get an acquisition at like, know, $50 million or a hundred million, whatever, it still makes money. still like, you know, double thumbs up to super success. But I'll always, when I try to plot out futures, like, is this something, is this gonna be the next, you know, jet brains where like, one in every two developers or whatever, four or whatever are using it, right? Is it the VS code? Is it GitHub? Is it?
that level of success? I don't know. And to your point, it could be that AI changes this, where now instead of having, so GitHub has like a hundred million users, although there's like, whatever, 25 million developers or 30, like do we get to a billion quote unquote, what does GitHub call them? Citizen developers or something like that? Like, do we get in that place? And then we have a billion of them, then yeah, maybe like a cursor type company can be a standalone company charged 20 bucks a month or whatever it is and still like be
super valuable just because the sheer size of the market is like orders of magnitude larger than it was historically could be.
Nitay Joffe (01:02:47.096)
No, it's an interesting question. Time will tell. We're getting close to the end of time here. Let me ask you one last question. There's one bit of your past that we didn't spend too much time talking about, so maybe just a few minutes here. Tell us about the Shift Conference that you created. What was the learnings of that?
Ivan (Daytona) (01:03:00.477)
So many learnings. you said something at the beginning is like people usually come from one or the other in the sense of like, you know, a commercial like PLG type place or enterprise or whatnot. And so I was always from like a personal perspective when I created CodeAnywhere, anything else was from a personal like I didn't understand enterprise. I did not understand someone would pay like $50,000 for a POC or $100,000 or five or a million dollars a year for like, what are these numbers, right? Like you don't understand these things.
And so when creating CodeAnywhere, was from that. And that's why we thought, assume the developer was the buyer. You assumed you were the buyer, the same person. and so with CodeAnywhere, went with a, to a bunch of conferences and then it was like pitch competitions all over the place. And we got into all these and went to them and they were like, great. I enjoyed conferences a lot. And at some point living in Croatia, Croatia at that point, this is post 2009, 10, like there was like the dot, not sorry, not the.com, but the,
crash of 2008 in the States and there it took about a while to get there. So like 2009 and 10 was just like crappy time to live. And every one of these conferences was very excited and very happy. And so I decided to start like a conference as a hobby, very much like you all are doing a podcast and did the first one, lost money, but people loved it. Second one lost money. People still loved it. And like not doing this again, but people made it convince me to do it.
At some point it started actually making money and becoming, and that sort of overlapped with the decline of interest around CodeAnywhere and made it my own, like my full-time thing. We did like three conferences a year. And the learning there was because conferences basically, the way I look at it, sponsors cover your costs and tickets are your profit. That's sort like how I thought about that. selling sponsorships is B2B sales. Like that is, you know,
Who is your buyer? What are they trying to buy? What is their budget? How much are they willing to? All these sort of things around that. Although I didn't understand that this is B2B, B2C, it's not in the same things in those terms. You were figuring out how these things worked. And you were creating conferences, also a two-sided marketplace. Almost three-sided. You have the show, which is the speaker. You have the sponsor, which is the person.
Ivan (Daytona) (01:05:19.101)
paying for it and then you have the audience which you have to come in. But basically you're selling, you're talking to all three, but you're paying these two or sorry, these two are paying you. and so how do you sell to both of them at the same time? How do you create different stories and different values for different audiences that are all converge in the same place? Right. And so that is sort of, I think a lot of my learnings now around buyer and having, you know, these questions of like, how do you create, you know, open source and PLG versus like top-down sales?
It's something I learned to navigate in these conference scenarios. And I did the conferences for like, for decades. I did it for a very, very long time. And also what it teaches you is deadlines. So the it's actually, you should check this out and like, you can verify this, but the top 10 most stressful jobs in the world conference organizer is in the top 10. Like it's a long firefighters, right? It's like, it's insanely. It's interesting. You, you, it sounds like I'm like, you know, talking BS. It is.
Nitay Joffe (01:06:14.126)
You
Ivan (Daytona) (01:06:18.843)
Like look it up. Why so stressful is because everything happens then. Like it's that day, that moment. There is no waiting. There's no patches. There's no nothing. whatever's going to happen. And usually like, especially the beginning, like shit happens. you have to solve it then and there and you have to launch it then and there. So it teaches you, like, if you did this final deadline, like we have to like get this milestone in like, you know, March 2nd.
You know, developers, especially engineers will be like, well, whatever, like it can be a day after it could be whatever, or if it doesn't work, you set a patch or update it. Like, no, you can't screw this up. The speakers have to land, the hotel has to be there, the audience has to be there, the food has to be there. Like everything has to happen at that one point. One serious story I will tell, the two stories I'll tell you about this, which is insane. The conference, I think number four, all the lights.
and sort of the video screens and everything died on the first speaker. There's the first speaker was talking. so Christian Hemeline was the speaker. Luckily he was like the baddest ass speaker in the world. So he had his clicker in his hand. Like there's nothing behind him. It's like daylight so you can see him anyway. And he keeps clicking and talking just as like the presentation is there, but there's nothing, right? And so he just like whisks through this thing.
He gets like a standing ovation afterwards. It's awesome. The tech crew, which also learned with us and sort of, you know, I have to make budgets work. Like you have to double of everything later on, got it to working by the time he was done. And so having him, it was great, but you learn like you have to do these things. The other was when I think when we hit like two or 3000 people, we decided to get all the lunches cause we gave it out for free from another city.
because it was like cheaper, like a bigger, like they would build, make everything and send it over. And the truck dies. Like the truck dies delivering food for two and a half thousand people. Like, how do you solve that problem? Like they will kill you. And I am not joking. Like these are two and a half thousand hungry developers. Like how do you solve this issue? And you have to solve it then otherwise like you're, I mean, again, figuratively, they will not literally kill you, but like that is not a happy place.
Ivan (Daytona) (01:08:37.521)
Like you don't want to be there. And so how do you solve that? What do you do to solve these issues that people actually like you afterwards? Just on that one, we had a bunch of drinks that we served like cocktails and whatever later, we gave that out right away. The truck, we sent out cars, like we got the lunch in like an hour and a half later than it was supposed to be, but there's a lot of things that have to keep, you have to be on your toes for.
And I think learning that, like if you can do that, apply that to a software startup, I think that's like has its value in gold. think that's my feel. That's how I take it anyway, because it was a stressful decade.
Nitay Joffe (01:09:14.816)
some pretty amazing stories. All right, well we know what we're going to cover next time we bring you on because there's definitely a lot more to dive into there. So Yvonne, thank you. This has been a real pleasure. Sounds like you guys are building some exciting stuff with Daytona. We look forward to watching you guys continue to execute and catching up more in the future.
Ivan (Daytona) (01:09:18.589)
You
Ivan (Daytona) (01:09:32.359)
Thanks so much for having me, enjoyed it.
Listen to Tech on the Rocks using one of many popular podcasting apps or directories.