Why Token Maxing is Failing Enterprise Startups | Legora CTO

Transcript

What percent of developer salary would you be willing to spend on AI tooling for them? I don't want to say infinite, but for me it's a question of opportunity cost. We're in a competitive environment. There's so many things that we can do and the cost of not doing it is extremely high. It almost outweighs any sort of token cost. Now I'm so excited to welcome Jacob Luritson, CTO at Lugora to the show today. The fastest growing enterprise company in history. They hit 100 million in ARR in just 18 months. Jacob is one of the best product minds I've had on the show. Specifically from the last crop of product leaders in this AI generation. Honestly, you just work harder than the 800 pound gorilla. People underestimate this, the 800 pound gorilla. No one in the 800 pound gorilla is extremely excited to be there. Ready to go? Jake, dude, I am so excited for this. I think Max is one of the most... Do you know what? I think it takes a psychopath to know one. And he's, fuck you, Harry, already. But he's just exceptional. I know the bar of talent that he has. And so I know that this show is going to be amazing. So first, thank you so much for joining me. [SPEAKER_02] Yeah, of course. [SPEAKER_02] Thanks for having me. Now, we were just chatting and you said Lugora is the first big company or company of this size that you've worked at. And I was thinking, is that a blessing or is that a curse? How do you think about that? [SPEAKER_02] I'd like to think that it's a blessing. I just have to be really, really humble about it. So essentially, I don't have any priors coming into how to build an engineering org. I think building an engineering org in 2026 is very different from doing it in 2024, maybe even. And so I think in that way, it's really good that I come in naive and I'm like, okay, let's try to do it this way. And if it doesn't work, we keep iterating, just like we keep iterating on our product, we keep iterating on our organization and our processes. And I just work with the team. What's working well, what's not working well? How do we solve that? Just another problem. [SPEAKER_01] Dude, how is it different building a team and your product in 2026 versus 2024 and years prior? Everything's just changing all the time right now. [SPEAKER_01] Productivity is through the roof. [SPEAKER_02] Processes are up in the air. [SPEAKER_02] You can be huge teams. You can be tiny teams. Productivity is through the roof. [SPEAKER_01] If we unpack that, why is it through the roof? Well, just AI tooling. I mean, what do we use internally? [SPEAKER_01] It's Cloud Code. It's Cursor. [SPEAKER_01] You use both? [SPEAKER_01] Those two are competing. Yeah. Wow. Because everyone runs from Cursor whenever I interview them. [SPEAKER_02] Yeah. So you still have Cursor users? [SPEAKER_02] We still have Cursor users. [SPEAKER_02] The Cursor harness is quite good. [SPEAKER_02] There's some personality differences on our team, but a lot of people still use Cursor. [SPEAKER_02] Some use Cloud Code. Some use Pi because Cloud Code's harness is annoying sometimes. [SPEAKER_02] We allow people to do both. [SPEAKER_01] Okay. And so we have efficiency against that. [SPEAKER_01] And so we just ship more? We ship more. We ship faster. We debug things faster. We iterate faster. Everything is faster now. [SPEAKER_02] And each engineer can produce much more than they could previously. [SPEAKER_02] And that just has a ton of ripple effects throughout the org, and how you structure it. [SPEAKER_02] Because I think a way I like to think about it is, when you build software, there's three phases. [SPEAKER_02] There's phase one, which is the product work. What are we building? Translate user pain, user dreams, nightmares into something tangible that we can try and we can iterate on. And we can figure out if it works. And once you have that, you know what you want to build. Then you build it. You write the code. And then you review the code and you merge it and you get it going. And number two was the primary bottleneck for the past 100 years, almost. So the rate limiter was how quickly can you write code. That is now super cheap. So that's been compressed. And so the bottleneck now is the two other ends, which is review. How can we do that much more efficiently? And then it's how can we actually do the product piece much more efficiently? Because if you believe that code is cheaper to write, then naturally the two other things are bottlenecks. And that means one of the focus areas is how do we do the product work as efficiently as possible? [SPEAKER_01] How do you think about that then? That's a great question. Part of that is how do we make our PMs as efficient as possible? How do we take all the working with clients, synthesizing what they think, our own strategic priorities, our own tastes and opinions of our vision of where our product is going? How do we make them do that as efficiently as possible and hand that over to engineers as efficiently as possible? So I'm not sure if I've solved that yet. But I do think that's the way that I'm thinking about it is constantly what's the bottleneck to our velocity? And then we try to solve that. You said about the review being one element of it. [SPEAKER_01] It could be a bottleneck. Do we see AI code review becoming the dominant source of review? How do we make them do that as efficiently as possible and hand that over to engineers as efficiently as possible? How do we make them do that as efficiently as possible and hand that over to engineers as efficiently as possible? [SPEAKER_01] So I'm not sure if I've solved that yet. But I do think the way that I'm thinking about it is constantly what's the bottleneck to our velocity? And then we try to solve that. You said about the review being one element of it. It could be a bottleneck. Do we see AI code review becoming the dominant source of review? And does that then remove it as a bottleneck? [SPEAKER_02] I think so. I think that's one of the solutions. We do AI code review today. And it's in its nascent phase. [SPEAKER_02] Yeah, exactly. You just ate all the Maltesers. It's in its nascent phases. Sweet. Yeah, that's nice. It's rough edges still. But no, I think that's right. I think that's part of it is getting, we have AI review bots. You can have security review. You can have different specialized reviewers. They do tons of review and they iterate with the AI coder. [SPEAKER_01] And it's weird because you see this pattern where it's agents fighting each other until they arrive at something. [SPEAKER_02] But even then, I think current review tools are not good enough. I think we need something new. I keep telling people at all events that I'm at, if you're going to do a startup, please do something that solves the review thing. Because no one wants to look at all the lines of code. What's important is what's the impact on systems architecture? What's the impact on systems design, stability, security boundaries? [SPEAKER_01] How does it take our system in the right direction? [SPEAKER_02] That's the stuff that you want to review. And if that doesn't change, then maybe you don't have to review it at all. Just unleash the agent. But if it does, if there are some strategic tradeoffs, then you want a human to be like, yeah, this is the right direction to take. Is that the future of engineering being systems design, systems architecture, and then bluntly code creation, code maintenance is actually completely done by AI? [SPEAKER_02] Yeah, I think so. I think that's right. The job of an engineer is changing from typing a bunch of code to one layer above it, which is what does the system look like? And then you can have AI running around inside each of the pieces of the system, but you have engineers thinking about the higher level one abstraction above, which is what does the system look like? What are the bets we're making in different places? Do we want to invest into doing something here that we can reuse a bunch of places over here and it's going to make everything much more stable? [SPEAKER_02] That's one of them. I think the other thing that engineers are doing more and more, which is an explicit role with us soon, is the meta engineering of making agents really effective. You know how you have developer experience teams that might help write custom linting or custom developer setups to make developers efficient. We need to have the same team for agents. How do we make agents really, really effective? [SPEAKER_01] How do we make sure that we can enable agents to independently self-improve the system? Can we gather data in a really good way so that we can unleash agents and say, hey, increase conversion rate on my e-commerce store? And it can just go and run experiments. [SPEAKER_01] That setting up the loop so agents can just run and optimize. I think that's going to be the actual job of a lot of engineers. [SPEAKER_01] How do you think we do that? I spend a lot of time with Jason Lamkin and Anjali Mitter, who's amazing. But they both told me that fundamentally, in a world where agents are the pickers of software, the API quality that we have is the core determinant of what agents will choose software based upon. How do you think about how we make agents more effective? Is it a simple question there of data and making sure we're the best at that? How do you think about it? We have to set up the guardrails really effectively. [SPEAKER_01] How do you think we do that? [SPEAKER_01] I spend a lot of time with Jason Lamkin and Anjali Mitter, who's amazing. [SPEAKER_01] But they both told me that fundamentally, in a world where agents are the pickers of software, the API quality that we have is the core determinant of what agents will choose software based upon. [SPEAKER_01] How do you think about how we make agents more effective? [SPEAKER_01] Is it a simple question there of data and making sure we're the best at that? [SPEAKER_01] How do you think about it? We have to set up the guardrails really effectively. This is actually something that I'm thinking about right now. Our code base is starting to get large. It happens. It's a good problem to have. [SPEAKER_01] [SPEAKER_02] We're starting to have a lot of engineers. [SPEAKER_01] [SPEAKER_02] We're also starting to have a lot of agents that are working on this together. And so you start to think about how can I mechanistically enforce the system to behave a certain way. So I'll try to give an example here, which is you can have custom rules, for example, which is the agent tries to do something and we tell it, no, you can't do that. There's for whatever reason, you can't do that because we want the system to be in this way. And I think that type of guardrail setting will be everywhere. And so if you're a big enterprise and you're rolling out AI tooling and you have agents that build your own internal software, you have AI tools that build your HRAS system and your ATS system and whatever else. [SPEAKER_01] [SPEAKER_02] You probably have some engineers that are just setting up the this is where you get the data. [SPEAKER_01] [SPEAKER_02] This is what you can do. [SPEAKER_01] [SPEAKER_02] This is what you can't do. [SPEAKER_02] And then you can just let agents run inside of that system. There's for whatever reason, you can't do that because we want the system to be in this way. And I think that type of guardrail setting will be everywhere. And so if you're a big enterprise and you're rolling out AI tooling and you have agents that build your own internal software, you have AI tools that build your HRAS system and your ATS system and whatever else. [SPEAKER_02] [SPEAKER_01] [SPEAKER_02] You probably have some engineers that are just setting up this is where you get the data. [SPEAKER_01] [SPEAKER_02] This is what you can do. This is what you can't do. And then you can just let agents run inside of that system. [SPEAKER_01] You mentioned the expansion of the Lagora code base today. [SPEAKER_01] [SPEAKER_02] [SPEAKER_01] But what percent of code created today is AI generated versus human generated? [SPEAKER_01] [SPEAKER_02] Actually, I took a look recently and it's Claude and Cursor on top. And there's, I think, 2% between them. [SPEAKER_01] [SPEAKER_02] So they are really, really close. And then it's miles above the next engineer. So they're way above 50%. [SPEAKER_01] Do you worry that we will see a next generation of security threat with the amount of AI generated code that bluntly opens vulnerabilities we didn't know we had? [SPEAKER_01] Yes. [SPEAKER_01] Absolutely. This is very top of mind for me. And that's why we still at Lagora and probably in a bunch of other enterprise software, we still review human PRs, every single one. Just because we have to be sure. [SPEAKER_01] [SPEAKER_02] I think that's inefficient. I want to get some risk scores in there and change that so that we can run really fast. But fundamentally, I think you're right. I think threat actors are extremely efficient now, which means they can try so many different things and they can keep running at it. [SPEAKER_01] [SPEAKER_02] And so we need just as good defense. [SPEAKER_01] [SPEAKER_02] And I'm not sure if we're there yet. [SPEAKER_01] I definitely don't think we're there yet. [SPEAKER_02] [SPEAKER_01] Yeah. [SPEAKER_02] And that's why we still at Lagora and probably in a bunch of other enterprise software, we still review human PRs, every single one. Just because we have to be sure. I think that's inefficient. I want to get some risk scores in there and change that so that we can run really fast. But fundamentally, I think you're right. I think threat actors are extremely efficient now, which means they can try so many different things and they can keep running at it. [SPEAKER_02] [SPEAKER_01] [SPEAKER_02] And so we need just as good defense. [SPEAKER_02] [SPEAKER_01] [SPEAKER_02] And I'm not sure if we're there yet. [SPEAKER_02] [SPEAKER_01] I definitely don't think we're there yet. [SPEAKER_02] [SPEAKER_01] Yeah. [SPEAKER_01] Which is why we see so many hacks. [SPEAKER_01] And so whenever I see the hack on Twitter, I'm like, oh, poor. And their weekend is thoroughly ruined. Yeah, yeah, yeah. I had a security incident. Oh, not me. [SPEAKER_01] [SPEAKER_02] One of our vendors had a security incident just yesterday. We just rotated a lot. To be clear, this was internally, doesn't affect any of our clients or anything like that. But it's just I think we're going to see more of them. [SPEAKER_01] Yeah, I totally get that. [SPEAKER_01] I interrupted you when we spoke about the efficiencies earlier that comes with AI. You mentioned the second was the processes that change. How do processes change, be it PRs, be it postmortems? Well, actually, postmortems is a great example. We run them really efficiently now. It's great. [SPEAKER_01] [SPEAKER_02] And if you have an incident, now you just unleash an SRE agent and an incident agent. [SPEAKER_01] [SPEAKER_02] And it will just super quickly figure out what's going on. [SPEAKER_01] [SPEAKER_02] Look at all the logs. [SPEAKER_01] [SPEAKER_02] Look at all the metrics, sorry, telemetry. And it's surprisingly good. It's really, really good. Postmortems is a great example. We run them really efficiently now. It's great. [SPEAKER_01] [SPEAKER_02] And if you have an incident, now you just unleash an SRE agent and an incident agent. [SPEAKER_01] [SPEAKER_02] And it will figure out what's going on super quickly. [SPEAKER_02] Look at all the logs. [SPEAKER_02] [SPEAKER_01] [SPEAKER_02] Look at all the metrics, sorry, telemetry. And it's surprisingly good. It's really good. And so instead of having a bunch of engineers wake up in the middle of the night, you still have some waking up in the middle of the night. But they are really well equipped. [SPEAKER_01] [SPEAKER_02] And the postmortem basically writes itself as well. [SPEAKER_02] So that's actually a great example of something that we can run really efficiently. [SPEAKER_02] But I think more broadly in the software development lifecycle with AI, PMs can prototype super fast. [SPEAKER_02] Which is really great because that means you can front load a lot of the work. So a PM can start way before, once he or she has the smallest inkling of an idea that we might want to do this. They can prototype it and they can test it. [SPEAKER_01] [SPEAKER_02] They can iterate themselves. [SPEAKER_01] [SPEAKER_02] They don't even need to bring in engineering until they have something that's clearly super valuable. [SPEAKER_01] [SPEAKER_02] And then we can switch and we can say, okay, now we take this from prototype to something that actually fits in the system and is super reliable. [SPEAKER_01] [SPEAKER_02] [SPEAKER_01] Do we skip the design stage in a world where prototyping and getting to V1 is so much easier? [SPEAKER_01] [SPEAKER_02] Probably some companies will skip the design phase. [SPEAKER_01] [SPEAKER_02] I think we can skip the design phase on functionality. You don't need to necessarily have this long discussion where 10 people need to figure out where should the button be. [SPEAKER_02] I do think design still has a place, but it's one level above the individual features and the individual stuff that we build. [SPEAKER_02] [SPEAKER_01] [SPEAKER_02] It's the design language that we choose to have. [SPEAKER_02] [SPEAKER_01] [SPEAKER_02] It's the taste. [SPEAKER_02] [SPEAKER_01] [SPEAKER_02] It's the opinionated stance we have of who we are and what does Lagora look like? [SPEAKER_02] [SPEAKER_01] [SPEAKER_02] What's the navigation? What's the hierarchy? But it's more for consistency UX UI sake and for taste sake rather than functionality. [SPEAKER_01] Totally get that. [SPEAKER_01] Do you still use Figma today? [SPEAKER_01] [SPEAKER_02] We still use Figma, yes. [SPEAKER_01] [SPEAKER_02] I know where you're going with this. [SPEAKER_01] [SPEAKER_02] As soon as you start building a system that's larger than something very small, you want consistency and you want to have a design language and all that. [SPEAKER_02] [SPEAKER_01] [SPEAKER_02] And so you need somewhere to store what your button looks like and what your pages look like and what's this and what's that. [SPEAKER_02] What's the hierarchy? [SPEAKER_02] But it's more for consistency UX UI sake and for taste sake rather than functionality. [SPEAKER_02] [SPEAKER_01] Totally get that. [SPEAKER_01] Do you still use Figma today? [SPEAKER_01] [SPEAKER_02] We still use Figma, yes. [SPEAKER_01] I know where you're going with this. As soon as you start building a system that's larger than something very small, you want consistency and you want to have a design language and all that. [SPEAKER_01] And so you need somewhere to store what your button looks like and what your pages look like and what's this and what's that. And for us, that's Figma and it works great for it. Could it be my down files? [SPEAKER_01] Yeah, do you think that's the case moving forward? I don't mean anything against Figma, but that's a storage feature. [SPEAKER_01] Yeah, I know. I mean, it could be something else. Yeah, you're right. Then the question is, is it faster for designers to take a prototype to something really crisp in Figma versus prototyping? [SPEAKER_01] We mentioned the wonderful word earlier. It's the word of the moment, which is taste. [SPEAKER_01] Taste is what separates us. How do you think about taste is what the differentiator will be? [SPEAKER_01] Is that true or is that bluntly Silicon Valley and tech BS that's trying to protect us? [SPEAKER_01] [SPEAKER_02] I think taste is important. [SPEAKER_01] [SPEAKER_02] There's different flavors to taste. [SPEAKER_02] Pun intended. [SPEAKER_01] [SPEAKER_02] It depends on what you mean with taste. [SPEAKER_01] I think in tech, taste is we have an opinionated stance on something. [SPEAKER_01] [SPEAKER_02] I think if you don't have taste, then you let AI slop converge to grayness and everything looks the same and everything's just. I think you need to have taste to have an opinionated stance in the world. [SPEAKER_01] This is who we are. [SPEAKER_01] [SPEAKER_02] This is what we do. [SPEAKER_01] [SPEAKER_02] And we don't do these other things. And that's not for everyone. I think to me, that's what taste means. It's, this is who I am. This is who we are. [SPEAKER_02] And some of you are going to hate it. [SPEAKER_02] And that's okay. [SPEAKER_02] Because you need to have some edges. If you're just letting AI rip, you're going to look the same as everyone else. [SPEAKER_01] When the cost of copying is quicker than ever, does that change how you think about product? [SPEAKER_01] [SPEAKER_02] You're in a very competitive space. [SPEAKER_01] But many people can copy very quickly. Does that change how you think about product? [SPEAKER_02] No, not really. [SPEAKER_02] [SPEAKER_01] I think the important thing for us is that we're building something that our clients get a lot of value out of. [SPEAKER_02] And we build that as fast as we can, but we don't build it faster than that. There are tons of people that are vibe coding. [SPEAKER_01] [SPEAKER_02] There's people that are vibe coding Lagora. [SPEAKER_01] There's people that are vibe coding Salesforce and Docs Design and other companies. [SPEAKER_02] You're in a very competitive space. [SPEAKER_02] [SPEAKER_01] But many people can copy very quickly. [SPEAKER_02] Does that change how you think about product? [SPEAKER_02] No, not really. [SPEAKER_02] [SPEAKER_01] I think the important thing for us is that we're building something that our clients get a lot of value out of. [SPEAKER_02] And we build that as fast as we can, but we don't build it faster than that. [SPEAKER_01] There are tons of people that are vibe coding. [SPEAKER_01] [SPEAKER_02] There's people that are vibe coding Lagora. [SPEAKER_01] There's people that are vibe coding Salesforce and Docs Design and other companies. [SPEAKER_01] [SPEAKER_02] When the cost of copying is quicker than ever, does that change how you think about product? [SPEAKER_01] You're in a very competitive space. [SPEAKER_01] [SPEAKER_02] But many people can copy very quickly. [SPEAKER_01] Does that change how you think about product? No, not really. I think the important thing for us is that we're building something that our clients get a lot of value out of. And we build that as fast as we can, but we don't build it faster than that. There are tons of people that are vibe coding. There's people that are vibe coding Lagora. There's people that are vibe coding Salesforce and Docs Design and other companies. It's very quick to get to the 90% where it looks the same. And in 80% of the cases, it works similarly. It's the other 90% that are difficult. [SPEAKER_01] It's ensuring all the edge cases work and all the unhappy paths and all the audit locking and all the RBAC and all the weird scenarios that you end up at at a certain scale. [SPEAKER_02] That's what's difficult. [SPEAKER_02] So no, we keep focused on how do we create the most value for our clients and sprint towards that as fast as humanly possible. [SPEAKER_02] [SPEAKER_01] My girlfriend is a lawyer and she's wonderful, but they're not the fastest in terms of adoption and usage. I'm going to get in huge trouble for saying that. [SPEAKER_01] I was not talking about her. [SPEAKER_01] I was talking about the legal profession. [SPEAKER_01] Okay, good. [SPEAKER_01] You can build products so much faster than your customer can consume it. [SPEAKER_01] Yes. [SPEAKER_01] How do you think about that? That's a great question. [SPEAKER_01] We have this notion internally that there's the speed of AI, there's the speed of our product, and then there's the speed of humans. [SPEAKER_01] [SPEAKER_02] And they're not the same necessarily. [SPEAKER_01] [SPEAKER_02] I think that's part, honestly, of the beauty of what we're doing is that we're translating the immense speed of AI development into a user base that's been historically underserved. [SPEAKER_01] [SPEAKER_02] And we're taking them along for the ride. [SPEAKER_01] [SPEAKER_02] And so I think sometimes it can be frustrating, but it's also really rewarding that we can actually take this huge base of people and we can really change the way that they work and their efficiency and their productivity. And we can remove the tons of awful work that they've spent their time doing and focus on the more strategic, more important work. [SPEAKER_01] What have you not done that you wish you had done? [SPEAKER_02] An email client would have been really cool. [SPEAKER_02] I would have loved to build that. [SPEAKER_02] I vibe coded one just for fun. [SPEAKER_02] We're probably a few ways away from that because there's other high-priority things, but I think an email client is where lawyers sit a lot. [SPEAKER_02] [SPEAKER_01] Do you vibe code internally within Lagora for customer presentations, for anything you name? [SPEAKER_02] Constantly. [SPEAKER_02] [SPEAKER_01] Is that the future of enterprises or is that bluntly Lagora at the very precipice of innovation? [SPEAKER_02] It will be the future. [SPEAKER_02] [SPEAKER_01] I don't know when, but it will be the future. [SPEAKER_01] And just so we understand, what does that mean? [SPEAKER_01] You build sites for Slaughter and May so you can pitch to them and Clifford Chance so you can pitch to them? No, but it's way broader than that. [SPEAKER_02] It's we have a team now that's internally at Enablement, which is just reimagining, from first principles, with all the stuff that we have today. If you're building the most efficient company to go from, let's say, 200 to 1,000 employees, what does that look like? And that means obviously Claude Cowork and similar things for everyone, but it's also we can just build a bunch of the tools that we need ourselves. Can we just vibe code a bunch of the tools? Can we vibe code our HR system? Can we vibe code our talent acquisition system? Can we vibe code our payroll system? [SPEAKER_02] So many things where tools exist out there, but you always need to customize them so much and they basically never really work. And we just built them now because it's so cheap to build. [SPEAKER_01] What have you been able to vibe code away? Let's see. We've primarily added a bunch of things that are additions to vibe coding. So a great, really stupid example is Ryan, who joined from Canada. [SPEAKER_02] We have a team of people joining from Canada. [SPEAKER_02] They're all moving to Sweden. [SPEAKER_02] And he vibe coded an app to help everyone migrate. [SPEAKER_02] So very specifically, if you're Canadian, these are all the laws and all the steps you take. [SPEAKER_02] And it's interactive and you can see how far you've made it. [SPEAKER_02] And it's awesome. [SPEAKER_02] And it took, I don't know, a day to vibe code and it saves so much time for an entire team. So you can build the big systems, but even just all the small ones that you can build really add up. [SPEAKER_01] So I was with a friend who's a public company CEO the other day. [SPEAKER_01] And he was, my chief of staff took three weeks off and basically vibe coded Cooper and we replaced Cooper. [SPEAKER_01] And it works and it's brilliant. And it's interactive and you can see how far you've made it. And it's awesome. And it took, I don't know, a day to vibe code and it saves so much time for an entire team. So you can build the big systems, but even just all the small ones that you can build really add up. [SPEAKER_01] So I was with a friend who's a public company CEO the other day. [SPEAKER_01] And he was, my chief of staff took three weeks off and vibe coded Cooper and we replaced Cooper. [SPEAKER_01] And it works and it's brilliant. [SPEAKER_01] What do you say to people who are, that's ridiculous. [SPEAKER_01] Why would you ever bother vibe coding and taking months to do an HR system when you could just buy it off the shelf? It really depends on the system. There are certain systems. There are two accesses to systems. There's the horizontal one, which is how big is your product surface area? And there's the vertical one, how complex is it? So if you're deep, your surface area looks quite similar. [SPEAKER_01] It's a simple app, but it does a lot of complex stuff. It hides away a lot of complexity to the user. [SPEAKER_02] And there's the other one, which is your very shallow app, which is tons of things you can do, but there's not that much complexity. [SPEAKER_02] If it's a shallow app and it requires a lot of customization from you, then you just build it. [SPEAKER_02] That's probably actually the right thing to do. [SPEAKER_02] If it's a very deep one, there's just too much stuff for you to build and it's not viable for you to do. We mentioned PMs and their proximity to customers and then that delivery mechanism back to engineering, which is what PMs did and did best. [SPEAKER_01] Does the role of the PM change in the next few years? Yes and no. I think there are certain people, or a lot of people are saying that product and engineering are converging. It's becoming one thing. One person can do the product work and build the system and ship it and everything. And I think for some companies, that's true. I think for companies where you really need PMs, it's not true. Or it can be true, but it's inefficient. And I'll tell you why. So we were talking about product. You do the product work first, the scoping, and then you build it and then you ship it and you review it. And in a company like Legora, we're always focused on the bottleneck and the bottleneck is no longer coding, which means the bottleneck is the product work. And so you don't want your product people to do engineering. Because the opportunity cost of that is really high, because what you really want them to do is the product work. Talking to customers, figuring out, doing the synthesis, that's the bottleneck. So if your PMs are coding a lot, if they're spending 50% of their time coding, we're missing out on so much product work. [SPEAKER_02] So that's how I think about it right now. [SPEAKER_02] And for certain companies, if you're doing developer tooling or doing consumer-aware engineers intrinsically have a good sense for their own or there are their own clients, you maybe don't need a PM at all. [SPEAKER_02] But I think you haven't needed a PM before AI either there. So I don't think that changes with and without AI. [SPEAKER_01] PMs can now do engineering that changes with AI. But it's not always efficient to do it. [SPEAKER_01] It's a matter of opportunity cost. And there's handover cost, which is if I do all the product work and then I give a PRD and I give it to an engineer, then you lose efficiency there. So it's good if PMs do some amount of coding to show very high fidelity. Here's a prototype. This is exactly what it looks like. [SPEAKER_01] To reduce the handover cost. Exactly. [SPEAKER_01] Yeah, exactly. [SPEAKER_01] But they shouldn't spend a lot of their time engineering because if they just focus on actual engineering, we lose out on the product work. [SPEAKER_01] I'm your little brother coming out of CS at university. [SPEAKER_01] What would you advise me to be best placed in the next three to ten years? [SPEAKER_01] So if I were to advise someone on social media marketing, I'd say, hey, you need to be full stack. [SPEAKER_01] You need to be able to create the image, get it out, and amplify. Yeah. Similar thing. I think engineers, I think actually the most important thing is you need to learn how to learn. You need to figure out how you constantly reinvent yourself and keep learning and improve because things change all the time right now. It's every week. There's something new you should be doing. You need to change your way of working or whatever. And the most important thing that you can do for yourself is figure out how you keep at the forefront of what's happening all the time. And if you can do that, if you're adaptable enough and you are ambitious enough, then the rest works out. Because if you can just learn faster than everyone else, then over time, you win. [SPEAKER_01] To what extent does the quality of Lagora as a product depend on the quality of the underlying models? It's not as much as most people think. The value of Lagora is there's so much more around it, whether it's the primitives that make sense for legal and make it more efficient to work with AI, or it's all the enterprise-y features, or it's the optimal routing between models. We wouldn't exist without the models. And every time the models become better, our product becomes better, our agent becomes better. Because if you can just learn faster than everyone else, then over time, you win. [SPEAKER_01] To what extent does the quality of Lagora as a product depend on the quality of the underlying models? It's not as much as most people think. The value of Lagora is there's so much more around it, whether it's the primitives that make sense for legal and make it more efficient to work with AI, or it's all the enterprise-y features, or it's the optimal routing between models. We wouldn't exist without the models. And every time the models become better, our product becomes better, our agent becomes better. But let's say you took away a model from Lagora, people would still pick Lagora. So they don't buy it based on the model. [SPEAKER_01] Totally get that. How has model usage changed for you over time? [SPEAKER_02] It changes a lot. The best model changes bi-weekly, almost, right? We've been between OpenAI and Anthropic. We keep evaluating all the different models. [SPEAKER_01] Do you use 15 at the same time for different tasks? We, not 15, but maybe 10. Yeah. So for each task, we will evaluate what model is best at this. Latency, performance, not so much cost. Eventually, it will be cost, but latency and performance is most important. Performance needs to be here. How much can we increase latency without dropping in performance? And so by building our agent and our other AI features in a way that you can decompose the problem, you can use really efficient models. [SPEAKER_01] You can have latency or performance at the fastest, but it may not be the best output, or slower, but great output. Yes. Yeah. Which one? And I have to choose. Yeah. Almost always performance. Performance is more important. Almost always. If you're a lawyer, you can wait two seconds more for the output if it's better. You can probably wait an hour more for the output if it's better. [SPEAKER_01] What do you think about the future of open source as we move more and more to a focus on cost? [SPEAKER_02] I think open source is having a great moment. It really, really is. There's so many great open source models now, and they're really easy to run. There's great inference providers that let you run really efficiently. We are moving very close to being able to do things on device. Transcription can run on device, it can run on my iPhone. I have local transcription on my Mac. I have, when I do flights and there's no Wi-Fi, I have local models running, so I can keep coding. But it's just a Codex model that runs and helps me code. So I think open source is going to play a huge role. I hope it continues to evolve the way that it currently is. And I think it's an important thing that we have open source models for sovereignty reasons and for security reasons. We should have great open source models. Can I ask, what worries you today? [SPEAKER_02] A lot of people are worried about open source Chinese models, which is what I was thinking about. More broadly, what worries you when you look at the landscape that we've discussed? I really hope to see European and American open source models. They've been lacking. And I think it would be really good to have some. I think game theoretically, we won't end up in a great place if there's a duopoly or a monopoly on the models for obvious reasons. You do want to have some competition. You want to have them. Does Europe have any place to play in the model race today? [SPEAKER_02] It should, but it doesn't yet. [SPEAKER_01] How far do you think are we in the efficiency frontier on training? Are we 1% of the way there? Or is it like we're 90% and we might eke out a little bit more? That's a great question. One thing is the current architecture. How long does that plateau? Do we need something new? There's one model release two days ago that's subquadratic, which is huge context length. [SPEAKER_01] That's super exciting. I don't know if I trust the benchmarks yet. [SPEAKER_01] How far do you think we are on the efficiency frontier on training? Are we 1% of the way there? [SPEAKER_01] Or are we 90% and we might eke out a little bit more? That's a great question. One thing is the current architecture. How long does that plateau? Do we need something new? There's one model release two days ago that's subquadratic, which is huge context length. [SPEAKER_01] That's super exciting. I don't know if I trust the benchmarks yet. [SPEAKER_01] We need to validate that. But there's architectural innovations going on still. And I don't know, maybe the current LLM architecture is not the one to take us all the way. [SPEAKER_01] Can I ask, what role does not exist today that you think will be very common in five years time? [SPEAKER_02] I think the internal AI systems role for enterprises. I think IT can have a flowering moment here and go from being internal IT that's setting up your computers to having a system team that's building tons of internal tools that just make your life so much easier. [SPEAKER_02] I think there's that. If enterprises don't create that role, I will get really annoyed because there's so much efficiency to gain there. [SPEAKER_02] [SPEAKER_01] Really getting into the enterprise and having all of that for them. Do you have to have FDs to have usage in enterprise? [SPEAKER_01] You work with relatively sticky lawyers. [SPEAKER_01] [SPEAKER_02] Yeah, yeah, yeah. [SPEAKER_01] Do you have to have people show them, here you go, here you go? [SPEAKER_01] [SPEAKER_02] We currently do, yeah. But I think that's just an education thing. In five years, maybe we don't at all, to be honest. But that's the price you pay for being on the forefront. You have to educate and you have to help. And that's why people want to work with us also. [SPEAKER_01] We take them for the ride. [SPEAKER_01] Are you ready for an unfair one? [SPEAKER_02] Yes. [SPEAKER_02] [SPEAKER_01] What have Harvey done better than you from a product perspective or an engineering perspective? I don't know. I think they've been more aggressive with hiring, which I actually think I have not been aggressive enough with hiring. Because I've always tried to have a very, very small, very lean team, which I believed a lot in. And I consistently underestimated how many people we need. I had this slide that I drew up maybe a year and a half ago that I showed the entire company and it was the 300 Spartans versus the Persians. And it was Leonidas and the 300 Spartans. And I said, I'm pretty sure I said we will cap out at 20 engineers or something like that, which is way undershooting it. [SPEAKER_01] How many engineers do you have today? Today we are about 80. [SPEAKER_01] You got that wrong on 20, didn't you? [SPEAKER_01] [SPEAKER_02] Yeah, I got that really wrong. [SPEAKER_01] And we're way too small still. As a result of being too small, you are too slow or you're not able to build what you want to build? [SPEAKER_01] [SPEAKER_02] Second. There's loads of features that you can staff a team to build. Can you ramp as quickly as you need to and retain quality? Yes. We're really good at this. How? [SPEAKER_01] [SPEAKER_02] First, we're extremely selective with hiring. Maybe that's also why we're slower at hiring. So we hire really great people and the ramp up time is extremely fast. [SPEAKER_01] How do you make ramp really fast? As specifically as possible, anything that you do? [SPEAKER_01] [SPEAKER_02] I can tell you what we probably should do. Because the reality is things move really fast. You need to have a developer experience team, relatively new. Again, a mistake I made, I should have staffed that earlier. And they are making everyone's life so good. [SPEAKER_01] What do they do? [SPEAKER_01] [SPEAKER_02] So they make sure that our local development setup works really, really well. It's super fast. It spins up really quickly. We have our own background coding agent that they built that allows each engineer to have 10 different agents running concurrently with all of our local development, a browser, all the iteration stuff. They're building custom review agents. They're building features so that it can wait and see and wait until everything looks green and all the reviews are good and then raise it to a human. So the efficiency gains there are huge. And they will then also build tooling that helps onboard people. And so it can be like, make sure that you have really good readme files in your repository so that a new engineer will ask their code or their cursor about all their questions. That's remarkably effective. So it's just like, even AI tooling makes it faster to ramp. [SPEAKER_01] How many do you have in developer experience and when do you think you should have done it? We have three people now, which is too few. I should have done it when Opus 4.5 came out, I think, because that's when I should have done it before that. But then the productivity of each engineer is next, I say. And so if you can make everyone 20% more efficient, it's even more gains. [SPEAKER_02] [SPEAKER_01] How does hiring engineers in Europe differ to hiring in the US? [SPEAKER_02] There's a few different ways that it differs. In the US, people are generally less risk averse. So they'll be ready to jump on a lot of things to test. I think in Europe, people are more risk averse. People in Europe, and I'm super generalizing now, but I think generally they're really bought into the company that they work for and work with. So it takes a lot of time to convince them. But once they're convinced, they really stay. And that's great. [SPEAKER_02] [SPEAKER_01] And the US is more transactional? [SPEAKER_02] I think so. [SPEAKER_02] [SPEAKER_01] Yeah. Do you find the attachment to equity different? [SPEAKER_02] It's actually something that we had to educate people on in Sweden. And in Europe, I think people are just not used to the venture thing. They don't know how to value equity the same way. You have to really, this is how it works. This is what it means. These are the, if this happens, then you get this much money. But you don't get it in cash. It's not like— [SPEAKER_01] Yeah, exactly. And then there's tax. I do it with our team and they're like, wait a minute, you're giving me half a million dollars? Exactly. Not literally, but in the future. In a way, yeah, exactly. I think so. [SPEAKER_01] Yeah. Do you find the attachment to equity different? It's actually something that we had to educate people on in Sweden. And in Europe, I think people are just not used to the venture thing. They don't know how to value equity the same way. You have to really, this is how it works. This is what it means. These are the, if this happens, then you get this much money. But you don't get it in cash. It's not— [SPEAKER_01] Yeah, exactly. And then there's tax. I do it with our team and they're like, wait a minute, you're giving me half a million dollars? Exactly. Not literally, but in the future. In a way, yeah, exactly. So that's been a little bit difficult for us, right? But I think it's part of just creating the ecosystem. In 10 years, the next startup that comes out of Stockholm hopefully won't have this problem. [SPEAKER_01] Totally get that. Can I ask, everyone is encouraged to use as many tokens as possible. I'm on the board of public companies and they're like, I'm hearing about token maxing. Oh yes. What do you advise a CEO in terms of intelligent usage of AI? And should we just be pushing tokens as much as possible? Or do we need to pump the brakes a little bit here? So a few different things on that. I think one, having a leaderboard. A lot of people say this, get a leaderboard and bring up token users at performance reviews and that leads to token maxing, which is people just burn tokens just to look good. That's a really stupid way to do anything. Do hack days, do demos, have people show everyone else how efficient they are and how much better they're doing and reward them for being effective and efficient and having more output, not for necessarily using AI, but AI will be the way there. I think that's one of the points. For enterprises, this is where I think Cursor has a reason to live, a reason to exist, which is if your options are Codex and Claude Code and a neutral third party and you all pay consumption based, Cursor can help you optimize your token spend because they can optimize your usage, right? They can route them to the cheap open source model or help you set limits for whatever models you want to use for what thing. Can they now post acquisition by Grok? [SPEAKER_01] Well, we'll have to see if they force work on everyone. I respectfully disagree and that's why I actually think both Cognition and Factory will do very well because they're model independent. Okay, because you think now that they're tied to X? [SPEAKER_02] A hundred percent. Yeah. I was a bit surprised actually with the acquisition. I was a bit surprised and a bit sad to see it. [SPEAKER_02] Why? Because I thought that they could, if they stayed independent, they had a really cool story. But I mean, I see the synergies. Obviously, they don't have enough compute. They can't train their own models. They probably have to train their own models. It's, I just think it's a shame that the industry is vertically integrated in that way. Do you think IDE is dead? [SPEAKER_01] The current shape of an IDE will die, yes. I think I don't know what the new, the next IDE is, but it's not reading lines of code. It's, maybe it's graphical, honestly. Maybe it's the systems, the architecture that you look at and you review and you plan it there and then agents run off and make sure that whatever you're planning actually is what's being made. I don't know what it looks like, but I don't think it's lines of code. What percent of developer salary would you be willing to spend on AI tooling for them? [SPEAKER_01] I don't want to say infinite, but for me it's a question of opportunity cost. So we're in a competitive environment. Are you? Yeah. You wouldn't. No way. I didn't know that. There's fascinating. I know. There's so much, so many things that we can do and the cost of not doing it is extremely high and it almost outweighs any sort of token cost. Any efficiency gain is worth so much to us and it's not that's for us, but for certain companies that will look different, right? So I think it's, the budget on tokens is mostly a question of opportunity cost. Is it worth us spending a ton of tokens to learn if it maybe gives us 20% efficiency? For us, yes. We have a really high opportunity cost. What did you do that you wish you hadn't done? Not investing in developer experience fast enough, definitely a problem. Underestimating our growth, also a problem. Now I make sure everything we build will scale to 100x the usage. [SPEAKER_01] I used to say 10x and then that was not enough so now everything needs to scale to 100x. What changes when you're building for 100x versus 10x? I'm sorry, I'm very naive. [SPEAKER_01] No, that's not naive at all. It doesn't always have to change but there are certain limits that you often will put in place. Just be, yeah, this probably is good enough for the next three months. If we bound the problem in this way which is maybe 10x then we can do x, y, z but maybe that doesn't hold if you're 100x. And so sometimes you need to think about particular problems where there's burstiness to it. So Tabular Review is one of our products where you can bulk extract from many documents and many cells. And there's a very big difference between 10,000 cells and 100,000 cells on the load of the system because it spikes immediately. And so that's one of those systems where there's actually a difference. And so what do you do in that case where the spike is so immensely different? [SPEAKER_01] Yeah, what does that mean you subsequently do differently? We have to think about the experience if 10 people do that crazy thing at the same time and we still have a bunch of other users that we want to have a good experience. So we need to think about fair queuing, which is, okay, if you're running 100,000 cells you're probably okay waiting a bit. You can go grab a coffee and that's fine but if you run 10 cells at the same time those should be really fast. Totally get you. If I ask a really unfair one: if I gave you access to a superior model for six months ahead of anyone else or superior engineers for six months ahead of anyone else, which would you rather have? [SPEAKER_01] Engineers. For sure. Because the models they change all the time. They get better all the time, but if you have really good engineers you can build a system that exponentially improves and that's worth a lot more. What do you know now that you wish you'd known when you started day one? [SPEAKER_01] Honestly, wish I'd known how quickly we were going to scale because that was the thing that I underestimated all the time. I don't think I was ready for this journey. I became ready really quickly because I got slapped in the face every three months. Do you buy that people are destined for certain stages of companies? I'm getting very personal. If I was you now I'd have in my mind: am I the CTO that takes this to public company? [SPEAKER_01] Do you buy that people are destined for certain stages of companies? I'm getting very personal. If I was you now I'd have in my mind: am I the CTO that takes this to public company? Honestly, wish I'd known how quickly we were going to scale because that was the thing that I underestimated all the time. I don't think I was ready for this journey. I became ready really quickly because I got slapped in the face every three months. [SPEAKER_01] Do you buy that people are destined for certain stages of companies? I'm getting very personal. If I was you now I'd have in my mind: am I the CTO that takes this to public company? It's a very fair question. Do I know? I don't buy that. I think to me it's a question of how quickly can I solve problems? Am I the person that can solve the problems that we have right now the fastest or can someone else solve them faster than me? We have a great culture in Ligora in that no one has any ego. I've told this to I currently have two engineering directors. I've told both of them when I hired if there comes a day when I think you'll do better than I will then we swap or I do something else. I have very little and they also have very little tied into their title or their role. We are here to build something huge and that's the most important thing and I continuously evaluate myself on my job performance and if I don't do well I try to rectify that really quickly and I haven't been able to not rectify it yet but maybe there comes a day. [SPEAKER_01] What's the secret to hiring the best engineers with no ego and how obvious are they? They're obvious. If they have ego you can even just when you negotiate salaries and titles you can tell. [SPEAKER_01] I don't know about you. I always say great people want more money. They don't mind so much about the title. I think that's right. [SPEAKER_01] I think that's absolutely right and I only most of the people that we hire we don't even talk about their title. We talk about the difficult problems that they're going to work on. [SPEAKER_02] How important is it that you're together in Stockholm? It's been very important for running really fast. This is we talked about the handover cost if you have a PM and a designer and an engineer and they just sit together you can almost not even have the handover you can just be like run at this problem and do it together the three of you. Next week and then it's done but if you have them siloed and there's handover in between you lose so much efficiency. [SPEAKER_02] Jump on a zoom. Cool. Lacking clarity. Yeah, this doc is not well written enough. You have to do another meeting and then you have to do three reviews of the document and then someone else has an opinion that sees it somewhere and writes a comment somewhere and then you have to talk about that. How do you factor that into how the best engineers prefer to be remote? Well, we're very opinionated about who we are and who we aren't. If you're a great engineer and you want to be remote then you probably also want to work on very isolated problems and that's that can be fine. We probably have those and we probably will have those but they're not for us right now. We'd rather find the people that want to solve the same problems with other people. [SPEAKER_01] How many engineers were you having two years or by the end of 2027? You're 80 today. Yeah. [SPEAKER_01] I'm going to say a number that's too low. I'm going to WhatsApp it to you on the 31st of December 2027. Were you wrong? Yeah. [SPEAKER_01] I don't know. 300 maybe? 200? [SPEAKER_01] 200 and 300 are different. You gotta put your name on one. If I have to put my name on one—I want to say the lower number. Let's say 270. [SPEAKER_01] 270. Okay so we're going to have 190 more. [SPEAKER_01] Yeah. Can you retain A only talent with 190 more? That's essentially adding two and a half a week. [SPEAKER_01] Yeah. Is that possible? If it's linear, I think so. I'd rather miss my number and have A players than hit it with B players. Because I think as soon as you introduce B players, as soon as you have people that you don't trust or that the team doesn't trust, the A players won't stick around. You're buying more companies than I'm doing podcasts these days. And you're laughing because it's true. It's not true. I'm essentially an investor now. My question to you is: do you have to buy companies to get the truly, truly A talent in a lot of cases? [SPEAKER_02] I don't think so, but it's faster. That's essentially why. Because if you find a really good founder, they're able to attract really good talent. And so you have a small group of five people that are A talent and then you get five in one week. If you have to get two every week, that's much faster than going to all the big companies or even the startups and trying to convince them to come over. People also, if you have a small startup of five, eight people, they want to work with each other. Do you just shed their code bases then, or is it pure acquisitions in a lot of cases? [SPEAKER_02] It can be both. If they've worked on adjacent things or think it's in a similar field or even unrelated but similar technology, we'll take all their learnings and we might rebuild it into Lagora. I think that's what happens in most cases, but they become fully embedded into the team. They're all Lagorians working on the Lagora code base and then they might bring some learnings. Is integration hard? [SPEAKER_02] No. It's surprisingly easy if you hire people with low ego. That's the thing. If you get five great engineers that don't care about their titles or where they sit in the org chart, that just want to solve problems, it's surprisingly easy to integrate. When you've got engineering hires wrong, what did you not see that you wish you had seen? No. It's surprisingly easy if you hire people with low ego. That's the thing. If you get five great engineers that don't care about their titles or where they sit in the org chart, that just want to solve problems, it's surprisingly easy to integrate. Is integration hard? [SPEAKER_01] No. It's surprisingly easy if you hire people with low ego. That's the thing. If you get five great engineers that don't care about their titles or where they sit in the org chart, that just want to solve problems, it's surprisingly easy to integrate. When you've got engineering hires wrong, what did you not see that you wish you had seen? [SPEAKER_01] So typically when this goes wrong, it's actually because of me—I'm going to be a little bit introspective here—it's probably because of my own. Because I don't have—I've not run an engineering team this big before, and so I start second-guessing. I'm not confident enough in saying this person who's more senior than me has seen more than me is wrong. And so it's happened once or twice when there's a very senior person and we talk and they talk about all this org building and org design and how they think about all this stuff. And I sense that something's wrong and I kind of know that all the time, but in the end I end up convincing myself that no they probably know more than me or they figured it out or whatever. And then two weeks in, four weeks in, six weeks in, you start to figure out they didn't. How fast do you know if you've made a mis-hire? [SPEAKER_01] A month, then you know. And then you give them really strong feedback. I give really strong feedback after two weeks. What does really strong feedback mean? [SPEAKER_01] Really strong means you're not going to stay if you don't change this, and feedback is feedback. Has anyone ever recovered from a "you're not going to stay if you don't change this"? [SPEAKER_01] No, but they need to get the chance. And if they do, they stay. What is the hardest role to hire for today? [SPEAKER_01] I think senior management is extremely difficult to hire for. Senior management, horizontal senior management. Engineering directors within product and engineering? [SPEAKER_01] Yeah. Maybe that's always been difficult, but I think it's because we only have really technical people also being managers. And so anyone who's seen scale typically also is no longer technical. Do we still have managers? And what I mean by that is one of my dear friends Jason Lemkin from Stashy is say anyone on LinkedIn who talks about their team, fire them straight away. We don't want managers who manage other managers who manage those managers. If you can't do full stack, get out, pick up your severance and go away. Do we still want senior managers? [SPEAKER_01] It really depends. You can build a company of super senior engineers. They can do everything and you probably don't need to manage them at all, especially if there's really strong alignment—if they know what they're trying to achieve. The Codex team, for example, they all know what they're building. They can just run at it and they don't need anyone to tell them that they're doing well. But if you have a more complex product that can go in many directions and you have to do constant prioritization with a suite of engineers and a team of engineers—so the way that we have engineering teams is relatively small teams, let's say six people, a PM, and an engineering manager. The engineering manager is super technical. They spend most of their time coding. They're not people who hold each other's hands and sing songs, but it's still important that I have someone that's accountable to the team health. Are people doing good jobs? Are people having fun? I can't walk around and judge everyone—are they doing well? So I think it's important to have someone who's accountable, and that's how we run it. They decide their own roadmap. They're their own little startup, but one person is accountable. Is Max on every new product feature? [SPEAKER_01] On big ones, yes. On small ones, no. Is that right? [SPEAKER_01] It's worked for us so far. It's worked great. His time—Max is an amazing salesman, which you'll probably know—and so I think Max spends his time on that and he spends his time on product vision and the important product things. So big launches, big things—he's involved early and for the duration of the project. But for small things, that's why you hire great people is that you can let them do this. [SPEAKER_02] And so that's the thing with Max. He's a specialist. He so believes what he says. Often when you're being sold, you know you're being sold to. Yeah. [SPEAKER_02] No, no. There is no way that he sees himself being wrong in his bones. Absolutely. Absolutely. And also, I think that was brilliant. We naturally hate them because they're shit, but Sifted did that piece with the taste of blood. [SPEAKER_01] Yeah. Did everyone in Lagora just go, "Oh my god"? [SPEAKER_01] Yeah. That's hilarious. Yeah, yeah. There's screensavers now that say "blood smug" on it. [SPEAKER_01] It's becoming this internal thing. Did you guys like the Jude lore? [SPEAKER_01] I loved it. I've sat on that secret for nine months. Did you think it was done well? [SPEAKER_01] I think so, yeah. Yeah. [SPEAKER_01] What—you asked if it was not done well. I think the Jude lore idea was great. Did it do well for you guys, do you think? Amazingly well. No, crazy well. [SPEAKER_01] Yeah, it's wild. Yeah, people see it everywhere, which is great. People talk about it a lot. [SPEAKER_01] Which is the goal of the campaign, right? We need to get everyone talking about us. Dude, we're gonna do a quickfire round. So I say a short statement, you give me your immediate thoughts. Does that sound okay? Yeah, let's do it. [SPEAKER_01] What have you changed your mind on most in the last 12 months? [SPEAKER_02] Hiring. Hiring? [SPEAKER_02] Yeah. We need to hire more. As long as adding someone is net positive, we should add someone. What's the most underrated AI company today, do you think? [SPEAKER_02] Lagora. Dude, I'm an ambassador and even I'm like, no shit, dude. You're gonna give me another one? I had to say it. I don't know. There's loads. One for me would be Whisper Flow—the pain of removing Whisper Flow for me is immense. [SPEAKER_02] Whisper Flow is great. I think we're gonna get more local models though. Whisper Flow is not local. You're probably gonna get a similar Whisper Flow. Well, maybe they should just go local, but the tool itself is great. Finish this sentence: the biggest threat to Lagora is not Harvey, but— Lagora. [SPEAKER_01] What's the most underrated AI company today, do you think? Lagora. [SPEAKER_01] Dude, I'm an ambassador and even I'm saying no shit, dude. You're gonna give me another one? I had to say it. I don't know. There's loads. One for me would be Whisper Flow—the pain of removing Whisper Flow for me is immense. Whisper Flow is great. I think we're gonna get more local models though. Whisper Flow is not local. [SPEAKER_01] You're probably gonna get a similar Whisper Flow. Well, maybe they should just go local, but the tool itself is great. Finish this sentence: the biggest threat to Lagora is not Harvey, but— The thing that's gonna kill us is if we don't keep reinventing ourselves. This sounds really boring, but I think we talk a lot about staying in our swim lane, focusing on our product and our users, and the entire environment is moving so much. If you had me on this podcast a year ago, it would have been very different. So I think the main thing that's gonna kill us is if we lose the ability to constantly react and readjust and reinvent ourselves. [SPEAKER_01] You just worked with Jude Law in terms of brand campaigns. What sports team would you most like to see Lagora across? Could be F1, could be football, could be NBA? F1 would be great. I'm a big fan. F1 would be awesome strategically. [SPEAKER_01] Would that be awesome? You do golf? We do golf. The Yankees we sponsor in New York, which is also great. [SPEAKER_01] You sponsor the Yankees? Yeah. You didn't know this? Aaron Judge. [SPEAKER_01] How much does that cost? That I can't tell you. But the team that I would want us to sponsor is my local FC Copenhagen football club. That would be a childhood dream. They're doing really bad right now though, so it's probably really cheap, actually. It's called exposure. [SPEAKER_02] [SPEAKER_01] You would get nil. [SPEAKER_02] Let's do it. [SPEAKER_02] [SPEAKER_01] I mean the Champions League? No. Europa League? No. They're not even top of the Danish league. [SPEAKER_02] Yeah. [SPEAKER_00] You know, you should be CTO probably. Cheap. [SPEAKER_01] Yeah, no, I know. It's okay. What is one thing you believe about the future of law that most people would say is crazy? If I had to get crazy, I think there's lots of analogies to coding. I think in law it's very text-based. The agent AI features are similar. If I believe that in coding we're going to look less at source code and more at one layer above, I have to say the same thing about law. Eventually, lawyers will not be nitty-gritty about the language of the contracts. They will work a level above, which is maybe what's our negotiation stance? What risks are we okay with? Which ones are we not okay taking? And not sit and type into Word. I'm not sure if this is true, but this is my hunch that it's going in this direction, and that's the crazy thing if it has to be. [SPEAKER_01] Lawyers' processes. Now I'm just wow. You seem to have done 100 NDAs. Why are we writing it fresh? This feels like a solved problem. [SPEAKER_01] What's the biggest advice to a founder competing in a business industry where there is an 800-pound gorilla? Honestly, just work harder than the 800-pound gorilla. I think people underestimate this. No one in the 800-pound gorilla is extremely excited to be there. I think if you're competing against Google, the PM at Google that you're competing against does not give a shit if it goes well or not. Maybe she tries really hard, but I don't think if you're a small lean team and you work really hard, you can do remarkable things. You ready for a bet? [SPEAKER_01] Yes. What are we going to end the year at revenue-wise? It's going to be above 250. I'm going to 272. [SPEAKER_01] 272? Yeah. I think it's going to be above that too. I don't want to... David's going to call me really mad soon. Dude, this has been such a pleasure. I've loved having you and you've been fantastic. [SPEAKER_00] Thank you. Or help you set limits for whatever models you want to use for what thing. Well, can they now post acquisition by Grok? Well, we'll have to see if they force work on everyone. [SPEAKER_01] I respectfully disagree and that's why I actually think both Cognition and Factory will do very well because they're model independent. But if you do. Because you think now that they're tied to X? A hundred percent. Yeah. I was a bit surprised actually with the acquisition. I was a bit surprised and a bit sad to see the acquisition. [SPEAKER_01] Why? Because I thought that they could, if they stayed independent, they had a really cool story. But I mean, I see the synergies. Obviously, they don't have enough compute. They can't train their own models. They probably have to train their own models. It's—I just think it's a shame that the industry is vertically integrated in that way. [SPEAKER_01] Do you think IDE is a dad? The current shape of an IDE will die, yes. I think I don't know what the new IDE is, but it's not reading lines of code. It's maybe graphical, honestly. Maybe it's the systems, the architecture that you look at and you review and you plan it there and then agents run off and make sure that whatever you're planning actually is what's being made. I don't know what it looks like, but I don't think it's lines of code. [SPEAKER_01] What percent of developer salary would you be willing to spend on AI tooling for them? I don't want to say infinite, but for me it's a question of opportunity cost. So we're in a competitive environment. Are you? The current shape of an IDE will die, yes. I think we, I don't know what the new, the next IDE is, but it's not reading lines of code. It's maybe it's graphical, honestly. Maybe it's the systems, the architecture that you look at and you review and you plan it there and then agents run off and make sure that whatever you're planning actually is what's being made. I don't know what it looks like, but I don't think it's lines of code. [SPEAKER_01] What percent of developer salary would you be willing to spend on AI tooling for them? I don't want to say infinite, but for me it's a question of opportunity cost. So we're in a competitive environment. Are you? [SPEAKER_01] Yeah. You wouldn't, no way. I didn't know that. There's fascinating. I know. There's so much, so many things that we can do and the cost of not doing it is extremely high and it almost outweighs any sort of token cost. Any efficiency gain is worth so much to us and it's not, that's for us, but for certain companies that will look different, right? So I think it's, the budget on tokens is mostly a question of opportunity cost. Is it worth us spending a ton of tokens to learn if it maybe gives us 20% efficiency? For us, yes. We have a really high opportunity cost. [SPEAKER_01] What did you do that you wish you hadn't done? Not investing in developer experience fast enough, definitely a problem. Underestimating our growth, also a problem. Now I make sure everything we build will scale to 100x the usage. I used to say 10x and then that was not enough so now everything needs to scale to 100x. [SPEAKER_01] What changes when you're building for 100x versus 10x? I'm sorry, I'm very naive. No, that's not naive at all. It doesn't always have to change but there are certain limits that you often will put in place. Just be, yeah, this probably is good enough for the next three months. If we bound the problem in this way which is maybe 10x then we can do x, y, z but maybe that doesn't hold if you're 100x. And so sometimes you need to think about particular problems where there's burstiness to it. So Tabular Review is one of our products where you can bulk extract from many documents and many cells. And there's a very big difference between 10,000 cells and 100,000 cells just on the load of the system because it spikes immediately. And so that's one of those systems where there's actually a difference. And so what do you do in that case where the spike is so immensely different? [SPEAKER_02] We have to think about the experience if 10 people do that crazy thing at the same time and we still have a bunch of other users that we want to have a good experience. So we need to think about fair queuing basically which is, okay, if you're running 100,000 cells you're probably okay waiting a bit. You can go grab a coffee and that's fine but if you run 10 cells at the same time those should be really fast. [SPEAKER_01] Totally get you. If I ask a really unfair one, if I gave you access to a superior model for six months ahead of anyone else or superior engineers for six months ahead of anyone else which would you rather have? Engineers. For sure. Because the models, they change all the time, they get better all the time, but if you have really good engineers you can build a system that exponentially improves and that's worth a lot more. What do you know now that you wish you'd known when you started day one? [SPEAKER_02] Honestly, I wish I'd known how quickly we were going to scale, because that was the thing that I underestimated all the time. I don't think I was ready for this journey. I became ready really quickly because I got slapped in the face every three months. [SPEAKER_01] Do you buy that people are destined for certain stages of companies? I'm getting very personal. If I was you now, I'd have in my mind: am I the CTO that takes this to public company? It's a very fair question. Do I know? I don't buy that. I think to me it's a question of how quickly can I solve problems? Am I the person that can solve the problems that we have right now the fastest, or can someone else solve them faster than me? We have a great culture in Ligora in that no one has any ego. I've told this to the two engineering directors I currently have. I've told both of them when I hired: if there comes a day when I think you'll do better than I will, then we swap or I do something else. I have very little, and they also have very little, tied into their title or their role. We are here to build something huge, and that's the most important thing. I continuously evaluate myself on my job performance, and if I don't do well, I try to rectify that really quickly. I haven't been able to not rectify it yet, but maybe there comes a day. What's the secret to hiring the best engineers with no ego and how obvious are they? [SPEAKER_02] They're obvious. If they have ego, you can tell even just when you negotiate salaries and titles. I don't know about you, but I always say great people want more money. They don't mind so much about the title. [SPEAKER_02] I think that's absolutely right, and I only—most of the people that we hire, we don't even talk about their title. We talk about the difficult problems that they're going to work on. How important is it that you're together in Stockholm? [SPEAKER_02] It's been very important for running really fast. I mean, this is—we talked about the handover cost. If you have a PM and a designer and an engineer and they just sit together, you can almost not even have the handover. You can just be: run at this problem and do it together, the three of you, next week, and then it's done. But if you have them siloed and there's handover in between, you lose so much efficiency. Jump on a Zoom. Yeah, this doc is not well written enough, so you have to do another meeting, and then you have to do three reviews of the document, and then someone else has an opinion that sees it somewhere and writes a comment somewhere, and then you have to talk about that. How do you factor that into how the best engineers want to be remote? Well, we're very opinionated about who we are and who we aren't. If you're a great engineer and you want to be remote, then you probably also want to work on very isolated problems, and that can be fine. We probably have those and we probably will have those, but they're not for us right now. We'd rather find the people that want to solve the same problems with other people. [SPEAKER_01] How many engineers do you think you'll have by the end of 2027? You're 80 today. [SPEAKER_01] I'm going to say a number that's too low. I'm going to WhatsApp it to you on the 31st. [SPEAKER_01] [SPEAKER_02] Well, we're very opinionated about who we are and who we aren't. If you're a great engineer and you want to be remote, then you probably also want to work on very isolated problems, and that can be fine. We probably have those and we probably will have those, but they're not for us right now. We'd rather find the people that want to solve the same problems with other people. [SPEAKER_01] How many engineers were you having two years, or by the end of 2027? [SPEAKER_01] You're 80 today. Yeah. [SPEAKER_01] I'm going to say a number that's too low. I'm going to WhatsApp it to you on the 31st of December 2027. Were you wrong? Yeah. [SPEAKER_01] I don't know, 300 maybe? 200? [SPEAKER_01] 200 and 300 are different. You gotta put your name on one. If I have to put my name on one, I want to say the lower number. Let's say 270. [SPEAKER_01] Okay, so we're going to have 190 more. Yeah. [SPEAKER_01] Can you retain A-only talent with 190 more? That's essentially adding two and a half a week. [SPEAKER_02] Yeah. Is that possible? If it's linear, I think so. I'd rather miss my number and have A players than hit it with B players. Because I think as soon as you introduce B players, as soon as you have people that you don't trust or that the team doesn't trust, the A players won't stick around. You're buying more companies than I'm doing podcasts these days. And you're laughing because it's true. [SPEAKER_02] It's not true. I'm essentially an investor now. My question to you is: do you have to buy companies to get the truly A talent in a lot of cases? I don't think so, but it's faster. That's essentially why. Because if you find a really good founder, they're able to attract really good talent. And so you have a small group of five people that are A talent, and then you get five in one week. If you have to get two every week, that's much faster than going to all the big companies or even the startups and trying to convince them to come over. People also want to work together: if you have a small startup of five, eight people, they want to work with each other. [SPEAKER_01] Do you just shed their code bases then, or is it pure acquihires in a lot of cases? [SPEAKER_02] It can be both. If they've worked on adjacent things or I think it's in a similar field or even unrelated but similar technology, we'll take all their learnings and we might rebuild it into Lagora. I think that's what happens in most cases, but they become fully embedded into the team. They're all Lagorians working on the Lagora code base and then they might bring some learnings. [SPEAKER_01] Is integration hard? No. It's surprisingly easy if you hire people with low ego. That's the thing. If you get five great engineers that don't care about their titles or where they sit in the org chart, that just want to solve problems, it's surprisingly easy to integrate. [SPEAKER_01] When you've got engineering hires wrong, what did you not see that you wish you had seen? So typically when this goes wrong, it's actually because of me. I'm going to be introspective here. It's probably because of my own insecurities. I don't have experience running an engineering team this big before, and so I start doubting myself. I'm not confident enough in saying this person who's more senior than me, who has seen more than me, is wrong. It's happened once or twice when there's a very senior person and we talk and they talk about all this org building and org design and how they think about all this stuff, and I sense that something's wrong. And I know that all the time, but in the end I end up convincing myself that no, they probably know more than me or they figured it out or whatever. And then two weeks in, four weeks in, six weeks in, you start to figure out they didn't. [SPEAKER_01] How fast do you know if you've made a mis-hire? A month. Then you know. And then you give them really strong feedback. I give really strong feedback after two weeks. [SPEAKER_01] What does really strong feedback mean? Really strong means you're not going to stay if you don't change this. And feedback is feedback. [SPEAKER_01] Has anyone ever recovered from a "you're not going to stay if you don't change this"? No. But they need to get the chance, and if they do, they stay. [SPEAKER_01] What is the hardest role to hire for today? I think senior management is extremely difficult to hire for. Senior management across product and engineering, engineering directors within product and engineering. Yeah, maybe that's always been difficult, but I think it's because we only have really technical people also being managers, and so anyone who's seen scale typically also is no longer technical. Do we still have managers? And what I mean by that is, one of my dear friends Jason Lemkin from SaaStr is like, anyone on LinkedIn who talks about their team, fire them. Fire them straight away. We don't want managers who manage other managers who manage those managers. If you can't do full stack, get out. Pick up your severance and go away. Do we still want senior managers? It really depends. You can build a company of super senior engineers. They can do everything, and you probably don't need to manage them at all, especially if there's really strong clarity, if they know what they're trying to achieve. The Codex team, for example, they all know what they're building. They can just run at it and they don't need anyone to tell them that they're doing well. But if you have a more complex product that can go in many directions and you have to do constant prioritization and you have a suite of engineers and a team of engineers, the way that we have engineering teams is relatively small teams. Let's say six people, a PM, and an engineering manager. The engineering manager is super technical, you know, spend most of their time coding. They're not holding each other's hands and singing songs, but it's still important that I have someone that's... It really depends. You can build a company of super senior engineers. They can do everything, and you probably don't need to manage them at all, especially if there's really strong clarity, if they know what they're trying to achieve. The Codex team, for example, they all know what they're building. They can just run at it and they don't need anyone to tell them that they're doing well. But if you have a more complex product that can go in many directions and you have to do constant prioritization and you have a suite of engineers and a team of engineers, the way that we have engineering teams is relatively small teams. Let's say six people, a PM, and an engineering manager. The engineering manager is super technical, spend most of their time coding. They're not people holding each other's hands and singing songs, but it's still important that I have someone that's accountable to the team health. Are people doing good jobs? Are people having fun? I can't walk around and judge everyone. Are they doing well? And so I think it's important to have someone who's accountable, and that's how we run it. They decide their own roadmap. They're their own little startup, but someone is accountable. Is Max on every new product feature? On big ones, yes. On small ones, no. Is that right? It's worked for us so far. It's worked great. Max is an amazing salesman, which you'll probably know. And so I think Max spends his time on that and he spends his time on product vision and the important product things. So big launches, big things, he's involved early and for the duration of the project, but for small things, that's the reason you hire great people is that you can let them do this. [SPEAKER_01] And so that's the thing with Max is he's a specialist. He so believes what he says. Often when you're being sold, you kind of know you're being sold to. Yeah. [SPEAKER_01] No, no. There is no way that he sees himself being wrong in his bones. Absolutely. [SPEAKER_01] Yeah, absolutely. And also, I think that was brilliant. We naturally hate them because they're shit, but Sifted did that piece with the taste of blood. Yeah. Did everyone in Lagora just go "Oh my God"? Yeah, that's hilarious. [SPEAKER_01] Yeah, yeah. There's screensavers now that say "blood smug" on. It's becoming this internal thing. [SPEAKER_01] Did you guys love the Jude lore? I loved it. I've sat on that secret for like nine months. [SPEAKER_01] Did you think it was done well? I think so, yeah. [SPEAKER_01] Yeah. If it was not done well, I think the Jude lore idea was great. Did it do well for you guys, do you think? [SPEAKER_01] Amazingly well. Crazy well, yeah. It's wild. People see it everywhere, which is great. People talk about it a lot. Which is the goal of the campaign, right? We need to get everyone talking about us. Dude, we're gonna do a quick fire round. So I say a short statement, you give me your immediate thoughts. Does that sound okay? [SPEAKER_01] Yeah, let's do it. So what have you changed your mind on most in the last 12 months? [SPEAKER_01] Hiring. Hiring. Yeah. [SPEAKER_01] Yeah, we need to hire more. As long as adding someone is net positive, we should add someone. What's the most underrated AI company today, do you think? [SPEAKER_01] Lagora. Dude, I'm an ambassador and even I'm like "no shit, dude." You're gonna give me another one? I had to say it. I don't know. There's loads. One for me would be Whisper Flow. Like, the pain of removing Whisper Flow for me is immense. [SPEAKER_01] Whisper Flow is great. I think we're gonna get more local models though. Whisper Flow is not local. You're probably gonna get a similar Whisper Flow. Well, maybe they should just go local, but the tool itself is great. [SPEAKER_01] Finish this sentence: The biggest threat to Lagora is not Harvey, but dot dot dot. The thing that's gonna kill us is if we don't keep reinventing ourselves. This sounds really boring, but I think we talk a lot about staying in our swim lane, focusing on our product and our users, and the entire environment is moving so much. If you had me on this podcast a year ago, it would have been very different. So I think the main thing that's gonna kill us is if we lose the ability to constantly react and readjust and reinvent ourselves. [SPEAKER_01] You just worked with Jude Law in terms of brand campaigns. What sports team would you most like to see Lagora across? Could be F1, could be football, could be NBA? F1 would be great. I'm a big F1 fan. F1 would be awesome strategically. [SPEAKER_01] Would that be awesome? You do golf? We do golf. The Yankees—we sponsor in New York, which is also great. [SPEAKER_01] You sponsor the Yankees? Yeah, you didn't know this? Aaron Judge. [SPEAKER_01] Fucking hell. How much does that cost? That I can't tell you. But I would want, the team that I would want us to sponsor is my local FC Copenhagen football club. That would be a childhood dream. They're doing really bad right now though, so it's probably really cheap actually. It's called exposure. [SPEAKER_01] Yeah. I mean, the Champions League? No, no, Europa League? No, they're not even top of the Danish league. [SPEAKER_01] Yeah. [SPEAKER_00] You know, you should be CTO probably, cheap. [SPEAKER_02] Yeah, no, I know. It's okay. What is one thing you believe about the future of law that most people would say is crazy? [SPEAKER_02] If I had to get crazy, I think there's lots of analogies to coding. I think in law, it's very text-based, and the agent AI features are similar. If I believe that coding, we're going to look less at source code and more at one layer above, I have to say the same thing about law. Like, eventually lawyers will not be nitty-gritty about the language of the contracts. They will work a level above, which is maybe like, what's our negotiation stance? What risks are we okay with, which ones are we not okay taking? And not sit and type into Word. I'm not sure if this is true, but this is. What is one thing you believe about the future of law that most people would say is crazy? If I had to get crazy, I think there's lots of analogies to coding. I think in law, it's very text-based, and the agent AI features are similar. If I believe that coding, we're going to look less at source code and more at one layer above, I have to say the same thing about law. Eventually lawyers will not be nitty-gritty about the language of the contracts. They will work a level above, which is maybe what's our negotiation stance? What risks are we okay with, which ones are we not okay taking? And not sit and type into Word. I'm not sure if this is true, but this is my hunch that it's going this direction. [SPEAKER_01] Lawyers' processes. Now I'm just thinking, wow, you seem to have done 100 NDAs. Why are we writing it fresh? This feels like a solved problem. I'm going to get in so much trouble for this show. What's the biggest advice to a founder competing in a business industry where there is an 800-pound gorilla? Honestly, just work harder than the 800-pound gorilla. I think people underestimate this. The 800-pound gorilla—no one in the 800-pound gorilla is extremely excited to be there. If you're competing against Google, the PM at Google that you're competing against doesn't give a shit if it goes well or not. Maybe she tries really hard, but if you're a small, lean team that works really hard, you can do really remarkable things. [SPEAKER_01] You ready for a bet? [SPEAKER_02] Yes. What are we going to end the year at revenue-wise? [SPEAKER_01] It's going to be above 250. I'm going to 272. 272, yeah. I think it's going to be above that too. [SPEAKER_01] I don't want to get a—I don't know numbers. David's going to call me really mad soon. Dude, this has been such a pleasure. I've loved having you and you've been fantastic. [SPEAKER_00] Thank you. Or help you set limits for whatever models you want to use for what thing. Well, can they now post acquisition by Grok? Well, we'll have to see if they force work on everyone. [SPEAKER_01] I respectfully disagree and that's why I actually think both Cognition and Factory will do very well because they're model independent. But if you do. Because you think now that they're tied to X? [SPEAKER_01] A hundred percent. Yeah. I was a bit surprised actually with the acquisition. I was a bit surprised and a bit sad to see it. Why? [SPEAKER_02] Because I thought that they could, if they stayed independent, they had a really cool story. But I mean, I see the synergies. Obviously, they don't have enough compute. They can't train their own models. They probably have to train their own models. It's, I just think it's a shame that the industry is vertically integrated in that way. Do you think IDE is dead? The current shape of an IDE will die, yes. I think we—I don't know what the new next IDE is, but it's not reading lines of code. It's, maybe it's graphical, honestly. Maybe it's the systems, the architecture that you look at and you review and you plan it there and then agents run off and make sure that whatever you're planning actually is what's being made. I don't know what it looks like, but I don't think it's lines of code. [SPEAKER_01] What percent of developer salary would you be willing to spend on AI tooling for them? I don't want to say infinite, but for me it's a question of opportunity cost. So we're in a competitive environment, you know? [SPEAKER_01] Are you? Yeah. You wouldn't, no way. I didn't know that. There's fascinating. I know. There's so many things that we can do and the cost of not doing it is extremely high and it almost outweighs any sort of token cost. Any efficiency gain is worth so much to us and it's not—that's for us—but for certain companies that will look different, right? So I think the budget on tokens is mostly a question of opportunity cost. Is it worth us spending a ton of tokens to learn if it maybe gives us 20% efficiency? For us, yes. We have a really high opportunity cost. That's for us, but for certain companies that will look different, right? So I think the budget on tokens is mostly a question of opportunity cost. Is it worth us spending a ton of tokens to learn if it maybe gives us 20% efficiency? For us, yes. We have a really high opportunity cost. What did you do that you wish you hadn't done? Not investing in developer experience fast enough, definitely a problem. Underestimating our growth, also a problem. Now I make sure everything we build will scale to 100x the usage. I used to say 10x and then that was not enough, so now everything needs to scale to 100x. [SPEAKER_01] What changes when you're building for 100x versus 10x? I'm sorry, I'm very naive. No, that's not naive at all. It doesn't always have to change but there are certain limits that you often will put in place. Just be like, yeah, this probably is good enough for the next three months. If we bound the problem in this way, which is maybe 10x, then we can do x, y, z. But maybe that doesn't hold if you're 100x. And so sometimes you need to think about particular problems where there's burstiness to it. So Tabular Review is one of our products where you can bulk extract from many documents and many cells. And there's a very big difference between 10,000 cells and 100,000 cells just on the load of the system because it spikes immediately. And so that's one of those systems where there's actually a difference. [SPEAKER_01] And so what do you do in that case where the spike is so immensely different? What does that mean you subsequently do differently? We have to think about the experience if 10 people do that crazy thing at the same time and we still have a bunch of other users that we want to have a good experience. So we need to think about fair queuing, which is like, okay, if you're running 100,000 cells you're probably okay waiting a bit. You can go grab a coffee and that's fine, but if you run 10 cells at the same time those should be really fast. [SPEAKER_01] Totally get you. If I ask a really unfair one: if I gave you access to a superior model for six months ahead of anyone else or superior engineers for six months ahead of anyone else, which would you rather have? Engineers. For sure. Because the models, they change all the time, they get better all the time. But if you have really good engineers, you can build a system that exponentially improves, and that's worth a lot more. [SPEAKER_01] What do you know now that you wish you'd known when you started day one? Honestly, I wish I'd known how quickly we were going to scale because that was the thing that I underestimated all the time. I don't think I was ready for this journey. I became ready really quickly because I got slapped in the face every three months. [SPEAKER_01] Do you buy that people are destined for certain stages of companies? I'm getting very personal. If I was you now I'd have in my mind: am I the CTO that takes this to public company? It's a very fair question. Do I know? I don't buy that. I think to me it's a question of how quickly can I solve problems? Am I the person that can solve the problems that we have right now the fastest, or can someone else solve them faster than me? We have a great culture at Ligora in that no one has any ego. I've told this to my currently two engineering directors. I've told both of them when I hired them, if there comes a day when I think you'll do better than I will, then we swap or I do something else. I have very little, and they also have very little, tied into their title or their role. We are here to build something huge, and that's the most important thing. And I continuously evaluate myself. I've told both of them when I hired if there comes a day when I think you'll do better than I will then we swap or I do something else. I have very little and they also have very little tied into their title or their role. We are here to build something huge and that's the most important thing and I continuously evaluate myself on my job performance and if I don't do well I try to rectify that really quickly and I haven't been able to not rectify it yet but maybe there comes a day. [SPEAKER_01] What's the secret to hiring the best engineers with no ego and how obvious are they? They're obvious. If they have ego you can even just when you negotiate salaries and titles you can tell. [SPEAKER_01] I don't know about you. I always say great people want more money they don't mind so much about the title. [SPEAKER_01] I think that's right. I think that's absolutely right and I only, most of the people that we hire we don't even talk about their title. We talk about the difficult problems that they're going to work on. [SPEAKER_01] How important is it that you're together in Stockholm? It's been very important for running really fast. This is, we talked about the handover cost. If you have a PM and a designer and an engineer and they just sit together you can almost not even have the handover. You can just be run at this problem and do it together, the three of you. Next week and then it's done. But if you have them siloed and there's handover in between you lose so much efficiency. Jump on a zoom. Cool. Lacking clarity. Yeah this doc is not well written enough you have to do another meeting and then you have to do three reviews of the document and then someone else has an opinion and sees it somewhere and writes a comment somewhere and then you have to talk about that. How do you factor that into how the best engineers like to be remote? [SPEAKER_02] Well, we're very opinionated about who we are and who we aren't. If you're a great engineer and you want to be remote then you probably also want to work on very isolated problems and that's that can be fine. We probably have those and we probably will have those but they're not for us right now. We'd rather find the people that want to solve the same problems with other people. How many engineers were you having two years or by the end of 2027? You're 80 today. [SPEAKER_02] Yeah. [SPEAKER_01] I'm going to say a number that's too low. I'm going to WhatsApp it to you on the 31st of December 2027. Were you wrong? Yeah. [SPEAKER_01] I don't know, 300 maybe? 200? [SPEAKER_01] 200 and 300 are different. You gotta put your name on one. If I have to put my, I want to say the lower number. Let's say 270. 270. [SPEAKER_01] Okay so we're going to have 190 more. Yeah. [SPEAKER_01] Can you retain only talent with 190 more? That's essentially adding two and a half a week. Yeah. Is that possible? If it's linear. I think so. I'd rather miss my number and have A players than hit it with B players. Because I think as soon as you introduce B players, as soon as you have people that you don't trust or that the team doesn't trust, the A players won't stick around. [SPEAKER_01] You're buying more companies than I'm doing podcasts these days. And you're laughing because it's true. It's not true. I'm essentially an investor now. [SPEAKER_01] My question to you is do you have to buy companies to get the truly, truly A talent in a lot of cases? I don't think so but it's faster. won't stick around. [SPEAKER_01] You're buying more companies than I'm doing podcasts these days. And you're laughing because it's true. It's not true. I'm essentially an investor now. My question to you is do you have to buy companies to get the truly, truly A talent in a lot of cases? I don't think so. [SPEAKER_02] But it's faster. [SPEAKER_02] That's essentially why. [SPEAKER_02] Because if you find a really good founder, they're able to attract really good talent. [SPEAKER_02] And so you have a small group of five people that are just A talent, and then you get five in one week. [SPEAKER_02] If you have to get two every week, and that's much faster than going to all the big companies or even the startups and trying to convince them to come over. [SPEAKER_02] People also like if you have a small startup of five, eight people, they want to work with each other. Do you just shed their code bases then, or is it pure acquihires in a lot of cases? It can be both. If they've worked on adjacent things or think it's in a similar field or even unrelated but similar technology, we'll take all their learnings and we might rebuild it into Lagora. I think that's what happens in most cases, but they become fully embedded into the team. They're all Lagorians working on the Lagora code base, and then they might bring some learnings. [SPEAKER_01] Is integration hard? No. It's surprisingly easy if you hire people with low ego. That's the thing. If you get five great engineers that don't care about their titles or where they sit in the org chart, that just want to solve problems, it's surprisingly easy to integrate. [SPEAKER_01] When you've got engineering hires wrong, what did you not see that you wish you had seen? [SPEAKER_02] So typically when this goes wrong, it's actually because of me. I'm going to be a little bit introspective here. It's probably because of my own, because I don't have, I've not run an engineering team this big before, and so I start doubting. I'm not confident enough in saying this person who's more senior than me has seen more than me is wrong, and so it's happened once or twice when there's a very senior person and we talk and they talk about all this org building and org design and how they think about all this stuff, and I sense that something's wrong, and I know that all the time, but in the end I end up convincing myself that no, they probably know more than me or they figured it out or whatever, and then two weeks in, four weeks in, six weeks in, you start to figure out they didn't. How fast do you know if you've made a mis-hire? [SPEAKER_02] A month. Then you know. And then you give them really strong feedback. I give really strong feedback after two weeks. What does really strong feedback mean? [SPEAKER_02] Really strong means you're not going to stay if you don't change this, and feedback is feedback. Has anyone ever recovered? [SPEAKER_02] And then you give them really strong feedback. I give really strong feedback after two weeks. What does really strong feedback mean? [SPEAKER_02] Really strong means you're not going to stay if you don't change this. And feedback is feedback. Has anyone ever recovered from a "you're not going to stay if you don't change this"? [SPEAKER_02] No, but they need to get the chance. And if they do, they stay. [SPEAKER_02] What is the hardest role to hire for today? [SPEAKER_02] I think senior management is extremely difficult to hire for. Senior management, horizontal senior management? [SPEAKER_02] Yeah, engineering directors within product and engineering. [SPEAKER_02] Maybe that's always been difficult, but I think it's because we only have really technical people also being managers. And anyone who's seen scale typically also is no longer technical. Do we still have managers? And what I mean by that is one of my dear friends Jason Lemkin from Stashy is anyone on LinkedIn who talks about their team, fire them straight away. We don't want managers who manage other managers who manage those managers. If you can't do full stack, get out. Pick up your severance and go away. Do we still want senior managers? It really depends. You can build a company of super senior engineers. They can do everything and you probably don't need to manage them at all, especially if there's really strong clarity. If they know what they're trying to achieve, the Codex team for example, they all know what they're building. They can just run at it and they don't need anyone to tell them that they're doing well. But if you have a more complex product that can go in many directions and you have to do constant prioritization and you have a suite of engineers and a team of engineers, the way that we have engineering teams is relatively small teams, let's say six people, a PM and an engineering manager. The engineering manager is super technical. They spend most of their time coding. They're not people holding each other's hands and singing songs, but it's still important that I have someone that's accountable to the team health. Are people doing good jobs? Are people having fun? I can't walk around and judge everyone. Are they doing well? And so I think it's important to have someone who's accountable. And that's how we run it. They decide their own roadmap. They're their own little startup, but one person is accountable. Is Max on every new product feature? On big ones, yes. On small ones, no. Is that right? It's worked for us so far. It's worked great. Max is an amazing salesman, which you'll probably know. And so I think Max spends his time on that and he spends his time on product vision and the important product things. So big launches, big things, he's involved early and for the duration of the project. But for small things, that's the reason you hire great people is that you can let them do this. [SPEAKER_01] And so that's the thing with Max. He's a specialist. He so believes what he says. things so big launches, big things. He's involved early and for the duration of the project. But for small things, that's the reason you hire great people is that you can let them do this. [SPEAKER_01] And so that's yeah, the thing with Max is specialist. He so believes what he says. Often when you're being sold, you kind of know you're being sold too. Yeah. [SPEAKER_01] No no, there is no way that he sees himself being wrong in his bones. Absolutely yeah, absolutely. And also, I think that was brilliant. We naturally hate them because they're shit, but Sifted did that piece with the taste of blood. Yeah, did everyone in Lagora just go, "Oh my god?" [SPEAKER_01] Yeah, that's hilarious. Yeah yeah, there's screensavers now that say blood smug on. It's becoming this internal. [SPEAKER_01] Did you guys the Jude lore? I loved it. I've sat on that secret for nine months. [SPEAKER_01] Did you think it was done well? I think so, yeah yeah. What, you asked, I guess if it was not done well, I think the Jude lore idea was great. Did it do well for you guys, do you think? Amazingly well. No no, crazy well. Yeah, it's wild. Yeah, people see it everywhere, which is great. People talk about it a lot. [SPEAKER_01] Which is the goal of the campaign right? It's we need to get everyone talking about us. Dude, we're gonna do a quick fire round so I say a short statement, you give me your immediate thoughts. Does that sound okay? Yeah, let's do it. [SPEAKER_01] So what have you changed your mind on most in the last 12 months? Hiring. [SPEAKER_01] Hiring? Yeah. We need to hire more. As long as adding someone is net positive, we should add someone. [SPEAKER_01] What's the most underrated AI company today, do you think? Lagora. [SPEAKER_01] Dude, I'm an ambassador and even I'm, no shit dude. You're gonna give me another one? I had to say it. I don't know, there's loads. One for me would be Whisper Flow. The pain of removing Whisper Flow for me is immense. Whisper Flow is great. I think we're gonna get more local models though. Whisper Flow is not local. [SPEAKER_01] You're probably gonna get a similar Whisper Flow. Well, maybe they should just go local, but the tool itself is great. [SPEAKER_01] Finish this sentence. The biggest threat to Lagora is not Harvey, but... The thing that's gonna kill us is if we don't keep reinventing ourselves. This sounds really boring, but I think we talk a lot about staying in our swim lane, focusing on our product and our users, and the entire environment is moving so much. If you had me on this podcast a year ago, it would have been very different. So I think the main thing that's gonna kill us is if we lose the ability to constantly react and readjust and reinvent ourselves. [SPEAKER_01] You just worked with Jude Law in terms of brand campaigns. What sports team would This podcast a year ago, you know, it would have been very different. So I think the main thing that's going to kill us is if we lose the ability to constantly react and readjust and reinvent ourselves. [SPEAKER_01] You just worked with Jude Law in terms of brand campaigns. What sports team would you most like to see Lagora across? Could be F1, could be football, could be NBA. F1 would be great. I'm a big F but F1 would be awesome strategically. [SPEAKER_01] Would that be awesome? You do golf? We do golf. The Yankees we sponsor in New York, which is also great. [SPEAKER_01] You sponsor the Yankees? Yeah, you didn't know this. Aaron Judge. [SPEAKER_01] Fucking hell. How much does that cost? That I can't tell you. But I would want, you know, the team that I would want us to sponsor is my local FC Copenhagen football club. That would be a childhood dream. They're doing really bad right now though, so it's probably really cheap actually. It's called exposure. Yeah. [SPEAKER_01] You would get nil. Let's do it. Yeah. [SPEAKER_01] I mean the Champions League? No. No. Europa League? No. They're not even top of the Danish league. [SPEAKER_01] Yeah. [SPEAKER_00] You know, you should be CTO probably cheap. [SPEAKER_01] Yeah. No, I know. It's okay. What is one thing you believe about the future of law that most people would say is crazy? If I had to get crazy, I think there's lots of analogies to coding. I think in law it's very text-based. The agent AI features are similar. If I believe that coding, we're going to look less at source code and more at one layer above. I have to say the same thing about law. Eventually, lawyers will not be nitty-gritty about the language of the contracts. They will work a level above, which is maybe like what's our negotiation stance, what risks are we okay with, which ones are we not okay taking, and not sit and type into Word. I'm not sure if this is true, but this is my hunch that it's going this direction, and that's the, if it has to be crazy, that's it. [SPEAKER_01] Lawyers processes now I'm just like, wow, you seem to have done 100 NDAs. Why are we writing it fresh? This feels like a solved problem. I'm going to get in so much trouble for this show. [SPEAKER_01] Fucking hell. What's the biggest advice to a founder competing in a business industry where there is an 800-pound gorilla? Honestly, just work harder than the 800-pound gorilla. I think, yeah, people underestimate this. The 800-pound gorilla, no one in the 800-pound gorilla is extremely excited to be there. I think that's just like if you're competing against Google, the PM at Google that you're competing against, he does not give a shit if it. No one in the 800 pound gorilla is extremely excited to be there. I think that's just if you're competing against Google, the PM at Google that you're competing against, he does not give a shit if it goes well or not. Maybe she tries really hard, but I don't think if you're a small lean team, you work really hard, you can do really remarkable things. You ready for a bet? [SPEAKER_01] Yes. What are we going to end the year at revenue-wise? [SPEAKER_02] It's going to be above 250. I'm going to 272. [SPEAKER_02] 272, yeah. I think it's going to be above that too. I don't, but I don't want to. I don't know numbers. David's going to call me really mad soon, dude. This has been such a pleasure. I've loved having you and you've been fantastic. [SPEAKER_00] Thank you. will do very well because they're model independent. But if you do. Okay, because you think now that they're tied to X? A hundred percent. Yeah. I was a bit surprised actually with the, I was a bit surprised and a bit sad to see the acquisition. Why? Because I thought that they could, if they stayed independent, they had a really cool, a really cool story. But I mean, I see the synergies. Obviously, they don't have enough compute. They can't train their own models. They probably have to train their own models. It's, I just think it's a shame that the industry is vertically integrated in that way. Do you think IDE is a dad? The current shape of an IDE will die, yes. I think we, I don't know what the new, the next IDE is, but it's not reading lines of code. It's, maybe it's graphical, honestly. Like maybe it's the systems, the architecture that you look at and you review and you plan it there and then like agents run off and make sure that whatever you're planning actually is what's being made. I don't know what it looks like, but I don't think it's lines of code. What percent of developer salary would you be willing to spend on AI tooling for them? I don't want to say infinite, but for me it's a question of opportunity cost. So, we're in a competitive environment, you know? Are you? Yeah. You wouldn't, no way. I didn't know that. There's like, fascinating. I know. There's so much, so many things that we can do and the cost of not doing it is extremely high and it's almost outweighs any sort of token cost. Like, any efficiency gain is worth so much to us and it's not, that's for us, but for certain companies that will look different, right? So, I think it's, the budget on tokens is mostly a question of opportunity cost. Is it worth us spending a ton of tokens to learn if it maybe gives us 20% efficiency? For us, yes. We have a really high opportunity cost. What did you do that you wish you hadn't done? You know, not investing in developer experience fast enough, definitely a problem. Underestimating our growth, also a problem. Now, now I make sure everything we build will scale to 100x the usage. I used to say 10x and then that was not enough so now everything needs to scale to 100x. What changes when you're building for 100x versus 10x? I'm sorry, I'm very naive. No, that's not naive at all. It doesn't always have to change but there are certain limits that you often will put in place. Just be like, yeah, this probably is good enough for the next three months. If we bound the problem in this way which is maybe 10x then we can do x, y, z but maybe that doesn't hold if you're 100x. And so sometimes you need to think about I think particular problems where there's burstiness to it. So Tabular Review is one of our products where you can bulk extract from many documents and many cells. And there's a very big difference between 10,000 cells and 100,000 cells just like on the load of the system because it spikes immediately. And so that's one of those systems where there's actually a difference. And so what do you do in that case where the spike is so immensely different? Yeah. What does that mean you subsequently do differently? We have to think about the experience if 10 people do that crazy thing at the same time and we still have a bunch of other users that we want to have a good experience. So we need to think about fair queuing basically which is like, okay, if you're running 100,000 cells you're probably okay waiting a bit. You can go grab a coffee and that's fine but if you run 10 cells at the same time those should be really fast. Totally get you. If I ask a really unfair one if I gave you access to a superior model for six months ahead of anyone else or superior engineers for six months ahead of anyone else which would you rather have? Engineers. For sure. Because the models they change all the time they get better all the time but if you have really good engineers you can build a system that exponentially improves and that's worth a lot more. What do you know now that you wish you'd known when you started day one? Honestly wish I'd known how quickly we were going to scale because that was the thing that I underestimated all the time. I don't think I was ready for this journey. I became ready really quickly because I got slapped in the face every three months. Do you buy that people are destined for certain stages of companies? I'm getting very personal. If I was you now I'd have in my mind am I the CTO that takes this to public company? It's a very fair question. Do I know? I don't buy that. I think to me it's a question of how quickly can I solve problems? Am I the person that can solve the problems that we have right now the fastest or can someone else solve them faster than me? We have a great culture in Ligora in that no one has any ego. I've told this to I currently have two engineering directors I've told both of them when I hired if there comes a day when I think you'll do better than I will then we swap or I do something else. I have very little and they also have very little tied into their title or their role. We are here to build something huge and that's the most important thing and I continuously evaluate myself on my job performance and if I don't do well I try to rectify that really really quickly and I haven't been able to not rectify it yet but maybe there comes a day. What's the secret to hiring the best engineers with no ego and how obvious are they? They're obvious if they have ego you can even just when you negotiate salaries and titles you can tell. I don't know about you I always say great people want more money they don't mind so much about the title. I think that's right. I think that's absolutely right and I only most of the people that we hire we don't even talk about their title. We talk about the difficult problems that they're going to work on. How important is it that you're together in Stockholm? It's been very important for running really fast I mean this is we talked about the handover cost if you have a PM and a designer and an engineer and they just sit together you can almost not even have the handover you can just be like run at this problem and do it together the three of you you know next week and then it's done but if you have them siloed and there's handover in between you lose so much efficiency. Jump on a zoom cool lacking clarity yeah this doc is not well written enough you have to do another meeting and then you have to do three reviews of the document and then someone else has an opinion that you know sees it somewhere and writes a comment somewhere and then you have to talk about that. How do you factor that into how the best engineers like to be remote? Well we're very opinionated about who we are and who we aren't we if you're a great engineer and you want to be remote then you probably also want to work on very isolated problems and that's that can be fine we probably have those and we probably will have those but they're not for us right now we'd rather find the people that want to solve the same problems with other people. How many engineers were you having two years or by the end of 2027? You're 80 today. Yeah I'm gonna say a number that's too low. I'm gonna WhatsApp it to you on the 31st of December 2027. Were you wrong? Yeah I don't know 300 maybe? 200? 200 and 300 are different you gotta put your name on one. If I have to put my I want to say the lower number let's say 270. 270. Okay so we're gonna have 190 more. Yeah. Can you retain a only talent with 190 more? That's essentially adding two and a half a week. Yeah. Is that possible? If it's linear. I think so. I'd rather miss my number and have A players than hit it with B players. Because I think as soon as you introduce players as soon as you have people that you don't trust or that the team doesn't trust the A players won't stick around. You're buying more companies than I'm doing podcasts these days. And you're laughing because it's true. It's not true. I'm essentially an investor now. My question to you is do you have to buy companies to get the truly truly A talent in a lot of cases? I don't think so but it's faster. That's essentially why. Because if you find a really good founder they're able to attract really good talent. And so you have a small group of five people that are just A talent and then you get five in one week. You know if you have to get two every week. and that's much faster than going to all the big companies or even the startups and trying to convince them to come over. People also like if you have a small startup of five eight people they want to work with each other. Do you just shed their code bases then or is it like pure aqua highs in a lot of cases? It can be both. If they've worked on adjacent things or think it's in a similar field or even you know unrelated but similar technology will take all their learnings and we might rebuild it into Lagora. I think that's what happens in most cases but they become you know fully embedded into the team. They're all Lagorians working on the Lagora code base and then they might bring some learnings. Is integration hard? No. It's surprisingly easy if you hire people with low ego. That's the thing. If you get five great engineers that don't care about their titles or where they sit in the org chart that just want to solve problems it's surprisingly easy to integrate. When you've got engineering hires wrong what did you not see that you wish you had seen? So typically when this goes wrong it's actually because of my going to be a little bit introspective here it's probably because of my own because I don't have you know I've not run an engineering team this big before and so I start downing I'm not confident enough in saying this person who's more senior than me has seen more than me is wrong and so it's happened once or twice when there's a very very senior person and we talk and they talk about all this sort of org building and org design and like how they think about all this stuff and I sense that something's wrong and I kind of know that all the time but in the end I end up convincing myself that no they probably know more than me or like they figured it out or whatever and then you know two weeks in four weeks in six weeks in you start to figure out they didn't how fast do you know if you've made a miss hire a month then you know and then you give them really strong feedback I give really strong feedback after two weeks what does really strong feedback mean really strong means you're not going to stay if you don't change this and and feedback is feedback has anyone ever recovered from a you're not going to stay if you don't change this no but they need to get the chance and if they do they stay what is the hardest role to hire for today I think senior management is extremely difficult to hire for senior management a horizontal senior management no yeah well like engineering directors within product and engineering yeah maybe that's always been difficult but I think it's because we only have really technical people also being managers and so anyone who's seen scale typically also is not no longer technical do we still have managers and what I mean by that is like you know one of my dear friends Jason Lemkin from Stashy is like anyone on LinkedIn who talks about their team fire them fire them straight away we don't want managers who manage other managers who manage those managers if you can't do full stack get out pick up your severance and go away like do we still want like senior managers it really depends you can build a company of super senior engineers they can do everything and you probably don't need to manage them at all you have especially if there's like really strong if they know what they're trying to achieve the codex team for example like they all know what they're building they can just like run at it and they don't need anyone to tell them that they're doing well but if you have a more complex product that can go in many directions and you have to do constant prioritization and you have a suite of engineers and a team of engineers so the way that we have engineering teams is relatively small teams let's say six people a PM and an engineering manager the engineering manager is super technical you know spend most of their time coding they're not like people hold each other's hands and like sing songs but it's still important that I have someone that's accountable to the team health are people you know doing good jobs are people having fun I can't walk around and judge everyone you know are they are they doing well and so I think it's important to have someone who's accountable and that's how we run it right they decide their own roadmap they're their own little startup but someone is one person is accountable is max on every new product feature on big ones yes on small ones no is that right it's worked for us so far it's worked great his time max is an amazing salesman which you'll probably know and so I think max spends his time on that and he spends his time on product vision and the important product things so big launches big things he's involved early and for the duration of the project but for small things that's like the reason you hire great people is that you can let them do this and so that's yeah the thing with max is specialist you know he so believes what he says often when you you're being sold you kind of know you're being sold too yeah yeah no no like there is no way that he sees himself being wrong in his bones absolutely yeah absolutely and also like you know I think that was brilliant we naturally hate them because they're shit but sifted did that piece with the taste of blood yeah did everyone in Lagora just go oh my god yeah that was that's hilarious yeah yeah there's a there's screensavers now that say blood smug on like it's like becoming this internal did you guys like the Jude lore I loved it you know I've sat on that secret for like nine months did you think it was done well I think so yeah yeah what you you asked I guess if it was not done well I think the Jude lore idea was great did it do well for you guys do you think amazingly well no no crazy well yeah it's it's wild yeah people see it everywhere which is great people talk about it a lot which is like the goal of the campaign right it's like we we need to get everyone talking about us dude we're gonna do a quick fire round so I say a short statement you give me your immediate thoughts does that sound okay yeah let's do it so what have you changed your mind on most in the last 12 months hiring hiring yeah I yeah we need to hire more the net as long as adding it someone is net positive we should add someone what's the most underrated AI company today do you think Lagora dude I'm an I'm an ambassador and even I'm like no shit dude you're gonna give me another one I had to say it I don't know there's a there's there's there's loads one for me would be whisper flow like the pain of removing whisper flow for me is like immense whisper flow is great I think we're gonna get more local models though whisper flow is not local you're probably gonna get a similar whisper flow well maybe they should just go local but the tool itself is great finish this sentence the biggest threat to Lagora is not Harvey but dot dot dot the the thing that's gonna kill us is if we don't keep reinventing ourselves this sounds really you know boring but I think we talk a lot about staying in our swim lane focusing on our product and our users and the entire environment is moving so much if you had me on this podcast a year ago you know it would have been very different so I think the main thing that's gonna kill us if we don't if we lose the ability to constantly react and readjust and reinvent ourselves you just worked with Jude Law in terms of brand campaigns what sports team would you most like to see Lagora across could be F1 could be football could be NBA F1 would be great I'm a big F but F1 would be awesome strategically would that be awesome you do golf we do golf the Yankees we sponsor in New York which is also great you sponsor the Yankees yeah you didn't know this Aaron Judge fucking hell how much does that cost that I can't tell you but I would want you know the team that I would want us to sponsor my local FC Copenhagen football club that would be a childhood dream they're doing really bad right now though so it's probably really cheap actually it's called exposure yeah you would get nil let's do it yeah I mean the Champions League no no Europa League no they're not even top of the Danish league yeah you know you should be CTO probably cheap yeah no I know it's okay what is one thing you believe about the future of law that most people would say is crazy if I had to get crazy I think there's lots of sort of analogies to coding I think in law it's very text based sort of the agent AI features are similar if I believe that coding we're going to look less at source code and more of like one layer above I have to say the same thing about law like eventually lawyers will not be nitty gritty about the language of the contracts they will work a level above which is maybe like what's our negotiation stance what risks are we okay which ones are we not okay taking and not sit and type into word I'm not sure if this is true but this is my hunch that it's going this direction and that's the if it has to be crazy that's lawyers processes now I'm just like wow you seem to have done like 100 NDAs why are we writing it fresh this feels like a solved problem I'm going to get in so much trouble for this show fucking hell what's the biggest advice to a founder competing in a business industry where there is an 800 gorilla honestly just work harder than the 800 gorilla I think yeah people underestimate this like the 800 pound gorilla no one in the 800 pound gorilla is extremely excited to be there you know I think I think that's just like if you're competing against Google like the PM in Google that you're competing against he does not give a shit if it goes well or not like you know maybe maybe she tries really hard but I don't I don't think if you're a small lean team you work really hard you can do really remarkable things you ready for a bet yes what are we going to end the year at revenue wise it's going to be it's going to be above 250 I'm going to 272 272 yeah I think it's going to be above that too I don't yeah but I don't want to I don't want to get a I don't know numbers David's going to call me really mad soon dude this has been such a pleasure I've loved having you and you've been fantastic thank you