20Product: Inside Legora's Tech Stack: Why Token Maxing is Failing Enterprise Startups with Jacob Lauritzen, CTO @ Legora

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. So many things that we can do. The cost of not doing it is extremely high and it's almost always any sort of token cost. Honestly, just work harder than the 800 pound gorilla. People underestimate this like no one in the 800 pound gorilla is extremely excited to be there. This is Twany product with me, Harry Stabbings. Now I'm so excited to welcome Jacob Luretson, CTO at LaGora to the show's day. LaGora is the fastest growing enterprise company in history. They hit 100 million in error in just 18 months. They're going to finish this year at 250 to 300 million. I'm pushing them to do 300 million because hey, I'm an investor and it's easy to throw peanuts from the side. But 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. Time to get the notebooks out. It goes quite deep into some pretty granular technical aspects. But this is a must listen. But before we dive into the show's day, you know what's wild? We have AI superpowers now. Yet so many product teams are still flying blind. Buried in spreadsheets, chasing feedback across 10 different tools. Jira product discovery fixes that. I've spoken with hundreds of product leaders and the best teams all do one thing differently. They build a system to capture ideas, validate them with real data and focus their roadmap on the right things. Well that's why product teams at Canva, Deliveroo, Toast and Decathlon use Jira product discovery. It pulls ideas and feedback into one place, with built-in tools to prioritize what'll have the biggest impact. That's when a roadmap stops being an endless list of ideas and becomes a plan people actually believe in. Join more than 25,000 teams already using Jira product discovery head to Atlassian.com/Harry and start building the right thing today. While Jira product discovery turns feedback into priorities, Finn turns questions into instant answers. As AI agents become more common in customer experience, teams often end up juggling multiple silo tools for every job. Well Finn was built to change that. It's a single unified agent that works across your entire customer experience, from service to sales to success and beyond. Finn is the agent making perfect customer experiences, possible for thousands of customers. It's powered by custom models, trained on years of real customer interactions, so it understands the nuance and complexity of customer service, better than any other agent. That means faster resolutions, more consistent support and just better experiences for every customer. It's also designed to be fully self-manageable, so you can easily improve and adapt it as your business evolves. No third party is required. Leading companies like Gamma, Asana, Dordash and Crypto.com already use and love Finn to deliver better customer experiences. So see what Finn can do for your team at fin.ai/20vc. While Finn helps answer the customer, Framer helps impress the next one. You know that moment when marketing wants a landing page, design mocks it up and engineering says, "Yeah, we'll get to it." Thousands of businesses from early stage startups to Fortune 500s are choosing to build their websites in Framer, where changes take minutes instead of days to solve this very problem. Framer is an enterprise grade, no code website builder, the works like your team's favorite design tool, and is used by companies like Poplexity, Mirror, Mixpanel to move faster. Designers and marketers can fully own the site with real-time collaboration, a robust CMS built for SEO, and advanced analytics that include integrated AB testing, so you're not just shipping pages, but you're maximizing what works. And when you're ready to ship, changes go live in seconds with one click, publish, without relying on engineering. Plus, Framer is built for scale, with premium hosting, enterprise grade security, and 99.99% uptime SLAs, whether you want to launch a new site, test a few landing pages. All my greatyourfull.com. Framer has programs for startups, scale ups, and large enterprises to make going from idea to live site fast. Learn how you can get more out of your.com from a Framer specialist, or get started building for free today at framer.com/20VC for 30% off, 30% off a Framer pro annual plan. That's framer.com/20VC for 30% off. Framer.com/20VC rules and restrictions may apply. You have now arrived at your destination. Jake, I am so excited for this. I think Max is one of the most. Do you know, I think it takes a psychopath to no one? And he's like, "Fuck you, Harry, why?" 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. Yeah, of course. Thanks for having me. We were just chatting and you said, "Legor 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?" 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 work. Building an engineering work 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 sort of our organization and our processes. And I just work with the team, like what's working well, what's not working well. How do we solve that, just like any other problem? Dude, how is it different building a team in Android product in 2026 versus 2024 and years prior? Everything's just changing all the time right now. You know, the productivity is through the roof. Processes are up in the air. You can be huge teams. You can be tiny teams. Productivity is through the roof. Yeah. If we unpack that, why is it through the roof? Well, just AI tooling. It's simply like, what do we use in town? It's Cloud Code, it's cursor. You use those two. You're competing. Yeah, yeah. Because everyone's like run from cursor whenever I interview them. Yeah, yeah. So you still have cursor uses. We still have cursor uses. The cursor harness is quite good. You know, there's some personality differences in on our team, but a lot of people still use cursor. Some use Cloud Code. Some use Pi. Those Cloud Code's kind of harness is annoying sometimes. We allow people to do both. Okay. And so we have like efficiency against that. And so we just ship more. We ship more. We ship faster. We debug things faster. We iterate faster. Everything is faster now. And each engineer can produce much more than they could previously. And that just has a ton of ripple on effects throughout the org basically and how you structure it. Because I mean, I think a way I like to think about is when you build software, there's kind of like three phases. There's phase one, which is the product work. You know, what are we building? Translate user pain, user dreams, nightmares into something tangible that we can try and we can iterate on. And when we can figure out if it works, then once you have that, you know, sort of what you want to build. Then you built 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 like the rate limiter was how quickly can you write code? That is now super cheap. So that's sort of been compressed. And so the bottleneck now is like 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 you know, 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? 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 sort of take all the working with clients synthesizing what they think, our own strategic priorities, our own taste and opinions of our vision of where, you know, 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? I'm not sure if I've solved that yet, but I do think it's like, that's the way that I'm thinking about it. It's constantly, what's the bottleneck to our velocity? And then we try to solve that. You said about the kind of reviewing 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? I think so. I think that's one of the solutions. We do AI code reviews today. And it's in its nascent face. It's. You know I said for it. I was like, "My mouth is fat when I was young. I'm not the used to just say I was big-boned." Oh, great. Yeah, it's like, "It's just eight all the Maltese's hands." It's in his nascent faces, sweet. That's the nice. Yeah, rough at just still, but no, I think that's right. I think that's part of it is we have AI review bots. You can have security review, you can have different specialized reviewers. They do a bunch of review and they sort of iterate with the AI coder. And it's like kind of weird because you see this pattern where it's like agents fighting each other until they arrive at something. But even then, I think current review tools are not good enough. I think we need something new. I keep telling people at all the events that I'm at. Like if you're going to do a start-up, 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? How does it sort of take our system in the right direction? That's the kind of 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 there are some strategic trade-offs, 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? Yeah, I think so. I think so. I think that's right. The job of an engineer is changing from typing a bunch of code to sort of one layer above it, which is what does the system do? look like. And then you can have AI running around inside each of the pieces of the system, but you sort of have engineers thinking about the higher level one abstraction above, which is like, what does the system look like? What are the best 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. 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, which is like kind of the mid-engineering of making agents really effective. So you know how you have developer experience teams that they might help write custom LinkedIn or custom developer setups to make developers efficient. We kind of need to have the same team for agents. Like how do we make agents really really effective? How do we make sure that we can enable agents to independently self-improve the system? Can we can we gather data in a really good way so that we can just unleash agents and say, hey, increase conversion rate on my e-commerce store and it can just like go and run experiments. That sort of setting up the loop so agents can just like run and optimize. I think that's going to be the actual job of a lot of engineers. How do you think we do that? I spend a lot of time with Jason Amkin and Anshini 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 determined 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 Godrails really effectively. This is actually something that I'm thinking about right now. Our code base is suddenly get a lot. Happens. It's a good problem to have. We're starting to be a lot of engineers. We're also starting to be 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. And until I'll try to give an example here, which is you can have custom rules, for example, which is like the agent tries to do something and we tell it no, you can't do that. There's like, for whatever reason, you can't do that because we want the system to be in this way. And I think that type of Godrails setting will see 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 HRIS system and your HES system and whatever else, you probably have some engineers that are just setting up the like, this is where you get the data. This is what you can do. This is what you can't do. And then you can just let agents run a mock inside of that system, basically. You mentioned the expansion of the LogoRot code base today. What percent of code to create today is AI-generated versus human-generated? Actually, I took a look recently and it's clawed in cursor on the top. And there's like, I think it's like 2% between them. So they are really, really close. And then it's, you know, miles above the next engineer. So they're way above 50%. You worry that we will see a next generation of security threat with the amount of AI-generated code that Blanny opens vulnerabilities we didn't know we had. Yes, absolutely. This is a very tough one for me. That's why we still add Ligora and probably 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, you know, 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 red actors are extremely efficient now, which means like they can try so many different things and they can keep running at it. And so we need just as good defense. And I'm not sure if we're there yet. I definitely don't think where they get. Which is why we see so many hacks. So whenever I see the hack on Twitter, I'm like, "Oh, Paul, I'm made of this company." That weekend is thoroughly ruined. Yeah, I had a security, and no, not me. One of our vendors had a security incident just yesterday. We just rotated it all out. I mean, just, you know, to be clear, this was internally doesn't affect any of our clients or anything I bad, but it's just, I think we're going to see more of them. Yeah, and I totally got that. 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 post-mortems? Well, actually post-mortems is a great example. We run them really efficiently, you know. It's great. And you know, if you have an incident, now you just unleash an SRE agent and sort of an incident agent, and it will just super quickly figure out what's going on. Look at all the likes, look at all the metrics, the limitry, and it's really, really good. And so like, 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 and the post-mortem basically almost writes itself as well. So that's actually a great example of something that we can run really efficiently, but I think more broader in sort of the software development lifecycle with AI PMs can prototype super, super fast, which is really, really great because that means you can front load a lot of the work so like a PM can start however long before once he or she has the, you know, smallest inkling of an idea that we might want to do this. They can prototype it and they can just go to use a second, they can test it and they can iterate themselves. They don't even need to bring in engineering until they have something that's like clearly super valuable. 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. Do we skip the design stage in a world where prototyping and getting to V1 is so much easier? Yeah, that's a great question. Probably some companies will skip the design phase. I think we can skip the design phase on functionality. You don't need to necessarily have this long, you know, discussion where you said 10 people in a figure out where should the button be. I do think design still has a place, but it's, you know, one level above the individual feature that the individual stuff that we build. It's the design language that we choose to have. It's the taste, it's the opinionated stance we have of who we are and like what does the gore look like? What's the navigation? What's the hierarchy? But it's more for consistency UX UI sake and for taste sake rather than functionality. Do you still use fake money today? We still use fake money, yes. I know where you're going with this. I think 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 kind of stuff. And so you need somewhere to store what your button looks like and what your like pages look like and what's this and what's that. And for us, that's Figma. And it works great for it. Do you think that's the case moving forward? I don't mean anything against Figma, but it's like that's like a storage feature. Yeah, no exactly. It's 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? We mentioned the wonderful word earlier that's at the word of the moment, which is taste. Taste is what separates us. How do you think about the, don't why taste is what the differentiator will be? Is that true? Or is that bluntness, a looking value and tech BS that's trying to protect us? I think taste is important. There's different flavors to taste. Fun and tender. It depends on what you mean with taste. I think you know, in tech, taste is like we have an opinionated stance on something. I think if you don't have taste, then you let AI slop converge to sort of grainess and everything looks the same and everything's just like you need to have taste to have sort of an opinion in its stance in the world. This is who we are. This is what we do 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 like this is who I am. This is who we are. And some of you are going to hate it. And that's okay. Because you need to have some edges, you know, if you're just like letting AI rip, you're going to look the same as everyone else. When the cost of copying is quicker than ever, does that change how you think about product? You're in a very competitive space and plenty of people can copy you very quickly. Does that change how you think about product? No, not really. The important thing for us is that we're building something that our clients get a lot of value out of. And we built that as fast as we can, but we don't build it faster than that. There are tons of people that are vibe coding. You know, there's people that are vibe coding. Logo, there's people that are vibe coding. Sales force and and and doctors sign in other companies. It's very great to get to the 90% where it looks the same. And in like 80% of the cases, it works similarly. It's the other 90% that are difficult. You know, it's like ensuring all the edge cases work and all the unhappy paths and all the ordered locking and all the our back and all the weird scenarios that you end up at at a certain scale. That's what's difficult. So no, we just, we keep focused on how do we create the most value for our clients and sprint towards that as fast as humanly possible. My girlfriend is a lawyer and wonderful, but they're not the fastest in terms of adoption and usage. I'm going to get in a huge trouble for saying that. I was not talking about how I was talking about the legal profession. You can build products so much faster than your customer can consume it. Yes. How do you think about that? We have this notion internally that there's the speed of AI, there's a speed of our product, and then there's the speed of humans. They're not the same necessarily. 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. We are sort of taking them along for the ride. Sometimes it can be frustrating, but it's also really rewarding that we can actually take the huge base of people and we can really change the way that they work and their efficiency and their productivity. We can remove but loads of awful work that they spent their time doing and focus on the moisture, cheek, cheek, war, important work. What have you not done that you wish you had done? An email client would have been really cool. I would have loved to build that. I've I've code one just for fun. We're probably a few ways that we're a little away from that because there's other high priority things, but I think an email client is where I lawyer sit a lot. Do you vibe code internally within Logora for customer presentations for you now? It meant constantly. Is that the future of enterprises or is that bluntly Logora at the very precipice of innovation? It will be the future. I don't know when, but it will be the future. I think there's like, and just so we understand, what does that mean? You build sites for slaughter or mass so you can pitch to them and if a chance you can pitch to them. broader than that. It's like, we have a team now that's internally I enablement, which is just like reimagining, you know, again, 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 a thousand employees, what does that look like? And that means, obviously, you know, called co-work and similar things for everyone, but it's also like, can we just build the bunch of the tools that we need ourselves? Can we just vibrate a bunch of the tools? Can we vibrate our HR system? Can we vibrate our talent acquisition system? Can we vibrate our payroll system? Like so many things where tools exist out there, but you always need to customize them so much and they always basically never really work. And we just built them now because it's so cheap to build. What have you been able to vibrate a way? Well, we've added a bunch of things that are additional or additions to vibrate coding. So great, really stupid example is Ryan, who joined from Canada, we have a team of people joining from Canada, they're all moving to Sweden, and he vibrated an app to help everyone migrate. So that very specifically with your Canadian, these are like all the laws and all the steps you take. And there was like, 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 date of I've code, and it saves so much time for an entire team. So it's like, you can build the big systems, but even just all the small ones that you can build really out of. I was with a friend who's a public company CEO the other day. And he was like, you know, my chief of staff took three weeks off and basically vibrated Cooper, and we replace Cooper. And it's works and it's brilliant. What do you say to people who are like, that's ridiculous. 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's really depends on the system. Let's say there's two actually systems. There's the horizontal one, which is like, how big is your product surface area? And there's the vertical one, like how complex is it? So if you're deep essentially your surface area, it looks quite similar to simple app, but it's just a lot of complex stuff. It hides away a lot of complexity to do so. And there's the other one which is your very very shallow app, which is like tons of things you can do, but there's not that much complexity. If it's a shallow app, and it requires a lot of customization from you, maybe you just build it. That's probably actually the right thing to do. 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 like their proximity to customers, and then that delivery mechanism back to engineering, which is kind of always what PMs did and debased. Does the role of the PM change in the next few years? Yes. And no, I think there are certain people that are a lot of people are saying that product and engineering are converging. It's becoming one thing. It's like one person can do the product work and build the engineer, like 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. It can be true, but it's inefficient. And I'll tell you why. So we were talking about product, you don't usually do the product work first, the scoping, then you built it and then you ship it and you review it. And then company like the Gora, 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 like the opportunity cost of that is really high. Because what you really want them to do is the product work, like 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. So that's how I think about it right now. And for certain companies, if you're doing developer tooling or doing consumer wear engineers, intrinsically have a good sense for their other other own clients, you maybe don't need a PM at all. Cause like you haven't needed a PM before a either there. So I don't think that changes with and with without AI, PMs can now do engineering that changes with AI, but it's not always efficient to do it. It's like a matter of opportunity cost. There's handover cost, which is if I do all the product work and then I give a purity and I give it to an engineer, then like you lose efficiency there, it's good if PMs do some amount of bivocoding to like show very high fidelity. Here's a prototype. This is exactly what it looks like. There's just a handover cost. Exactly. Yeah, exactly. But they shouldn't spend a lot of their time engineering. Because if they just like focus on actually engineering, we lose out on the product work. I mean, a little brother coming out of CS, but university, what would you advise me to be best placed in the next three to 10 years? So if I were to advise someone social media marketing, I'd say, Hey, you need to be full stack. He needs to be able to create the image, get it out and amplify. Yeah, similar thing. I think, I think I think actually the most important thing is you need to learn how to learn, you need to to to figure out how you constantly reinvent yourself and keep learning and improve because the things things change all the time right now. It's it's every week. There's something you should be doing. You need to change your way of working or whatever. 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 risk kind of works out. Because if you can just learn faster than everyone else, then you know, over time, you win. To what extent is the quality of La Gora as a product dependent on the quality of the underlying models? Much less than most people think. The value of La Gora is there's so much more around it, whether it's like the deprimatives that make sense for legal, that make it more efficient to work with AI, or it's all the enterprise features or it's the optimal rounding 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 La Gora people would still pick La Gora. So they don't buy it based on the model. How is model usage changed for you over time? It changes a lot. I mean, the best model changes by weekly. We've been between open AI and at the same time, we keep evaluating all the different models. Do you use like 15 at the same time for different tasks? Not 15, but yeah, 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. You know, performance needs to be here. How much can we increase latency without dropping in performance by building our agent and our other AI features in a way that you can decompose the problem. The efficient. You can have latency or performance at the fastest, but it may not be the best output or slower, but fucking great output. Yes. Yeah. Which one? I have to choose. Yeah. I see 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. What do you I'm just fascinated now? What do you think about the future of open source as we do move more and more to a focus on cost? 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. I mean transcription can run on device and run on my iPhone. I have local transcription on my Mac. When I when I do flights and there's no Wi-Fi, I have local models running so I can keep coding. But it's just like a Gwen model that runs in Help's 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 model for sovereignty reasons and for like security reasons. We should have great open source models. What worries you today? A lot of people are worried about the open source Chinese models, which was kind of thinking about it. 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, really good to have some games. You read it. We want it up and up in a great place. If there's a dual pulley or I'm not pulling on the models for our fears reasons, you know, you do want to have some competition. You want to have any place to play in the model race today. It should, but it doesn't yet. How far do you think are we in the efficiency frontier on training? Are we like 1% of the way there? Or is it like, we're 90% and like, we might e-cout some little bit more. One thing is just like the current architecture. How long does that, you know, does that plateau? Do we need something new? I mean, there's a one model released two days ago that's sub quadratic, which is huge context length. That's super exciting. I don't know if I trust the benchmark yet. You know, we need to validate that. But there's architecture really innovations going on still. And I don't know, maybe the current element architecture is not the one to take us all the way. What role does not exist today? The E think will be very common in five years time. I think the internal AI systems role thingy for enterprises. I think IT will can have like a flowering moment here. And you know, go from being in turn, IT that's like setting up your computers and whatever to maybe have a sister team that's building a tons of internal tools that just make your life so much easier. If enterprises don't create that role, I will get really annoyed because there's so much efficiency to gain there. Really getting into the end price and having all of that for them. Do you have to have FDs to have usage and enterprise? You work with relatively sticky noise. Yeah. Yeah. Yeah. Do you have to have people show them here you go? Here you go. We currently do. Yeah. But I think that's just that's an education thing in five years. Maybe we don't know. That's the price you pay from being you know, on the forefront. Yeah, you have to educate and you have to help and that's why people want to work with us also. Are you ready for an unfair one? Yes. What have you done better than you from a product perspective or an engineering perspective? They've been more aggressive with hiring. I have not been aggressive enough with hiring because I've always tried to have a very, very small, very lean team, which I believe the lot in. I consistent the underestimated how many people need to be. I had this slide that I drew up a year and a half ago that I showed the entire company and it was you know, the 300 spots and versus the Persians. And it was like LaGora and the 300 spots since then I said, I'm pretty sure I said, we will cap out at 20 engineers. That's something like that. which is like way undershooting it. How many engineers do you have today? Today we are about 80. Yeah, you got that wrong. I got that really wrong. 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. Second, there's loads of features that you can basically staff a team to build that we've kept. Can you ramp as quickly as you need to and retain quality? Yes, we're really good at this. First, we're extremely selected with hiring. Maybe that's also why we're slower at hiring. So we're a really great people. And the ramp up time is extremely fast. How do you make ramp really fast as specifically as possible and anything that you do? I can tell you what we probably should do. Because like the reality is things move really fast. You need to have, so we have a developer experience team. Relative to the new, again, a mistake I made that should have staffed that earlier. And they are making everyone's life so good. What do they do? So they make sure that our local development setup works really, really well. It's super fast. It spends up really quickly. We have our own background coding agent that they built that allows each engineer to have like 10 different agents running concurrently with like 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 race it to a human. The efficiency gains there are huge. And they will then also build tooling that helps onboard people. And so it can just be like, make sure you have really good readme files in your repository so that a new engineer will just ask their cloud code or their cursor about all their questions. Like that's remarkably effective. So it's just like even just AI tooling makes it faster to ramp. 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 two few. I should have done it when Opus 4.5 came out, I think. Because that's when I should have done before that. But then the productivity of each engineer to next I say. And so if you can make everyone 20% more efficient, it's even more gains. How does hiring engineers in Europe differ to hiring in the US? There's a few different ways. In the US, people are 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 generally are more, I don't want to call them mission-driven or loyal, but they're like, they really buy 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. That's great. And the US is more transactional. I think so. Yeah. Do you find the attachment to equity different? It's actually something that we had to sort of educate people on in Sweden. And in Europe, I think it's, people are just not used to the venture thing. They don't know how to value equity the same way. Like, you have to really, this is how it works. This is what it means. Like, if this happens, then you get this much money. But you don't get it in cash. It's not like, yeah, yeah, yeah. There's tax in this. I do. They're not teaming that. Wait a minute. You're giving me half a million dollars. Exactly. Not literally, but like in the future. Yeah, exactly. So that's been a little bit difficult for us. But I think it's a, that's part of just creating the ecosystem. And 10 years, the next start of the ComSort of Stockholm. Hopefully we won't have this problem. Everyone is encouraged to use as many tokens as possible. I'm on the board of public companies. And they're like, oh, I'm hearing about like token maxing and tokens. What do you advise a CEO in terms of intelligent usage of AI? And should we just be pushing tokens as much as fucking possible? So a few different things on that. I think one, having a leaderboard, a lot of people say this. Get a leaderboard, 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 like how much better they're doing. It reward them for being effective and efficient. And having more output, not for necessarily using AI. But like AI will be the way there. That's one of the points. I had another point for enterprises. This is actually where I think cursor has a recent to live. And recent to exist, which is if your options are codex and cloud code and a neutral third party and you all pay, you know, you pay consumption based, cursor can help you optimize your token spend a lot. 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. Well, can they now post acquisition by Grog? Well, we'll have to see if the first part can be done. I actually disagree and that's why I actually think both cognition and fat tree will do very well because that model independent. But if you think now that they're tied to X. A hundred percent. Yeah. 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 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. I just think it's a shame that the industry is is vertically integrated in that way. Do you think ideas are dead? I think the current shape of an idea will die, yes. I don't know what the new, the next idea 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 in your review and you plan it there and then agents renounce and make sure that whatever you're planning actually is what's being made. I don't think it's lines of code. I don't want to say infinite. But for me, it's a question of opportunity cost. Why are you? Yeah, I wouldn't do that. No, I didn't know that. There's like, fascinating. I know. There's so much, so many things that we can do. The cost of not doing it is extremely high. And it's almost always any sort of token cost. Like any efficiency gain is worth so much to us. That's for us. But for certain companies, that will look different. 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. Under estimating our growth, also a problem. And 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 as far as 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. So like, yeah, okay, we can, if we have these, if we bound the problem in this way, which is maybe 10x, then we can do what I said. 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 we're typically reviews one of our products where you can bulk extract from many documents and many, 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. Of course, 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? 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 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, that those should be really fast. If I also really unfaewon, 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 a 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 proud. So if I was you now, I'd have in my mind, I'm either CTO to take this to public company. It's a very fair question. No, 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 culturally and legal way and 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 heard. If they come today, 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. 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, when maybe there comes today. What's the secret to hiring the best engineers with no ego? And how obvious are they? They're obvious if they have ego. Even just when you're negotiating, it's all recent titles. You can hear it in the towel. I didn't about you. I always say great people want more money. Yeah. They don't mind so much about the title. Absolutely right. Most of the people that we hire, we don't even talk about the title. We talk about the difficult problems that they're going to work on. How important is it that you are together and stuck with them? It's been very important for running really fat. I mean, this is, we talked about the handle for cost. If you have a PM and a designer and an engineer and they just sit together, you can almost not even have the handle. where you can just be like, run it this problem and do it together. The three of you, then it's done. But if you have them siloed and there's handle in between, you lose so much efficiency. Jump on a Zoom cool, lacking clarity. Yeah, this stock 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, what are the best engineers like 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. That can be fine. We probably have those and we probably will have those, but they are not for us right now. We'd rather find the people that want to solve the same problems with other people. How many engineers we have in two years? Well, by the end of 2027, you're 80%. Yeah, I'm going to say a number that's too low. I'm going to WhatsApp it to be on the 31st of December, 2027. Were you wrong? Yeah, as a reverse. I don't know, 300, 200, 200 and 300 different. You're going to put your name on one. If I have to put my, I want to say the lower number, let's say 270. 270. OK, so we're going to have 190 more. Yeah. Can you retain a only talent with 190 more? That's essentially adding two and a half a week. That possible. If it's linear. I think so. I'd rather miss my number and have eight players than hit it with three players. As soon as you have people that you don't trust or that the team doesn't trust, the eight players won't stick around. You're buying more companies than I'm doing podcasts these days. [LAUGHTER] And you'll all think, is this true? It's not true. I'm essentially an investor. My question to you is, do you have to buy companies to get the truly, truly a talent in a lot of cases today? I don't think so, but it's faster. Because if you find a really good person who-- 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 to it 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, 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 unrelated, but similar technology will take all their learnings, and we might rebuild it into LogoRa. I think that's what happens in most cases. But they become fully embedded into the team. They're all-- LogoRaans working on their LogoRa code base. And then they might bring some learnings. Is integration hard? It's surprisingly easy if you hire people with low ego. 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 a pressing least. It's great. When you've got engineering highs wrong, what did you not see that you wish you had seen? 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-- I don't have enough 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. It's happened once or twice when this is a very, very senior person. We talk and they talk about all this sort of 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. 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 mess on it? 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, Jay? Really strong means you're not going to stay if you don't change this. 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? This is a great question. All of them. No, I think senior management is extremely difficult to hire for. In your management, a horizontal senior management? Engineering directors. Maybe that's always been difficult. 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? Then what I mean by that is, you know, one of my dear friends Jason, I'm here from Sasha's. Anyone on LinkedIn who talks about that team, fire them. Fire them straight away. We don't want managers who manage other managers, who manage other managers. If you can't do full stock, get out, pick up your severance and go away. Do we still want like senior managers? Well, you can build a company of super senior engineers that can do everything. And you probably don't need to manage them at all. Especially if there's like really strong, if they know what they're trying to achieve, could the codex team, for example? 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, PM and an engineering manager. The engineering manager is super technical. It's been most of their time coding. They're not like people who hold each other's hands and like sing songs. (laughs) 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, you know, 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, their own little startup, but someone is one person is accountable. Is Max on every new product feature? And on big ones, yes, on small ones now. Is that right? It's worked for us. His time, Max is an amazing salesman. I sure probably know. (laughs) 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. The thing with Max is Bachelors, you know he so believes what he says. Often when you're being sold, you kind of know you're being sold too. Yeah. There is no way that he sees himself being wrong. In his bones. Absolutely. Yeah, absolutely. And also, I think that was his brilliant. We naturally hate them because they're shit, but sifted. Did that piece. What the fuck? It tastes a flood. Yeah, yeah. Did everyone in Lagoraj just go, oh my god. Yeah, that was hilarious. Yeah, yeah, yeah. There's screen savers now that say, "Blue Smuck." I'm like, "Oh, it's like this is internally." Did you guys like the Jude Law? 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 asked, I guess, if it was not done well. I think the Jude Law idea was great. Did it do well for you guys? You think it would have been off mixing the word? No, no, crazy well. Yeah. It's wild. People see it everywhere, which is great. People talk about it a lot. Yeah. Which is like the goal of the campaign round. It's like we need to get everyone talking about us. Dude, we're going to do a quick far round. So, I say a short statement. You give me your immediate thoughts. That sound okay. Yeah, that's the way. Change your mind on most in the last 12 months. You can have hiring. Hiring? Yeah. We need to hire more. As long as adding it to someone, isn't it positive? We should add someone. What's the most underrated AI company today? Do you think? Look over here. Dude. I'm an investor and even on my nose shit, dude. Come on. You're going to give me another one. I had to say it. 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 going to get more local model stuff. Whisper Flow is not local. You're probably going to get a similar Whisper Flow. Well, maybe they should just go local. But the tool itself is great. Finish their sentence. The biggest threat to LaGour is not Harvey, but dot, dot, dot. The thing that's going to 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 had me on 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 if we lose the ability to constantly react and readjust and reinvent ourselves. You just want with you, Lauren, times of brand campaigns. What sports team would you most like to see LaGour across? Could be F1, could be football, could be MGA. F1 would be great. But F1 would be awesome. Stratically with that be awesome. You do go for a strategic. We do golf. The Yankees we sponsor in New York, which is also great. You sponsor Yankees. Yeah, you didn't know this. Aaron Judge. Fucking hell. How much does that cost? That I can't tell you. But I wouldn't want, you know, the team that I would want is the 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. You were getting ill. Still at the end. I mean, the champion is a new. I know. You were hoping to get a nutty wind tub of the day usually. Yeah. So I die his butt. You should be CPT. I'm cheap. You see, 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 in law. It's very text based. So 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 needy greedy about the language of the contracts. They will work a level above, which is maybe like what's our negotiation stance or like what risks are we okay, which ones are we not okay taking and not sit and type into word. What's the biggest advice to a founder competing in a business? in his stash industry, why there is an 800 pound gorilla. - Honestly, just work harder than the 800 pound gorilla. People underestimate this like 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, like the PM in Google that you're competing against, it does not give a shit if it goes well or not. Maybe she tries really hard, but if you're a small lean team, you work really hard, you can do really remarkable things. - You ready for a bad? - Yes. - And the year after every new year. - It's gonna be above 250. - We have 272. - 272? - Yeah. - I think it's gonna be above that too. - Ooh. - I don't want to get in trouble. - I'm just not getting in trouble. - I don't have numbers. - I don't have a minute, Max, I'm bad. - I know. - David's gonna call me really mad soon. - Dude, this has been such a pleasure. I've loved having you and you've been fantastic. - Thank you. - This is my first podcast ever by the way. - But before we leave you today, you know what's wild? Buried in spreadsheets, chasing feedback across 10 different tools, Jira Product Discovery fixes that. Well, that's why product teams at Canva, Deliveroo, Toast and Decathlon use Jira Product Discovery. It pulls ideas and feedback into one place with built-in tools to prioritize what'll have the biggest impact. Join more than 25,000 teams already using Jira Product Discovery head to Atlassian.com, forward slash Harry and start building the right thing today. Well, Finn was built to change that. It's a single unified agent that works across your entire customer experience from service to sales to success and beyond. Finn is the agent making perfect customer experiences possible for thousands of customers. It's powered by custom models, trained on years of real customer interactions so it understands the nuance and complexity of customer service better than any other agent. That means faster resolutions, more consistent support, and just better experiences for every customer. It's also designed to be fully self-manageable so you can easily improve and adapt it as your business evolves. No third party's required. So see what Finn can do for your team. At fin.ai/20Vc. You know that moment when marketing wants a landing page, design mocks it up and engineering says, yeah, we'll get to it. Thousands of businesses from early stage startups to Fortune 500s are choosing to build their websites in Framer where changes take minutes instead of days to solve this very problem. Framer is an enterprise grade, no code website builder. The works like your team's favorite design tool. And it's used by companies like Poplexity, Miro, Mixpanel to move faster. Designers and marketers can fully own the site with real-time collaboration, a robust CMS built for SEO and advanced analytics that include integrated AB testing so you're not just shipping pages, but you're maximizing what works. Plus, Framer is built for scale with premium hosting, enterprise grade security, and 99.99% uptime SLAs, whether you want to launch a new site, test a few landing pages, or migrate your full.com. Framer has programs for startups, scale ups and large enterprises to make going from idea to live site fast. Framer.com/20VC rules and restrictions may apply.