Transcription
When we expanded the team to the first ten people, we did completely crazy recruiting tricks. For example, we flew to the other end of the world to a candidate after they said no. And yes, I think one of the key challenges that the company will face in the future, and that we have already faced in the past, is that we are in a market that, you know, has already had its iPod moment, and will still have its iPhone moment. Please welcome to the stage Michael Troy, co-founder and CEO of Cursr, and General Partner Martin Casada. [applause] Glad to be here. Good morning, everyone. Thank you for coming. Michael, glad to be here. He very, very rarely participates in things like this. I had to literally beg. I couldn't miss this. Okay. And as everyone knows, Michael's Cursr is one of the fastest-growing companies we've ever seen. It's everywhere. It's insane. And you have to hire people and manage all this chaos. So, actually, I want to dig not into the typical founder story. How you got here, we'll touch on a bit, of course, but more I want to discuss how you deal with this madness. Sound good? Yes, sounds great. Then, to start, a little history. Recently, I met with a company, and they came and said, "We are the 3D version of Cursr." And I said, "Funny story, because Cursr itself was once a 3D company." Is that true? Well, in a way, yes. And maybe you don't mind telling a bit about the origin story? Of course. There are actually a few different ways to date the beginning, but essentially the company started like this. My co-founders and I were close colleagues from school and elsewhere. And there were two moments that truly inspired us to create the company. The first was encountering some of the first truly useful products, particularly GitHub Copilot, which was a player in our space. And why did it inspire us so much? Because these products actually worked. It was the first proof of existence that AI doesn't necessarily have to work only in a lab. It was time to build systems in the real world. There are really useful things that can be done. The second moment that hooked us was the laws of scaling. We were amazed that even if an area runs out of ideas, models will still get better. This was around twenty-one, early twenty-two. And Cursr was essentially born out of a whiteboard exercise where we excitedly discussed the idea of Cursr for AI for many different areas. What did that mean? We then believed that for many verticals of intellectual labor, there would be one company that automates that area. And such a company would do several things. First, it would create the best product for that field, and it would define what the process of intellectual labor itself looks like as AI develops and improves. Then, with this product, it would win distribution, build a large business, and gain access to resources like data and capital. And then it would evolve into something that already resembles a lab a bit, not a fundamental model lab, but something similar, where it would start using the acquired data to work on foundational models and increase autonomy in that area. And this, in turn, would again advance the product and change the perception of what the best product should be. It creates a flywheel effect. And we found this incredibly interesting. We thought Microsoft would do it for programming, and we wanted to work in a sleepier, less competitive field. We had colleagues in mechanical engineering, and we were familiar with CAD systems. So, we had an initial false start. We started working specifically with mechanical engineering. We were building models to increase people's productivity within CAD systems, and also trying to build our own CAD system. That's how it all began. It was a bad idea. The fit between the founders and the market was terrible. The classic problem of the blind men and the elephant arose. We would call mechanical engineers and ask what they do during the day. And we never gained an intuitive understanding of this work. Honestly, sometimes I feel that for the 6-7 months we were doing this, we should have just interned at some company and really studied the field. In the end, we put this idea aside and returned to what interested us most, programming. I have a theory. And I'd be interested to hear your opinion, why Cursr performed so well early on. And it's actually quite banal. At the time we were studying the market, there were many companies, and they were doing all sorts of things. And much of it looked like pure science fiction. We will create an agent, a software engineer, we will create a model with new technology, we will rewrite the editor, and so on. And one of my theories why Cursr took off early is that you were incredibly focused. You chose VS Code. Copilot had been preparing the market for several years by then. And due to this narrow focus, you made a product that was simply an order of magnitude better. So, two questions. First: do you think there's any truth to that? And second: how did you manage to maintain focus when everyone else was doing everything? After all, it was the time to build agents or models or something else. Yes, I definitely think there's a lot of truth to that, but I think it's important to add a caveat here. The story of this company is still being written, and there's still a lot of work ahead. Absolutely, yes, I meant the journey up to the current point, the success up to this moment. There was just such a strong tailwind. Yes. Going back to the time we were working on CAD, the cold-start problem in that field was much harder than in ours. To start helping people be more productive, when creating engineering models for real physical objects, none of the out-of-the-box models were suitable. Moreover, there were no good 3D representations or open 3D models with portability. If you take existing text-based large language models and try to teach them to work with CAD, they simply couldn't. Therefore, a significant part of the time, in addition to calls with mechanical engineers, where we didn't understand what they did at work, which was obviously a big problem, was spent on modeling and data collection. And when we decided to put CAD aside and focus on programming, we essentially had PTSD from all of it. So, at first, yes, we were hyper-focused, we acted as quickly as possible, and just hacked, hacked, and hacked again to get something out into the world as soon as possible and start gaining momentum. Partially, this was because, you know, we had some funding, but nothing like modern seed rounds. [laughter] There were four of us co-founders. We discussed hiring and expanding the team, but honestly, we were still learning how to do that at all. So, the competitive landscape at the time looked like this. Microsoft and dozens of startups. These startups were divided into different categories. Some immediately tried to build large foundational models, some offered high-flying product ideas with radical workflow changes, and we just tried to release a product as quickly as possible. I remember that our peculiar anchor at the time was monthly investor updates, which probably no one read. But yes, from the very beginning, from the moment we decided to work on Cursr, it took us only a couple of weeks to get an IDE that we ourselves used. Moreover, at first, we didn't even fork VS Code, we built the IDE from scratch. We made an editor that we used every day. Another couple of weeks were spent giving it to other people. And in total, it seems, within a couple of months, we had launched the first beta version online. And it almost immediately started attracting user interest. And that launched the very momentum. Specifically, at the moment when momentum was building, many other companies in the same niche were starting to expand very rapidly. They immediately went to CLI or integrated with IntelliJ or somewhere else. But you decided not to do that. Was it a conscious decision or did it just happen because you had enough work anyway? Yes, it was conscious in the sense that we were constantly working. Four co-founders: breakfast, lunch, and dinner every day. What will you talk about? You endlessly argue about key strategic issues. Make an editor or an extension? Do something on the model side? What should be the first product ideas? Make a new idea? And yes, we were very, very determined to own the product surface itself. It sounded strange then, but not now. But at the time, people thought that making your own editor was very strange. Forking it or not, it doesn't matter. They said you couldn't get people to switch code editors. They are too attached to it. We knew that wasn't true, because we ourselves switched to the VS Code ecosystem with Copilot. We were Luddites, sitting in Vim on the command line. And we knew that if you make a better mousetrap, people will switch, the bar will be high. And yes, from the very beginning, we consciously understood that we wanted to work with the model part in the future. That's a whole separate story how we got there. And it became a very important product lever for us. But we didn't want to start with that. We just wanted to release a product into the world without touching modeling at all. Great. Okay. I told you this story, and you said you don't remember it. But I remember it very well, the early days were about scale. I've seen many companies in 30 years in the industry, but I've never seen such scale achieved so quickly and by such a small team. And I remember one night you called me and said, "Listen, we took down one of the major cloud providers because they can't handle our scale." There was a relatively small service interruption, and then you fixed it. But, as Oscar told me, during that time, someone came to the Cursr office, put an iPad to the window, and it said: "Cursr is down." So, it was definitely a moment when people started to notice. For me, it was a kind of shock, because it was about some inconspicuous building that suddenly became known. So, it would be great to hear how you and the team as a whole think about dealing with such scale. Especially considering that you are already essentially starting to load the platforms you rely on. Although these are some of the largest platforms in the world, there's nowhere else to grow. Yes, this story just gets lost among many others. Yes, a long time ago. Yes, I think that in the early stage, how we encountered scale looked like this. There was a tiny team serving a service that started growing very rapidly. And my co-founders are great guys, but, as you can understand, we don't have the most experience, if we talk about the number of years. And so, yes, very quickly we had a huge number of users. There are things that, especially if we talk, for example, about our own file synchronization system, you can think of them as two or three mini-Dropboxes inside. In the early days, there was essentially a search engine for AI. And you know, at first glance, it doesn't sound that difficult, but in practice, it turns out to be quite unpleasant to implement. And depending on how exactly you build it, such things can start to load the systems you rely on. But yes, very quickly we reached scale even in the context of ordinary boring cloud services. And there was a whole story about how we managed a very, very large Kubernetes cluster, large compared to many other companies, and tried to figure it out on the fly, with only five people in the company, facing outages and problems. Then we more or less took it under control, made some correct architectural decisions, expanded the team. And the next big scaling problem arose at the API provider level. And here it wasn't so much about some super-smart technical tricks, but about relationships. I think API providers themselves didn't fully understand what to do with us, because in front of them are four twenty-something guys, and their product suddenly starts bringing in a very high double-digit percentage of the provider's total API revenue. And now these companies have to make capacity planning decisions, possibly even financing decisions, to cope with this growth. It was more about building relationships. And I think we are still learning to build connections with people. Plus, we've become quite resourceful. It turns out that the same API tokens for one model can be obtained from different providers. There are token resellers, and it's strategically beneficial to distribute the load among several providers with whom there are contractual obligations. So, we've become very good at tracking down all the Sunet tokens in the world. This was a difficult level of scale for us. Now, I would say, we do a lot of our own training. We perform some of our own inference, and, accordingly, a completely new layer of scaling problems arises. A whole new class of tasks related to decision-making at this level emerges. Do you think that in the end it all comes down to heterogeneous dependence on third parties or, conversely, to you mainly building your own infrastructure? Are you talking about basic model inference? No. No, I'm talking about infrastructure in general. That is, over time, you bring more and more things inside, just to have control over them. In the sense of running the desktop application website, backend, and all that? Yes, I think from the very beginning we were quite multi-cloud and are likely moving by default towards a heterogeneous model, relying on multiple providers. We have DABCKS, Snowflake, we use AWS, GCP, and Azure for the web and our own hosting. For databases, we use PlanetScale. And a significant part of those boring cloud scaling problems was tied to databases. On the one hand, the Kubernetes part, where things like CoreDNS failed. On the other hand, a whole series of stories related to databases, because some of our scenarios are quite heavy for databases. At some point, the standard advice "just increase the RDS instance" works for a while, and then you hit a ceiling. And the next question is, should you shard the database or not? We switched to an AWS service that, it is claimed, does not allow sharding the database. As it turned out, this is not entirely true. It usually seems that public clouds have everything perfectly debugged, but at the very top level of scale, they have a very small pool of clients, and they are also figuring a lot of things out as they go. And here PlanetScale turned out to be incredibly useful. Sam, are you here? Thank you very much, Sam, we appreciate it. Let's applaud Sam, all the developers. Applause for Sam. Well, in general, for us, it's several providers. Different providers are strong in different things. And this is our plan. Before we move on to the topic of talent, you maintained focus excellently, but over time you started making many different products. You made Backbot, CLI, you're improving infrastructure. How organic and obvious was the decision to do this? And how consciously do you approach prioritization? Or maybe just tell us how you generally think about where to direct R&D resources, given everything you're dealing with. It's a very conscious choice. We try to say no to many things, but I am convinced that in the future we need to be a multi-product company. There is huge potential in our niche to create a whole suite of coding tools. We want to become the primary provider in this area for many of our clients. For now, our main focus is the entry point, i.e., the screen where an engineer spends their entire day creating software. Our editor. We believe there is still a lot of work to be done there, and this is our priority, where most of the resources go. But we also see that changes in the editor's functionality are starting to affect how teams interact with each other. And we believe this is both a great strategic opportunity and simply a necessity. To make the best editor in the world, you need to have an add-on that helps teams review code and collaborate more effectively. We are doing this purposefully. We are still learning how to do it correctly. How to provide support for such projects, how to work with cross-selling. In our field, there are huge opportunities for this, both from the product marketing PLG side and from the sales department. I will say that many founders underestimate how difficult it is to go from one product to several when it comes to market entry. It is indeed very, very difficult. Yes, and here we are still learning a lot, but we are very inspired by the initial results. Great. >> Subscribe to my Telegram channel right now via the link in the description. I have prepared for you the top three materials that, in my opinion, everyone should know. First, a map of a hundred top AI startups - this is the future in one picture. Second, a forecast from an insider from OpenAI, who predicted everything that is happening with neural networks even before the appearance of ChatGPT. And this year he released a new forecast until 2027. And third, the most powerful is my analysis of the essay by the founder of Anthropic, who is essentially the second person in the world of artificial intelligence. He laid out step-by-step what will happen in the world in the next 5 years, and most importantly, what the universal AI, which everyone fears or awaits, will be like. Go to the link in the description. >> Then let's move on to the topic of talent. I think you have one of the most rigorous and thoughtful hiring processes I've ever seen. I try to set aside some evenings and weekends to help you communicate with candidates and recruit people. And before each such call, I receive an incredibly well-prepared document. Here's where we are. Here's what we've done. There's a colossal amount of work behind this process, in my opinion. So, if you don't mind, tell us how you generally think about recruiting, how you've structured the process, what you've learned, what works, and what doesn't. Yes, let the board members make a lot of calls until they cry. Prepare them all, just use their time. Yes, how do we think about recruiting? I think in many ways our process is quite orthodox, but there are also things that are perhaps unique. For example, when you're a small company, there's a trick with the first engineers. You essentially just work with them on contract and don't conduct standard LeetCode interviews or full interview cycles. We did that. It seemed the most natural, because you get straight to the point. Are you comfortable working together? Usually after a couple of hires, this is abandoned. We, and we've tried to kill this internally many times, and I myself have tried to close it. We are still continuing to do it. Everyone we hire for the engineering or design team spends 2 days in the office and works on a project. And it's a very informal format. It's not a series of whiteboard interviews where every minute is scheduled. Here's a desk, here's a laptop, here are three projects you can work on. Here's a frozen, older version of the codebase with DX set up. Just go and do it. And this approach has two functions. The first is an excellent test for things that are orthogonal to the standard coding interviews that we conduct before the on-site stage. We look to see if a person can go through the entire process in code, if they show initiative. We have design, engineering, and product closely linked, so we look for engineers with product sense. This format shows it well. What will a person build if left alone without a team? And, in my opinion, this gives us a very strong signal about the fundamental technical skills needed for success in our environment. Another thing this does for us is that it also works as a cultural interview. You have four to six meals with us. And you know, this gives us an understanding of whether we would want to be around you, whether you want to be around us. Speaking of one of the advantages, perhaps a third sub-point, it also gives the candidate a huge amount of information about the company and what it will be like to come in on the first day of work. I think, thanks to this, the probability that a person will fit perfectly into the team is very high. This is one of the most unusual things we do. A two-day immersion into our environment, and we stick to it, even though we have over 200 people now. But you don't do this for sales departments or other divisions. We did it at the very beginning to hire the first salespeople, we said, "Here are our inbound leads, you have a quota, go ahead." It was more structured. They did demos, conducted simulated client conversations, but we gave them access to real data so they could dive in. The very first employee was like that. He came, we showed him everything and said, "Now teach us how to sell." But then it became more structured. Understood. Great. Listen, I generally think that this wave is changing a lot of established ideas about how to build companies. This is a new supercycle. We are essentially rethinking everything. You are definitely at the forefront of this process. You, I would say, have relatively young people managing very large organizations. And it works incredibly well. And another thing you do, I would say, almost to an extreme degree, is mergers and acquisitions. You are very good at conducting such deals for companies that are only 2 years old. Many private firms buy other startups, but you do it masterfully. Could you share your vision? Before the AI era, it was thought that startups shouldn't buy other startups, but for you, this has brought great success, and not only. Cursr? What are the main lessons from this process? Yes, I think that so far for us it has been a continuation of the approach to do everything possible to attract the most talented people. And so, in the early stages, when we were expanding the team from zero to the first ten people, we did crazy recruiting tricks, like flying. Some of these things are quite common. People do that, but a lot was like flying halfway around the world to someone, even after they said "no." And then, when they say "no." After you've flown halfway around the world, you come up with a dinner with researchers, which takes place in San Francisco, and you say that he should definitely fly there and come in 6 months, so that you can reignite the conversation and eventually convince him to become an engineer. And in the end, he turns out to be one of the best people on the team. That really happened. So yes, we really tried to get the most talented people. And I think sometimes, conveniently or inconveniently, these people work in companies. And mostly that's where it came from. It all started from the talent side. I think that in the future, given the entire range of products that are possible in our space, and the advantages we see in combining them, we are particularly interested, earlier than most companies at this stage of maturity, in using mergers and acquisitions as a strategic tool, including to start building a multi-directional structure and adding complementary products. And yes, for each new product, if it becomes possible in our space, we can try to build it internally. We can see what the market offers. And if there is a truly right match with the right set of founders, we will be happy to join forces with them. That's how we've thought about it so far. Our first truly large acquisition was SuperMe. For example, it was a team of five people. It was founded by the person who created Tabnine. Essentially, the predecessor to Copilot. He worked as a researcher at OpenAI with John. Jacob is a fantastic specialist. He worked on code autocompletion models, just like us. Our technologies complemented each other perfectly. We stayed in touch for many months, and in the end, we approached him with a very aggressive offer. Well, we have to wrap up, but I have one last question. It was asked by one of your candidates, and I really liked the wording. He said, "Cursr is changing the very essence of software, which we all agree with, and the wave is breaking old foundations." But at the same time, Cursr itself is written in software. Don't you think this is a kind of Ouroboros that will eventually consume your own solution? That sounds philosophical. I'm interested to hear your opinion. My answer to him was along the lines of, "It's better to be the one who destroys than the one who is destroyed." But that sounded too venture-capitalist. Yes. And there's still this narrative around Cursr. Like, if Cursr is so good, then someone can No, this was a person I was very happy with. He was a very philosophically inclined person who was super interested in joining. The question was, if you are building a tool to transform an industry, and the foundation of your own product is something that is being transformed, what does that mean for you? Yes, I think there are two points here. First, despite the headlines, despite how high the demand is in this market now and how much software has changed in recent years, we are still very far from automation. 100%. It is still extremely inefficient. Creating software in a professional environment, especially when it comes to teams of tens to tens of thousands of people, is, well, at the management level, it's very easy to underestimate how far we still are from the limit of development automation. So, I think there is still a very long way to go. There is a very long chaotic middle. And yes, I think one of the key challenges that the company will face in the future, and that we have already faced in the past, is that we are in a market that had an iPod moment, will have an iPhone moment, and another iPhone moment. And I think there have already been several such moments. I am sure there will be more to come. And we have tried to build a company as a place that is capable of constantly creating such things, because if we don't, well, we're done. And I think this is both a challenge and one of the pleasant aspects of the physics of this space, because it is also one of the reasons why giants like Microsoft find it quite difficult to truly compete here on a large scale. But yes, it is definitely a challenge. Great, wonderful. Thank you very much. Please give Michael a round of applause for coming and doing this.