S13 E5: The Dynamic Compute Revolution: Eliminating Cache Invalidation with Julien Verlaguet, Founder & CEO of SkipLabs
Julien Verlaguet is a self proclaimed "French guy", growing up in south of France. He studied in Paris, and moved to the US when he was 27, spending 10 years in the Bay Are and 5 years in New York. He's spent many years developing software, in particular, developing programming languages. Outside of tech, he is married to a Columbian woman, and admits his Spanish isn't as good as it should be. He loves to play Pétanque, merely needing a flat surface to play on.
Julien was a lead programming language designer at Facebook, and lead the open source release of a new programming language. Over time, he noticed that frontend dev was in a resolution with reactive paradigms, while backend architectures remained bogged down by manual steps. In 2022, he stepped out to create Meta-grade creativity usable in everyday software.
This is the creation story of Skiplabs.
Links
https://www.linkedin.com/in/julien-verlaguet-b5710a20/
Current Sponsors:
Checkout our Stacklist! https://stacks.codestory.co/
Hosted by Noah Labhart | Technical Founder & Startup Mentor.
Our Sponsors:
* Check out Granola and use my code granola.ai/CODESTORY for a great deal: https://granola.ai
* Check out Perplexity and use my code CODESTORY for a great deal: https://www.perplexity.ai
Advertising Inquiries: https://redcircle.com/brands
Privacy & Opt-Out: https://redcircle.com/privacy
[SPEAKER_01]: That's, I guess my experience with programming languages is I tend to listen to people's problems, but very little to people's solution. [SPEAKER_01]: I've worked on programming languages for a long time, I've had a lot of people coming back with feedback for me. [SPEAKER_01]: Usually they know what the source of the pain is, but usually users have a very poor sense of what a good solution is. [SPEAKER_01]: And that's because they don't care about the rest of the product. [SPEAKER_01]: They only care about their use of it.
[SPEAKER_01]: And so the solution that they're going to propose is usually a really easy fix for what they want to do, but not necessarily a good... My name is Julian Verdequette, and I'm CEO of Skip Labs.
[SPEAKER_04]: This is code story. [SPEAKER_04]: A podcast bringing you interviews with tech visionaries. [SPEAKER_04]: 6 months moonlighting goes. [SPEAKER_00]: I was lossing on the backhand. [SPEAKER_04]: Who share what it takes to change an industry? [SPEAKER_00]: I don't exactly know what to do. [SPEAKER_04]: It's all too many girls to get right. [SPEAKER_02]: who built the teams that have their bad company is its team's help each other, which is proud of our team. [SPEAKER_04]: Keeping scalability top of mind, all that infrastructure was up there.
[SPEAKER_04]: Yes, we've been fighting it as we grew up. [SPEAKER_04]: Total waste of time. [SPEAKER_04]: The stories you don't read in the headlines. [SPEAKER_04]: It's not an easy thing to achieve. [SPEAKER_04]: To get yourself a deficit of off, try to begin to ride the ups and downs of the start-up line. [SPEAKER_04]: Need to really want it. [SPEAKER_03]: Not just about technology. [SPEAKER_03]: All this and more on code story. [SPEAKER_03]: I'm your host, Noah Labpart. [SPEAKER_03]: And today, how Julian Verlicwitt has turned the cleared of logic into streaming, keeping views fresh using skips incremental compute.
[SPEAKER_03]: Julian Verliguit is a self-proclaimed French guy growing up in the south of France. [SPEAKER_03]: He studied in Paris and moved to the US when he was 27, spending 10 years in the Bay Area and 5 years in New York. [SPEAKER_03]: He spent many years developing software in particular developing programming languages. [SPEAKER_03]: Outside of tech, he is married to a Colombian woman and admits his Spanish isn't as good as it should be. [SPEAKER_03]: He loves to play Patinka, merely needing a flat surface to play on.
[SPEAKER_03]: Julian was a lead programming language designer at Facebook and led the open source release of a new language. [SPEAKER_03]: What led to this was that he and his team noticed that front-end development was in a revolution with reactive paradigms, while back-end architectures remained bogged down by manual steps. [SPEAKER_03]: In 2022, he stepped out to create meta-grade infrastructure, usable in everyday software based on this language.
[SPEAKER_03]: This is the creation story of skip labs. [SPEAKER_01]: So skip labs really as a name indicates, it's the company that builds products based on skip. [SPEAKER_01]: We open source to programming language called skip that was released by Facebook in 2018. [SPEAKER_01]: So back then that was a research project within Facebook. [SPEAKER_01]: and then one skip was released a couple of years later I decided to found skip labs and the goal of skip labs is to go after products where the programming language gives us an edge, especially when reactive programming gives us an edge because we didn't want to be in the business of setting a programming language [SPEAKER_01]: And that's just because I heard so many horror stories about anybody who tried that.
[SPEAKER_01]: That, yeah, we decided to build products where the technology that we have gives us an edge. [SPEAKER_01]: And so right now, we build a product called Skipper. [SPEAKER_01]: And Skipper is a coding agent that works in a closed loop, so think of it. [SPEAKER_01]: You can think of it to live it. [SPEAKER_01]: You can use it all the way. [SPEAKER_01]: Tell me about some of the other of them. [SPEAKER_01]: So you give or we die back. [SPEAKER_01]: Skipper that you might take five of the process.
[SPEAKER_01]: And then you let Skipper switch ways to the other. [SPEAKER_01]: And then you can control you something that works.
[SPEAKER_01]: Yeah, so we have also built development environments, or JavaScript. [SPEAKER_01]: You can check it out, it's on skiplabs.io. [SPEAKER_01]: And that's for anybody who wants to use React programming from JavaScript. [SPEAKER_01]: And then we also built a clone of SQLite. [SPEAKER_01]: So it's a database that works like SQLite, but that is also reactive, so we can listen to queries. [SPEAKER_01]: But we've shelved this project for now. [SPEAKER_01]: So we kept a lot of the underlying technology in our stack.
[SPEAKER_01]: But the SQL engine itself, we shelved it for now.
[SPEAKER_03]: Let's dive into the MVP for skip labs, but then also for skip. [SPEAKER_03]: I'm curious about how you went about building that. [SPEAKER_03]: What sort of tools you're using and obviously probably skip is at the root of that. [SPEAKER_03]: But what kind of tools you're using to bring it to life? [SPEAKER_03]: And how long did it take you to spin up? [SPEAKER_01]: What we're trying to do with skip is really two different things. [SPEAKER_01]: So first we realize that basically coding agents are reactive systems.
[SPEAKER_01]: First of all, let's see if I'm aware reactive system is because otherwise I think a lot of people are going to be confused. [SPEAKER_01]: Reactive is a term that is a little bit loaded. [SPEAKER_01]: It's depending on who you're talking to, it can mean different things. [SPEAKER_01]: So, to some people, it means streaming, and to some others, it means spreadsheet semantics. [SPEAKER_01]: I don't mean streaming, so when I'm active programming, I don't mean streams. [SPEAKER_01]: I mean something that works like a spreadsheet, so you change something and then the rest of the sheet updates.
[SPEAKER_01]: So for me, that's reactive programming and so that's what skip is for. [SPEAKER_01]: Skip is a programming language that basically generalizes the way Excel works or the way Reactjs works this way too. [SPEAKER_01]: So Reactjs, you... [SPEAKER_01]: pretends that the app that you're trying to build doesn't change, so that's how react works, right? [SPEAKER_01]: Your job is a developer. [SPEAKER_01]: It's to develop your app as if it was in a frozen state and not think about updates.
[SPEAKER_01]: And then when you change something, it's the role of the framework to make the update for you, right? [SPEAKER_01]: So you are the one defining the dependencies, but you're not explicitly saying what should happen when it change occurs. [SPEAKER_01]: That is the job of the framework. [SPEAKER_01]: So that's what I call reactive programming. [SPEAKER_01]: And skip is basically a whole development environment slash programming language. [SPEAKER_01]: Design specifically for that. [SPEAKER_01]: So now that we define reactive programming, the turns out that encoding agents has very many cases where reactive programming is really, is really a good fit.
[SPEAKER_01]: Think about it. [SPEAKER_01]: Basically, what encoding agent does is that it makes changes and once those changes are made, it needs to go and update its state and knowledge about what is left to be done in the system, right? [SPEAKER_01]: And that is exactly what's reactive programming is for. [SPEAKER_01]: So if you try to write it by hand, which you can, meaning you can write reactive systems without a reactive programming language. [SPEAKER_01]: But if you do what you'll end up doing is maintaining a bunch of caches by hand.
[SPEAKER_01]: And when you do that, trying to do your caches validation by hand, it's going to lead to a bunch of bugs. [SPEAKER_01]: and you're probably going to get involved. [SPEAKER_01]: So skip is a good way of getting this right. [SPEAKER_01]: So that's for the harness. [SPEAKER_01]: The second part of the story is that we've built a bunch of tools to help the coding agent produce better code. [SPEAKER_01]: And one of them is a re-implementation of TypeScript that we've written from scratch.
[SPEAKER_01]: That is both sound and incremental. [SPEAKER_01]: And then we've built a bunch of tools on top of that implementation. [SPEAKER_01]: But the idea here is you have an AI that's going to produce a lot of code and you want a harness that a really constrained development's environment to provide feedback to this AI. [SPEAKER_01]: And the only way this is going to work well is if the tooling that you provide is very fast has a very low latency. [SPEAKER_01]: and to build this kind of tooling, the only way to make that work at scale is to have an incremental implementation of your tools, and that's where skip comes in.
[SPEAKER_01]: To get back with Goddess into Skipper, [SPEAKER_01]: Two dimensions, one, that is, that reactor program is just a good bit to write to harness. [SPEAKER_01]: Two, we had a bunch of tools in mind where we knew we could help AI, an AI produced that a code and we just cockled them together and that gave birth to Skipper. [SPEAKER_03]: you've got skip a then. [SPEAKER_03]: How are you progressing and maturing it? [SPEAKER_03]: And I think to wrap in a box a little bit, what I'm looking for is how do you build your roadmap for skip a, or really for any of the products you build at skip lax, but how do you go about deciding that?
[SPEAKER_03]: Okay, this is the next most important thing to create a dress or build or skip a. [SPEAKER_01]: So there's two separate ways. [SPEAKER_01]: There's one that is more vision driven where you have something in mind and that's when I say you it's not necessarily me It could be somebody else on the team. [SPEAKER_01]: So somebody on the team could come to me, which is actually what happened with Skipper [SPEAKER_01]: Somebody on the team could come to me and say, hey, I really think I can build this thing, I think it's a game changer to try T-Trump.
[SPEAKER_01]: So that's why I would call more vision driven, and it's typically what you're going to do when you're going from zero to one. [SPEAKER_01]: When basically there's really not much there, you need a vision to drive what you're going after, and the goal of the person who is driving the vision is to convince the rest of the team that this is the
[SPEAKER_01]: The other way is just more natural and I would say easier is once you have something then it's more like feedback driven. [SPEAKER_01]: So the one thing though and that's I guess my experience with programming languages is I tend to listen to people's problems but very little to people's solution. [SPEAKER_01]: I've worked on programming languages for a long time and so they've had a lot of people coming back with feedback for me and usually they know what the source of the pain is but usually users have a very poor sense of what good solution is and that's because they don't care about the rest of the product, they only care about their use of it.
[SPEAKER_01]: And so the solution that they're gonna propose is usually a really easy fix for what they want to do But not necessarily a good fit for how the product should work. [SPEAKER_01]: So yeah, two ways to go about it One day is more vision driven the other one that's more feedback to him [SPEAKER_03]: Yeah, that makes sense and it feels a little different than what I normally hear with building just a normal product and building a language building something that's built around the skip language seems like you have to lean more on that vision than user feedback.
[SPEAKER_03]: Am I hearing that correctly? [SPEAKER_01]: Yeah, it really depends on where we are in the lifetime of the product, but when you're building a company that is built around a technology, you will have to take shots like that, where you will have to try to build something based on that technology and see if it sticks, right? [SPEAKER_01]: So imagine, for example, a company that has been very successful at that is temporal, right? [SPEAKER_01]: So temporal, the goal of the company was to build a framework for durable execution at a time where durable execution didn't exist, right?
[SPEAKER_01]: And so they couldn't go around and ask, hey do you think doable execution would be something you would use or why do some kind of market study, right? [SPEAKER_01]: Because if you do that then basically asking people's opinion on something that doesn't exist is not going to work. [SPEAKER_01]: So they needed to have that vision and drive that vision and if it works and once it picks up then it's a huge reward but it's also very risky because you will know very late if your vision is going to turn into a viable company.
[SPEAKER_01]: But I think that's more, that's not how every company operates and that's not how every company should operate. [SPEAKER_01]: But for a company that's based on a vision on a technology, then this vision based approach is really what I think it should strive for. [SPEAKER_03]: Okay, so I'm curious about team, right? [SPEAKER_03]: How do you go about building your team to for the people at skip labs that are building these products? [SPEAKER_03]: You gotta have the right people at the helm.
[SPEAKER_03]: I'm curious about what to look for in those people to determine that they're the winning horses to join you. [SPEAKER_01]: So for me, I've been really blessed in that regard because I basically only worked with people who are used to work with. [SPEAKER_01]: So I have a good network of people and usually the people who I hire, those are people who I used to work with in the past and we agreed that it was really fun to work together and we wanted to work together again. [SPEAKER_01]: Then so 100% of the people who I
[SPEAKER_01]: people who I've worked with in the past and I wanted to work with them again. [SPEAKER_01]: But if you don't have that luxury then I really wouldn't know how to go about it because that's 100% of my recruiting is through my network. [SPEAKER_01]: So I don't think I have much insight here to bring to someone who's trying to put a kick-ass team together. [SPEAKER_01]: If they don't have a network
[SPEAKER_03]: Okay, Julian, let's move into scalability. [SPEAKER_03]: This will be interesting. [SPEAKER_03]: Scalability could be technical scalability for products for the preskipa for all of the things you're building at skip labs, but it could also be scalability for skip labs itself. [SPEAKER_03]: I think both are interesting topics. [SPEAKER_03]: I'm curious about how you approach those. [SPEAKER_03]: And if there's been interesting areas we've had to fight scale as you grow. [SPEAKER_01]: So far, no, I would say we've had, we haven't had big scaling issues so far with a product.
[SPEAKER_01]: I'd say I had scaling issues when I was back at the meta, but right now, the architecture that we have in place is relatively straightforward to scale, a couple of sharding here and there, load balances, but nothing too complex from a technical perspective. [SPEAKER_01]: Scaling the team with a team of 10 so far we don't really have scaling issues. [SPEAKER_01]: So I wouldn't say I have any interesting scaling war stories with Skiblab so far. [SPEAKER_03]: Julian, as you step out on the balcony and you look across all that you've built this far with Skiblab and it'd be even beyond.
[SPEAKER_03]: What do you most proud of? [SPEAKER_01]: I'll definitely skip the programming language skip. [SPEAKER_01]: I'm most known for hack because hack had a big impact at meta. [SPEAKER_01]: I think it's still the language they use the most at meta. [SPEAKER_01]: Maybe not these days, I don't know. [SPEAKER_01]: For their business logic for sure, in general I don't know. [SPEAKER_01]: But yeah, most people would know me for the work I did on hack. [SPEAKER_01]: But for me, skip is was really the most difficult.
[SPEAKER_01]: technical challenge I have undertook and I don't think I'll build something more complex in my career. [SPEAKER_01]: So I think that's that was the defining moment for my career for sure.
[SPEAKER_03]: Okay Julian, let's flip the script a little bit. [SPEAKER_03]: Tell me about a mistake you made and how you and your team responded to it. [SPEAKER_01]: I was working on skit and one of the things that we wanted for skit was to be able to compile it to WebSem. [SPEAKER_01]: And the reason is we back then had a bunch of ideas of why WebSemB would be a good target and I can get into the details. [SPEAKER_01]: But back then I was being very naive about it and I thought that because our run time was within in C++.
[SPEAKER_01]: We could compile that C++ to WebSemB.
[SPEAKER_01]: And I was very naive about it because I heard of M scripting, I heard oh yeah they have a compiler, but so I thought yeah how hard could it be, right? [SPEAKER_01]: We can take our C++ and compile it to WebAssembly. [SPEAKER_01]: I didn't expect it to work from the get-go. [SPEAKER_01]: I knew that would probably be a couple of fixes to do here and there, but I didn't realize how far it was. [SPEAKER_01]: It's absolutely impossible to just take the modern C++ code base, [SPEAKER_01]: and compile it to WebAssembly to inscript it.
[SPEAKER_01]: That's just impossible. [SPEAKER_01]: You can use C++ if that's a decision that you made from the get-go, but you're not going to adapt a C++ project and compile it to WebAssembly in just work. [SPEAKER_01]: Because there are just so many things that are insupported, so many things that don't work, like very simple things like exceptions and not supported. [SPEAKER_01]: At least if you want them supported, you have to turn on an option [SPEAKER_01]: and that option basically uses a shadow stack and then your program is 15x lower.
[SPEAKER_01]: So that's never going to work. [SPEAKER_01]: So here I am with my skip runtime and always an NC++. [SPEAKER_01]: I try to compile it. [SPEAKER_01]: I try to shake it as much as I could to make it work with mscript and nothing is but. [SPEAKER_01]: So I'm like, okay, fine, I'll rewrite the runtime in C. [SPEAKER_01]: And it was a very bare version of C because the C standard library does not compile to WebAssembly. [SPEAKER_01]: So it was C without a standard library. [SPEAKER_01]: So C without Maddox, C without pretty much anything that you would need to make C bearable.
[SPEAKER_01]: So it was super low level C. So some people in the audience are going to ask themselves, why didn't he just use Rust? [SPEAKER_01]: Two
[SPEAKER_01]: Two of the kind of stuff that I had to do was very nasty, so it's got a Garb's collector and to write a Garb's collector you need to. [SPEAKER_01]: There's a bunch of tricks that you have to use in the run time and steal bits and dual sorts of unsafe things, so I don't know that rest would have gained that much, so that's why it shows. [SPEAKER_01]: So here I am writing a runtime in C, in a version of C that doesn't have a standard library. [SPEAKER_01]: And I need basic thick, so I need to, so since I'm writing a runtime, I'm manipulating pages and I need to figure out if a pointer is part of this region or that region or these pages and that group of pages.
[SPEAKER_01]: So I need basic things like sorting and binary search and this kind of stuff to work. [SPEAKER_01]: Right? [SPEAKER_01]: So I need a source and of course I don't want to write my own sorting function so I go on the internet and I pick the first quick source implementation that I find. [SPEAKER_01]: So I take this function write few tests for it and it works and then I keep on using it for the rest of the runtime everything works, wait, but then I hit a stack all the flow. [SPEAKER_01]: and I realized by looking at the implementation that they had a very naive version of pick sort where the pivot that they were choosing was always the first element and I realized that as I mean that's a weird choice so I just adjust the algorithm so that it chooses a different pivot and I fix my stock overflow problem.
[SPEAKER_01]: All right, great. [SPEAKER_01]: The problem is it was one of those versions of C plus of C that is completely unreadable where you have an expression with plus minus minus everywhere and it's very compact and I didn't pay attention but in fact that version of quicksword only worked if the pivot was the first element. [SPEAKER_01]: So me changing the pivot to another element I in fact broke that algorithm. [SPEAKER_01]: but I broke it in a very subtle way and it was working most of the time.
[SPEAKER_01]: And so here I am with a version of QuickSort that passes all my tests, actually sorts almost always, but doesn't be, right? [SPEAKER_01]: And I end up with a bug, [SPEAKER_01]: down the road, that was like I was looking up a pointer in a bunch of pages, and the because those pages were not properly sorted, the binary search would say that the pointer was not in those pages, so it would treat stuck pointer as if it was reference counted. [SPEAKER_01]: And if it was reference counted, then you were supposed to have some memory every year right before the pointer where you had to convince a reference counts, which it was doing, and in fact was corrupting the data from the objects that were just before.
[SPEAKER_01]: And it took me forever to fix it. [SPEAKER_01]: So the hardest bug I had to deal with in my life was non-deterministic bugs, so bugs that come from you know waste conditions, especially at scale. [SPEAKER_01]: So these are definitely the hardest one. [SPEAKER_01]: But this was the hardest, deterministic bug that I had to chase and God I was banging my head against the water. [SPEAKER_01]: I will never copy paste code from the internet ever ever after.
[SPEAKER_03]: Okay, so let's move forward then. [SPEAKER_03]: What does the future look like for skip labs? [SPEAKER_03]: For what you're offering for skip up or other products you're thinking about building for where the industry is going all the things. [SPEAKER_03]: Tell me about what the future looks like. [SPEAKER_01]: I think the future is going to be very exciting for people who are building tools. [SPEAKER_01]: And skip is uniquely positioned to build tools that both scale and are incremental.
[SPEAKER_01]: Because that's really what we go down. [SPEAKER_01]: And so let's imagine the future with two companies. [SPEAKER_01]: And let's assume that both companies are actually shipping code using AI, right? [SPEAKER_01]: And of course not 100% of it, but a good bunch of the diffs that they produce, let's say in 5 10 years for now, will be written by AI. [SPEAKER_01]: So if company A and company A, you have an AI that's producing changes. [SPEAKER_01]: And every time there's a change that occurs, it's let's say a 1-million-line codebase, you have to re-run all the tests, you have to run circles, see I and whatnot, and then you have to deploy, and that takes maybe an hour.
[SPEAKER_01]: Right. [SPEAKER_01]: Company B, the whole tool chain is incremental. [SPEAKER_01]: the code itself is also reactive, stashing, criminal. [SPEAKER_01]: So when a diff comes in, you can take it in less than a second and deploy the change also in less than a second. [SPEAKER_01]: If those two companies are competing, which one do you think is going to win, right? [SPEAKER_01]: So [SPEAKER_01]: That's a rhetorical question, obviously, and so I think given that AI is now in the mix, the bottleneck is going to switch to tooling very soon.
[SPEAKER_01]: I don't, it hasn't happened yet because the tokens are still too slow to be generated. [SPEAKER_01]: But it's only a matter of time. [SPEAKER_01]: We are investing a ton of money into making those models smaller and faster. [SPEAKER_01]: And also in hardware, the amount of money spent on this kind of stuff is unprecedented. [SPEAKER_01]: I think in human history, so these models are going to get faster. [SPEAKER_01]: Once they get, let's say, $100,000 times faster. [SPEAKER_01]: The bottleneck is going to become totally.
[SPEAKER_01]: They will produce a ton of code, and we won't have the infrastructure to take into account that code, to take that code in. [SPEAKER_01]: And that's where the active programming kicks in, and that's where things skip labs can really shine.
[SPEAKER_03]: Let's watch the U Julian who influences the way that you work.
[SPEAKER_01]: There are people who I worked with in my career, but most people wouldn't know them. [SPEAKER_01]: My personal hero, when it comes to programming, is Fabri's Bela. [SPEAKER_01]: So he programmed FFM Peg, he's written QMU, he's written all sorts of things. [SPEAKER_01]: Everything he writes is everything I like, it works very fast, it's well put together, very useful to a lot of people, so yeah, he's a personal hero of mine. [SPEAKER_01]: Outside of him, oh yeah, there he is, he's a creator of OCaml and he also now has his driving comfort.
[SPEAKER_01]: I don't know if he's still doing that, but he was back in the days. [SPEAKER_01]: So he's written a secumpiler, [SPEAKER_01]: that is proven to be correct formally, but his first project was OCaml, so he was he also had a lot of inference on me. [SPEAKER_01]: And what they both have in common, which I think is what I like the most, in programmers, is when a programmer is both good at theory and practice. [SPEAKER_01]: So, I like when somebody has been educated on theory, they understand whatever theory it is they're working on, so it could be algorithmic if that's what they do, it could be programming languages, it could be logic, it could be distributed systems, it doesn't really matter, but I like the fact that people have had a formal education on certain things, and then when those same people are also extremely pragmatic, [SPEAKER_01]: and just love to ship stuff that actually works, that is something that just makes my eyes sparkle.
[SPEAKER_03]: Julian, last question. [SPEAKER_03]: So you're getting on a plane. [SPEAKER_03]: You're sitting next to a young entrepreneur who's built the next big thing. [SPEAKER_03]: They're jazzed about it. [SPEAKER_03]: I can't wait to show it off to the world and can we show it off to you right there on the plane? [SPEAKER_03]: What advice do you give that person? [SPEAKER_03]: Having gone down this road a bit. [SPEAKER_01]: A lot of it is not technical, so that's the advice I would give myself, if I were to engage on that path, when you are a technical person, you have a tendency to think that you can treat everything like a technical problem, and it's true to some extent and in fact, when that works, it's great.
[SPEAKER_01]: So for example, when you want to deal with both, so let's say you want to think about the growth of your company, if you think about it like an engineering problem, that's probably [SPEAKER_01]: So you should approach that's like an engineering problem. [SPEAKER_01]: But most of the problems you're going to face when you start a company will have nothing to do with how good your product is or how technical you are. [SPEAKER_01]: A lot of it is going to be convincing investors that you are the right company to invest it.
[SPEAKER_01]: And that is all going to be about narrative.
[SPEAKER_01]: You just want to show that you have the fastest products that can ship the most code or whatever metric that you're very proud about. [SPEAKER_01]: It's not going to be about that. [SPEAKER_01]: It's going to be broader narratives. [SPEAKER_01]: So the advice I would give that personal on the plane is make sure you understand that building a company is a lot more than just building a cool, technical product. [SPEAKER_01]: And there are people who've built amazing things, who've ended up nowhere because they did not listen to that advice.
[SPEAKER_03]: That's fantastic advice to point out. [SPEAKER_03]: Julian, thank you for being on the show today. [SPEAKER_03]: Thank you for telling the creation story of skip labs. [SPEAKER_01]: Thanks you, thank you for having me.
[SPEAKER_03]: And this concludes another chapter of Coat Story.
[SPEAKER_03]: code story is hosted and produced by no-alapart. [SPEAKER_03]: Be sure to subscribe on Apple podcast, Spotify, or the podcasting app at your choice. [SPEAKER_03]: And when you get a chance, leave us a review, both things help us out tremendously.
[SPEAKER_03]: And thanks again for listening.
Podbean