#15 – Tuomas Artman: Linear, sync engines, rethought startup MVP

And like from the get go, we knew that we just like, the way for us to win was to build Something that was excellent, like build a product that would just feel so good that you wouldn't want to use anything else. You have to build something much better in order to to be able to gain market share. And convince users to switch over. And because our mission is to help companies be better at building software, like, We should make a product that is an inspiration to them as well.

So we should make sure that, know, when they use the product, they're like, oh, man, like, ooh, this feels good. Like, I want to make my product as good as this freaking project management solution. Because if you can make an issue tracker that is, that is aspired to, then like, then you can make any, any application as, as, as nicely, like an issue tracker is hard to pull off as being a very nice and cool looking and, intuitive app. Welcome to the Local First FM podcast.

I'm your host, Johannes Schickling, and I'm a web developer, a startup founder, and love the craft of software engineering. For the past few years, I've been on a journey to build a modern, high quality music app using web technologies. And in doing so, I've been following down the rabbit hole of local first software. This podcast is your invitation to join me on that journey. In this episode, I'm speaking to Tuomas Artman, co founder and CTO of Linear.

Prior to Linear, Tuomas had already built Sync engines for over a decade at companies, including Groupon and Uber. In this conversation, we explore how local first and the focus on software quality was crucial for Linear's success and how the concept of a startup MVP should be rethought. Before getting started, also a big thank you to Rosicorp and PowerSync for supporting this podcast. And now my interview with Tuomas. Welcome Tuomas. So nice to have you on the show.

It was such a pleasure to also have you in Berlin for the Local-First Conference a couple of months ago, and super excited now to dig in even deeper into so many things local-first with you. Would you mind introducing yourself? Yeah, of course. Um, and thanks for having me and having me at the local first conference, which was I guess the first conference that, you know, was about local first, which was awesome. I thoroughly enjoyed it. I'm Tuomas. I've been engineering my whole life.

Like I started way back in, in 96, doing CD ROM multimedia presentations. if you can imagine, when the internet was sort of not there yet, if you ever had a Nokia phone that usually came with the CD ROM, with instructions on how to use that phone. Chances are that, that was made by the company that it was working for, or even by me. I did a few of those as well. but you know, ever since then, obviously the intern came around much, much more interesting.

I, started the consultancy for nine years until I realized that, that's not what I want to do. Did startups a few in Finland, went to China for a year, doing a startup there. until I got the opportunity to move to, Silicon Valley, joint Groupon, and later Uber. and, finally, I found myself as the co founder of Linear, you know, six years ago. and, I've been, working on essentially the harder technical problems.

I do enjoy working on products, More, but, somebody needs to take care of all the tech stuff. so I found myself, like, working on the sync engine in the early beginnings, and, that's what I'm still, working on. So I've, done anything from CD ROMs back in the day to sort of, you know, early web HTML applications, then going into mobile. and now I'm doing sort of, sync engine and infrastructure.

So I'm, I'm literally have gone, full round and I'll end up with, probably doing CD ROMs in the future as well.

That is super impressive and very inspiring. When you've been building software got shipped on CD ROMs, I was four years old in 96. But. It seems like a theme throughout at least the later years of your engineering career and path has been sort of like gravitating towards syncing engines. So when was the first time you thought about the concept of syncing engines and used the term?

Um, that was in the consultancy back in, Finland, like we had a consultancy doing all kinds of, you know, campaign stuff and internet things. Um, Flash was pop then, um, and, you know, we did a lot of Flash campaigns and Metro Media had this, plugin called Shockwave. I don't know if you remember. and it had a 3D component, so you were able to do, 3D accelerated games on it.

and we did one of these games, and it was a sort of multiplayer shoot 'em up game, which was amazing back then, and I loved it, and it looked, you know, super awesome. and it, it was multiplayer. It was like four people against four people. so it, it needed What I would call a sync engine, like you needed to sort of, you know, send over the coordinates of, you know, all of these ships. it was, you know, fully real time, 3D rendered, stuff, so it needed to be really, really fast.

And that was, you know, the first time I wrote, could be described as sync engine, where you would annotate some properties saying, like, these need to be transferred to all the players in that room, and it would automatically pick up on those and then send them over whenever they changed, which happened, like, effectively, locally, then, the Client code would just change those properties.

So that still looks very similar to what we have today, where, like, you annotate your properties, and then they automatically get picked up and sent over to the server to do something. So that was the first time I built a very simple sync engine, a bit more complicated. One, I built one in China for this, you know, I was working at a gaming company or a gaming startup that had a lot of smaller teams building games for, one of their portals that they had.

And I was, one of the CTOs there, like we had two CTOs, weirdly, like a Chinese CTO and then me. And I was responsible for sort of the, trying to build out a common stack for, their real time games. So I built another sync engine, and this time with Yeah, I don't remember what the first one was built on, even, but the second, like, my second sync engine was built with Node. And it had a Flash client and a Unity 3D client.

And it would essentially do the same thing as, know, the first one that I built. Like, it would pick up properties and send them across the room. It was a bit more intelligent. Like, it did more stuff. And it became, better. And then my third sync engine was built for Groupon when I joined, um, in San Francisco in 2000, probably 12. and I was working on a point of sale application, for high end restaurants. Like you would have an iPad in the, or multiple iPads in the menu.

and you could take orders, you could swipe credit cards, you could sort of, print out tokens to the kitchen for them to prepare the food. and all of these iPads need to be in sync. Cause. Otherwise, you could take sort of the order twice, or you could charge the customer twice. So, I was like, hell, I know how this stuff works. They had a very complicated thing built that just didn't work very well, and they wanted to pull it out. And I was like, I can try something.

I can sort of, you I tried to reinvent how this should look like, so I built in a sync engine, this time with Objective C, and a Node backend, because, I was pretty good at that already. And, yeah, it shipped into production, it would synchronize all the iPads at the menu, and just make sure that everything was nice and tidy. And it had offline support, even. Even back in the day, because, um, we realized that, many of the customers had, pretty, flaky Wi Fi.

And so you would, constantly lose, your connectivity to the backend. and we want to do something about it. So it would, you know, buffer all these requests on the iPad. And I think it tried to even talk to the other iPads to synchronize between them before sending it out. to the internet, and that sort of worked, but, you know, obviously immediately somebody, somebody took it, to the next level. And, we never said that there was offline support.

We've just said, like, you can turn your, you know, Wi Fi off for a second. And we had built in these precautions of like, what happens if you don't have connectivity and you, you take a credit card charge? we would store, that credit card securely.

On device, like encrypted, and make sure that, you couldn't get at it, you know, otherwise, and then when you got back, you would replay those, those orders and, hopefully they would go through, obviously it wasn't no guarantee because we couldn't check with the payment provider, whether that been true, that went through, so we never anticipated for anybody to sort of be offline for a long time.

And then there was this company that operated the train across the Rocky Mountains, and they had a restaurant car. And what they immediately did, they bought the software, which was called Breckrum, and they started just charging everybody. in that restaurant car for two days. Like, two days they didn't have any Wi Fi connectivity and took all these charges and then, regained connectivity once the trip was over and, luckily it all worked out.

yeah, it could have gone really wrong and would have been very, very expensive. but, I don't know what happened to that. We probably told them to never do that again. and, it wasn't really meant for, meant for that, but. Yeah, so that was the third sync engine that I, that I wrote. and the fourth one was for Uber. I mean, I joined like literally every single company I've done in, in, in the past, five companies. I've built a sync engine, engine for them.

Um, At Uber, I joined at a time when hyper growth was just going on. I think we were 300 engineers when I joined. Later we will be like 4, 000. And I tried to build a sync, or I actually did build a sync engine with a Go backend together with a former colleague of mine who was a Groupon as well. And we shipped a sort of, small beta product out on it.

Like, I think if I remember correctly, it was sort of a courier service in New York where you could Just order a car and the car would come and pick up your stuff and then you could sort of, see him deliver those things in your city and we built that thing in effectively a week. Like the sync engine obviously took quite a bit of time to put together.

But after that, building the application was a week and with that in mind, I, went to, my managers and, tried to explain to them how, how freaking awesome it is that you can build an application that does, sort of, all of this out of the box in a week and we should sort of just, put the whole Uber application onto this.

And I sort of got the green light to try to do it but I just wasn't able to, like, the company was moving so quickly and everything was just, on fire all the time around me that nobody really cared about, like, my nice initiative to sort of put a sync engine in. And it sort of bothered me very much because, like, even a year later, like, the way that Uber client did sync was what we call ping.

It would, every three seconds, call the server and receive everything, everything that it knew in this one huge packet, every three seconds it would go in and fetch the entire state of the world. And then like including, user accounts and credit card, credit card that you had in the application, all the cars around you. you know, Literally, literally everything. And it was like, pretty big packet. So it, it, it felt so inefficient. And, then we started optimizing it a bit and effectively build.

some small, you know, sync like functionality into it, but it was never the same. Like, I think that Uber would have been so much better off if they had, just gone with a sync engine, put it in and build it effectively like a local-first application out. It would have saved so many, so many engineering, engineering hours, and the product would just be much better because of that. Yeah, it didn't happen. So, that actually was open sourced.

It's called JetStream. Like, I think it's somewhere still on GitHub, if you want to check it out. We had a Swift client and a JavaScript client, and even an Android client and a Go backend. It was, it was interesting, but, unfortunately, never, never worked out.

And then came Linear. And um, yeah. What do you start, that product with, like, you just come out of Uber and you're sort of super excited about local-first and think that, that's the model of the future of how you should be building any kind of application that has a limited set of data. And I, I was excited just, trying out things and, getting back to web, like I hadn't worked on, on, on web technologies in, in ages.

It probably was like six years that I had spent on mobile, mobile engineering. So when I got back, like I was like, holy crap, like what is all this React stuff? Like this, this looks awesome. And the technology has just, progressed so much that I you know, had to learn a lot of stuff, which was super exciting.

And the first thing that I, that I did, like, , Jory and I got together on hacking on, on just some issue tracking, because, we were excited about or we weren't excited about this space, but we thought that somebody should, do something about it should figure out like, to do a project management system that actually worked nicely. Because we had heard all these stories at our respective companies of like, how, how people just disliked whatever they were using back in the day.

And we were like, oh, it sounds like an interesting challenge. And so we started, effectively just. hacking on it. And through just making a few prototypes with a local-first architecture, we were like, holy shit, this is pretty good. You can, rather really quickly build something that is immensely fast and is real time. And it just feels like a modern application that, isn't really a web app anymore, but just a desktop app that just runs in your browser. That is fascinating.

So through those technical prototype explorations, you build for yourself the conviction, Oh, we can build something much better. And that has then led to the building, the conviction to start out Linear. Do I summarize the starting point there correctly? I think so. Like, so we were struggling with the, with starting the company or not struggling. Like we, we didn't want to spend 10 years of our time doing project management because it felt such a boring space to be initially.

Like when you think about like, we were always like, very often we we're just having a drink first with only Jory. And then we tried to, recruit Kari as well. But he was even less interested in, in this space, like project management, what the hell and We always had the, the weird, idea of like, it seems such a simple thing to do, like, it seems like such an opportunity to build, start with an issue tracker, because like, you don't need much more than that in order to sort of cater to startups.

And it felt like such a market opportunity to build something really good in that space. And it really shouldn't take too much time. Like, it was a relatively simple application and we immediately knew that. We would be able to build it. But we always came back to the idea, like, why hasn't anybody else done this before?

And thinking about that problem so many times, we were like, the only the only reason we could come up with was that nobody who sort of was able to create beautiful applications wanted to spend their time on project management. And thus, nobody had done it before. And we were sort of struggling with the same thing as well. Like, We didn't want to spend our time with project management. Like, it felt like an industry that was kind of boring until later.

And, my co founders might have a very different, view on, on how this happens. This is how I felt. Like at some point at least I understood like that it's, it's not about building a project management solution. Like it's, it's about helping companies be better at building software. And that sort of became our mission statement in, in the early days, like helping companies be better at building software. And that was sort of a selfish mission as well.

Like I enjoy using software, like I, I love using, great applications and, when the iPhone came around like that, that mechanism of using, your mobile phone in a, in a very different manner in a much more intuitive manner was, awesome. And I wanted to enable people. To just build better software so that I can use it myself. And I think we did these sort of, technical trials at the same time as well.

Like we did some prototyping and I was, I was just hacking with Couchbase or some other tech to sort of, put together a few, few demos just to, catch up with. With the rest of the web stack that I hadn't used in ages. but yeah, that's, that's sort of how we, how we got started. And like from the get go, we knew that we just like, the way for us to win was to build Something that was excellent, like build a product that would just feel so good that you wouldn't want to use anything else.

Because, like, again, the incumbent solutions have been around for, for ages and they're so ingrained in all the software companies. You have to build something much better in order to to be able to gain market share. And convince users to switch over. And because our mission is to help companies be better at building software, like, We should make a product that is an inspiration to them as well.

So we should make sure that, know, when they use the product, they're like, oh, man, like, ooh, this feels good. Like, I want to make my product as good as this freaking project management solution. Because if you can make an issue tracker that is, that is aspired to, then like, then you can make any, any application as, as, as nicely, like an issue tracker is hard to pull off as being a very nice and cool looking and, intuitive app. Totally.

I'm friends with some of the folks who built Wunderlist back in the days. And I mean, I think that there's a lot of similarities there where I don't think there's like anything sexy about a to do list. But yeah, Wunderlist was so well built and felt so great to use. I think there's a lot of similarities there. And yeah, if you think about it, like a issue tracker is sort of like a more evolved to do list.

And this was like over a decade ago, and I think you've now just set the new bar of what a high quality app looks like. Where did you put your focus on when you said, okay, we want to, to build an app that feels great. And so the early technical explorations were also like an ingredient was snappy data with that sync engine, but which other parts did you feel like this is what we have to really get right that otherwise it won't feel good?

Yeah. So we have three points three things that we want to achieve, like Superhuman was around back then. So Superhuman was an inspiration to us. Like their command menu was, an inspiration. So the, the first, like we started using Linear, the, the week we started building it. So we have all the old tickets in, in there, you know, still. And the first ticket that is in Linear LIN1 is about implementing the command menu.

The first thing that you start with when building a product is implement a command menu like that. That tells you something about sort of the. Yeah, the interest that we had, like, we wanted to play around with, with sort of new ways of building UI and new ways of, keeping or making our users sort of, be super users without having anything else in the app yet. So that was the first thing that Jori started implementing. And I, I started implementing the sync engine cause like we like, yeah.

So the first thing was like, we need keyboard shortcuts and command menu. Like we need to enable the application to be super fast for, for super users. So if you're a, you know, high end engineer that just wants to get, things done very quickly in their issue tracking software, we should enable you to just, use keyboard shortcuts and the command menu to get things done. The second one was that, the application should feel like an application, like a native application.

We, like, we knew that we couldn't build a native app because then we would have to do a Windows version and Linux version and it would just, and a web version as well, because, like, often you, you, don't have your computer with you or you have your iPad and you just need to sort of go onto the internet and see your tickets. So we were like, well, we need to cut corners there, but let's try to make an application with web technologies that feels like a native application.

So that was the second thing. And then the third thing was sort of the real time aspect of it. Like, we wanted it to feel real time. Again, coming from these other solutions that we had used ourselves like, it was a thing back in the day when, you had to refresh the page in order to see if anybody else has updated it. It's kind of strange that that was the case. There was no background push, for most of these, these tools and everything was a page load.

And you know, maybe a fourth one was the speed as well. You could couple that with the sort of native application. Like, speed of the app, like, I mean, native application is fast. So, our web application needed to be fast as well. And one concerning thing that, happened, or not concerning, but a weird thing, was which relates to sort of not trusting everybody's feedback.

I, when we had an early prototype of the application with the command menu and keyboard shortcuts, and it was super fast and all that I showed it to a friend of mine in Finland when I was here, here on vacation and you know, showed him all the, all the cool things that I thought were super exciting. Like the, the, the quickness of it and the real time aspect of it. I had two windows open and then I changed here. It changed here. and, he was like, well, I don't really get it.

Like I, my current thing is, is fast enough. Like I really don't need the speed. I don't really use keyboard shortcuts. Who needs that real time stuff? And I was devastated by that feedback. I was like, what the hell? Am I wrong or is my friend just wrong? It turns out my friend was wrong. And those three things are the things that we're known for today. And that people appreciated the product. The quickness of it.

The ability of using keyboard shortcuts to do many, like, all operations effectively. Maybe not so the real time aspect, like, nobody calls out the real time aspect of it, but I think that comes as a given, like, in a modern time, you'd expect your application to be up to date without you having to refresh. The page, it would have all kinds of problems if it didn't do that. So, so yeah that's why, why I started with the sync engine.

Like, I'm thinking about a regular sort of, startup story or a journey of a startup, like those are the last things that you should do. Like, the common knowledge is always, build a, quick and early MVP to try out your ideas. Get in front of users. And we spent like half a year building out, the sync stack and the command menu and all this, all this stuff. And I think that was, that was a great success.

Like, it could have had a very different outcome if you had just built an issue tracker before and then in the end, try to sort of hinge in a sync engine or replace whatever we had built, as a REST API, and put it into a Sync Engine stack. So I think we we totally did the right thing, at least in hindsight of, focusing on, on sort of the tech first and obviously the design as well. Like Kari jumped in and started doing, designs and it took us some time to, get it right and, and make it work.

But the first version that we launched was already looking very much, of, of what we have today. I see so many parallels to also how I intuitively tried to build Overtone the, the music app where I think it was probably after I implemented like initial list of tracks and some playlists where you could switch between those lists of tracks. I remembered, okay, I'm not going to just click on those playlists. I have to use a command menu for that.

So, I think also at some point where I just needed a break from, like, many of the more low level harder SQLite things. I treated myself to implementing that command menu and I haven't now attached it for two years and it just works and makes the app feel so nice. And that's always like, it's one of those features where someone sits next to you and he sees you using that and it's like, Oh, what is that? And I think by now it's just shout's power tool.

And also the other aspects that you've mentioned that qualify that high quality goal that you set for software is like that native feel. Since I was also on a, on a similar fork in the road, like how should I build this? And I think one very interesting path could have been to say like, I'm, I'm a Mac OS user, I'm a iPhone user.

So. Like being also led by building things for myself, I could have selfishly just said, okay, I'm just going to build this in Swift for Mac OS and for iOS and that's it.

But then also with my web background, I knew that was going to be extra hard to do it for the web, but the distribution of the web is so powerful that it's probably going to worth that effort, but that has like, what drew me to, Native macOS, native iOS, is that like that notion of it's native and people ask like, Oh, is it native? And when you ask them, well, what, what does it mean for you? It's kind of gets fuzzy very quickly, but I think it's even more important that it should feel native.

And building a web app that feels native was always like a intuitive north star for me that I had to. Like pin down more and more. What does that actually mean for Overtone? For example, for Overtone, I have decided that the cursor is actually not becoming a pointer on when you click on a button, but it stays like a default one. I think this is one where I think the internet is deeply divided whether they know it or not.

But that, but I, I've like, I was led a lot by Mac OS Finder as an inspiration for how an app should feel. And so this is where I spend a lot of time just thinking about that and tweaking the little details. So this, this is a story about the, the only time that we've, you know faltered, in our judgment. We had, The pointer cursor in there for every button that you had, like, your pointer would turn into a finger and then we removed it because we're like, no native application uses that.

It's the right thing to do. Our application, should feel native as well, so it remains a pointer. We just highlight things underneath. And we shipped it, and, we had, we didn't have too many users back then. So every feedback was important to us. And I remember this one user mailing us in, like, literally, Maybe an hour later, after we shipped it, and his thing was like, Linear has went from the best application in the world to the worst.

Like, he was so unhappy with us removing the finger pointer from there that we got scared. We were like, oh shit, like, did we really do something that is ingrained in people's minds?. And there were a few other feedbacks that we got from that as well. So we put in a preference where, they could turn it, turn it on again. And it's still there. Like, if you search for your personal preference, you can turn on the finger. And after that, you haven't heard anybody do anything.

It's just when you change things that then people notice, but otherwise you come in and you don't really realize that, something's off because it, it, from the get go feels like a like an application. And that's, that's totally the way to go. I love that. That, that is such a meta thing to like pull out the, oh, let's make it a preference last resort. yeah, we should not have done that. we should have just stuck with it and be like, no preference. It is what it is.

So you've been talking before about sort of like that the typical startup MVP and best example by the project management where there's many project management tools is no longer really cutting it. And you've written a great blog post about that, which will be put in the show notes called Rethinking the Startup MVP, Building a Competitive Product. So in this article, you.

outline that, yeah, the traditional way of thinking about an MVP, where you just build something quickly, ship it quickly is maybe no longer cutting it today. Can you dig in a little bit more? Yeah, sure.

Cause it, it sort of was Was what we did with Linear effectively like, yeah, so Eric Ries invented the MVP you know, ages ago um, in a world where the internet has just came around and people were, you know, didn't know really what would work and what didn't like, I, it's hard to imagine that Airbnb was controversial back in the day, like when they went to YC you know, they, they barely got in because, people were like, who, who wants to invite strangers to your home and who

would want to sleep at a stranger's home? Like, that's, that's a crazy idea. And in those cases, obviously, like if you're, building out something that is, that is, completely new, where you even don't know if the idea works, an MVP is a great, thing to test it out. But unfortunately, we don't find ourselves in that situation anymore very often.

Now, maybe with AI we might have a bit more leeway in there, like there might be new things that come up that we need to try out because we just don't know if people are comfortable with. Doing some of the, things that will, will happen. But other than that, like it, most of the time you find yourself in a space where you're already competing with, with other people, like you're entering a space has already, you know, incumbent applications or services and, and you need to somehow be better.

Like, why would anybody use your product? if you enter that, then. Build something that is not as good, which is effectively what an MVP is. It's a, it's a quick and dirty hack to try things out. Like why would anybody jump over to you? if it's not better in any fashion. So there is an aspect of quality that you need to have in order to be better at, at, doing an application or service than the incumbent solutions.

So you need to rethink, you know, what, what it means to, to build out in that way and to build something, that can compete with the rest of the world. And that is like how, I think MVPs have changed. So if you think about a final product after it has maybe seen 10 years of investment, I think there's sort of two axis, at least.

One is the breadth of the functionality, whether you have that many features, if you're thinking about like a product like Linear, for example you've like added more and more features over the time. And another one is the depth and the quality aspect to each of those. And so what you're inviting people to think about and do is certainly increase more the effort on the qualitative side.

But that also begs the question, like, do you Just go for 10 years right away and like build up all the features and then launch. Or if you can't do that to be competitive with alternative existing products, then you kind of need to cut down the scope significantly on the features that you and the functionality that you initially launch with. So, and I think that's a really interesting and challenging exercise so how did you wrestle with like which features you pick?

So ultimately you need to do both. Like you need to have the depth and the breadth of features if you want to compete like at the large scale. But you know, then you run into the problem, like you can't build it. You don't have 10 years to build out a thing before you try it out. Well, Figma was a good example that you have some leeway there. Like you can work on the technology for four years and then ship it. And then actually, very quickly find product market fit. So it is possible. to do it.

And even like, they were probably quite niche as well. Like it's just a design tool, right? How hard can it be? Like there's not many features that you, that you need. But, but for us, it was like obvious that we can't go after sort of, larger customers immediately. Like we needed to scope down our set of functionalities and still find a consumer.. Or a target customer that would be happy with that. And for us, it was easy. And then, there might be cases where it's harder.

Like if you're trying to run, you know, create a banking application, like, yeah, you need to build up quite a bit of stuff in order. To be able to service even your first customer, like you need a bank, and that is a pretty hefty undertaking. But for us, like, we found this target customer, which is very, very small startups. Startups that have just been incubated, that are maybe, 2, 3, 4 people large that go through YC maybe. What do they need? Like, they don't need any project management.

They, they don't need a lot of functionality around labels. Like, they will have not too many tickets. Like, literally what they need is an issue tracker, a way of just tracking a few things and then marking them as complete. And that is the first thing that we built. We built an issue tracker, and even on our website said that, the issue tracker that you'll enjoy, you'll enjoy using. And I always hated that website.

Like, I, whenever I went there, I was like, no, this is not what we're building. We just have to lie to everybody that we're doing it now, because you want to focus on the target segment. And the, the idea always was to sort of, go and do project management. And even, even beyond project management, because, we wanted to help companies be better at building software, which encompasses literally everything in that space. But we had to start with sort of the small customers.

So that's what we focused on for the, for the first few years. Just make an issue tracker that works nicely. Start with small companies that were super excited to give you feedback. Like startups are great because like they, they know how it is, how hard it is to build a product. So they'll be happy to help, help you build your product as well while they're using you.

And so we had a lot of customers that, gave us a lot of feedback, which we could always invite for a Zoom call and just learn stuff from. then like the idea was to gradually grow with them. Like we knew that, once we got those customers, like it would probably stick around if we were able to, to, to grow our feature set as they grew.

And we knew they were growing, they would raise seed round then, eventually a series A, like 50 people series B. So we, we said like, I think we can build out the functionality of features that, that our initial customers need as they grow. . And it's sort of a wrap.

Like, we were able to have a few customers that started very early with us that now are sort of pretty huge companies and they've been sticking around with us for, for, for the entire duration and we've been just building more stuff for them. And that enabled us to just grow into larger customers. Starting to go into sort of, series A companies and growth companies and now sort of eyeing not, not yet the enterprise, I'll take, take some time more, but, established companies and IPO companies.

And that was sort of our strategy to, build something of the highest quality but just reduce the scope in the beginning so much because we were able to identify those target customers that didn't need much. I think that's fantastic advice and a great strategy how to go about picking the right narrow initial scope is not to primarily think about like, Oh, which features should we build first, but really starting out from like, okay. We are set on that we want to have that rethought MVP.

We want to aim really high in terms of the quality. Otherwise, like, why do we even get started in the competitive landscape? So that is, that is a fixed assumption. But then instead of thinking about which feature do we start first, is like, who as a customer segment do we start with? And that then implies the, the kind of features that are most important to start out with.

And I think that also aligns Hopefully nicely with the way how you can also charge for the product and build not just like a product that people use, but also pay for. And I'm not sure whether you got lucky there, but it seems like things certainly lined up very nicely for, for yourself there. And I think One aspect as well to maybe highlight there is that you've been seen as the company that other companies also aspire to as sort of a role model.

And I think that fit nicely with also your initial target customer segment.

Yeah, I, know, obviously it's, it's been mostly luck as with any startup. Like, we sort of stumbled into this way of working cause we enjoyed ourselves. Like we want to build nice things. And we had the, the, the lack of sort of, wanting to inspire people with, with our own products. That meant that we had to build the company in a certain way. That meant that we had to. Sort of hire people that we could trust to, not have to sort of look after them.

Because again, we were a remote company from the get go. And we wanted to make sure that, anybody we hired was just so good that, we knew that they could do whatever without literally, even talking to us if we went that way and just, you know, ship something, something awesome which again meant that, we hired effectively senior people not only that reason, but, the second reason was, was that we didn't know how to mentor junior people in a remote environment.

Like we were afraid that we would be doing them a disservice. Like, hiring somebody who needs to learn and hire them into a remote setting. We wouldn't know how to mentor them or how to grow them, so therefore we didn't. And later on we sort of find out that, it's actually pretty nice to having a very senior team around you that you just trust with building out the vision or even them having the same vision as you do, being able to drive the product forward because they're good engineers.

They know what they want from a, a, initially issue tracker and then project management tool. And that also meant that, you know, we were, it was hard for us to, to grow. Like, we wanted these, Overly qualified people which were super hard to find. So we grew slowly and in the end, like, we became profitable very quickly. I think two years in, we were profitable not because we wanted to or because we needed to or because that was the grandmaster plan. No, it was just, effectively luck.

Because we did these things, we grew so slowly and then the sort of revenue just overtook our expenses. And then like the downturn came and now everybody was sort of wanting to be the Linear, like wanting to do the same thing. Everybody's looking at like, where can we get profitable? We don't want to raise another round or ineffectively do a down round in that scenario. So. Everybody started looking at building things in a similar fashion.

So I think there's there's a lot of luck involved but also sort of, our passion and our backgrounds sort of directed us to build out this company this way. And we're still on that route. Like we, we still go down the same way, like we don't want to go through hyper growth and we will never, yeah, we will never hyper grow. Like I've seen that at, at, at Uber, Kari saw that in Airbnb Jori in Coinbase, I don't think anybody of us, really, Enjoyed that experience.

It was nice to see once but, we don't want to go through that again. Like, we want a product team that is excited to building something great and not just sort of a, cog in the big wheel of, working on some, remote infrastructure piece that maybe gets open sourced one day.

We want to make sure that, know, people who build Linear are sort of, they're, they're craftsmen that, enjoy building something beautiful and, want to see their work out there, and hopefully, are and can be proud of what they ship. So even though that's very humble of you saying most of it has been luck there is this this nice quote, which I think goes along the lines of luck favors the prepared. and I think there's a lot of intentionality also that went into building Linear.

I think it's always like this dance between open ended experimentations, like seeing, Oh, this is actually great. And then that becoming like a strong intention of like, Oh, this is, this is who we are. So, and I think you've probably maybe got lucky and like, like found a few things that you think, Oh, this is actually, we should really do that. But then you also embrace that and some companies call those like values or principles.

I think quality is certainly like a strong aspect there, but have you ever like formalized this in some way? Or if you bring on someone new to the company who hasn't been around over the years, how do you tell them like, Hey, this is who we are, how we do things, particularly given that you give people so much autonomy?

Yeah. Um, We, like, we just had our offsite in, in Mexico where we, flew the whole team in, and Kari was preparing some slides and, we've been talking about having, some sort of, value statement or values of the company and a vision statement. And we never did it because we always felt that like all the values of companies are somewhat fake. Like they. just tell what they want the company to be, but not really what the company is, right? Which never felt good to us as Finns.

Like we don't want to lie about things like. We're honest people. So, again, we didn't go down the vision or, the values route and we said like, ah, let's not have any values. So Kari started working on slides to sort of, show everybody how we got here and what we've done, over the past five years in order to, get to this place.

And he had like, five things that he pointed out that, that, that we had done and showed that slide deck to, to, to somebody on the team and that team member was like, huh, these look like values to me. um, so we were like, yeah, I'm, I, I guess they are values now. And our values are literally based on, on, What we've done in the past and what we want to continue doing. And yeah, there's a small, small set. Like the first one is trust. Like we, we've always trusted our engineers.

We've made sure that we hire people that, can work on their own, that can sort of bring something, something into, into the company. And we want to be open in, in, in our doings and we are open in our doings. And secondly, we've always built sort of with the customer in mind with hiring or, building our functionality by asking customers what they need.

So customer focus is one of the things that we've been doing, which is now a value of ours, not building things in isolation and making sure that we built something for our customers and that we built something that, people, people value and people need. Um, And it gets more, important as, as, you grow higher and you start working for functionality that, you wouldn't necessarily use yourself like for PMs or CEOs and CTOs at larger companies.

The third thing that sort of came out of how we, built the tool, like, we were sort of opinionated about, what we want to do. We didn't want to have that, like, we, it wasn't really a great value to have to be opinionated. That sort of sounds a bit negative. But what we, what we've turned it into is like, we built purpose built tools. tools, like we built for a specific purpose, for a specific target customer in mind. We want to, build software for software companies.

And if you stick with that, then we can build an excellent user experience and excellent functionality. If you start diverging and building everything for everybody, then, you sort of diluting, the aspects of the core of your application and it usually becomes. Less usable or less great. And then, the fourth one being quality.

We've always, wanted to build a high quality product and, put so much effort into making sure that, everything is It's great and working and works fast and all the small details are taken care of. And if you do all of these things well, then you inspire people. And that's sort of the last thing that we wanted to do. Like, we wanted to, be a company that helps companies be better at building software. And we think that inspiration is part of it.

Like, inspire people with the quality product that you've built for them and make them want to build an equally great experience. From what I can tell from the outside that all rings true and sounds very authentic that's more of an assessment of how I perceive Linear then. So I, I think you've met your, you've reached your bar of like that not being fake. But very authentic.

And I love how that is like also in terms of the yeah, that the craft of everything you're doing, how that's also rooted in the quality. And I think becomes like a core pillar of how the next generational product should be built.

So maybe taking one quick step back to the blog post you've written about the rethinking the startup MVP. Do you have a take on what is the rethought startup MVP? Is there like a new three letter acronym that people should use in the future? No, I, I, you know, I, I don't think there should be a three letter word for any of this. Like it'll really depend on what you're building. But you know, it is about competing in an existing market. Like, and being better at something.

What that something is, it might be literally anything. But yeah, you need to be better at something. Like, you can't just throw things at the ball and see what sticks because, the ball is already covered with, with all kinds of things. And people will just not, notice you or do anything about it. So what sort of advice would you have for builders and founders, people who want to build those next generational high quality products? What of the traditional wisdom, startup wisdom still applies?

So you mentioning sort of the, the hyperscaling maybe is no longer an attractive ingredient to, to get there. what would you recommend as like, what to focus on and what to be careful with? in, in order at least to get started, like, I think the most important thing to do is to, scope down and find, find a target segment that you can deliver something competitive for. Again, like we've talked about not being able to build everything for everybody.

So it's important if you can find a way to sculpt a new product and then, put something that people need. If you find something that, is a pain point for those users you immediately have a following. You can You know, sort of, build out a nice waitlist. And then with that waitlist, you can, you can iterate on your product and make it better.

Like you're, you have a waitlist and you have five users selected probably for that waitlist or maybe from your friends and you're iterating with them to make it better. And then you're happy when they have no feedback anymore. Then you go to your waitlist, you invite a few others to see if, they have new ideas of what you could build and how you could do things. So building things with, your customers is , it has been done obviously already, with startups.

Like that has been the wisdom so far and that hasn't changed. Like use your customers and use your, waitlist users to, iterate on the product to make it better until you're sort of ready to sort of go public and have everybody have a go at it.

Hyperscaling, like, obviously comes to mind when you're competing against somebody, like, Uber, it was, like obvious that, and the story of Uber is sort of sad as well, like, how it all went down, but obviously, like, in the end, it turned out good, but, being, being in Uber during that hyperscale time was pretty harsh. Like you have, you, you started off with building out a, prototype.

Like there was an iOS application that was a shitty backend that, I don't even know what it was written in, but it wasn't great. And then it started taking off a few users in San Francisco started using it, more black cars came available. And the, the thing where, when Uber took off was like when effectively sort of Lyft invented the model of, okay, let's have normal. People drive their own cars and be the driver. And suddenly you realize that's the way to go.

And now immediately they're in a competition. So now they have to get some money in and start scaling and start conquering some areas. And your infrastructure is still horrible. You haven't built out any of the stuff. You were just trying things out and your application looks horrible. And now you're suddenly having to run. And it takes off. And suddenly you've got tons of users coming in and you have to scale your infrastructure.

So you have to hire people as quickly as you can in order to just keep the flames, not reach the outer walls. And, two years later, when, when you've grown rapidly you, you end up with sort of having an infrastructure that is just. Coals and ash. Your team is burned out because they had to fight fires the entire time. And then you have to sort of replace that whole thing while you're still serving all the customers.

And, the weird thing was, and I, When I left Uber, they had started already sort of redoing much of that, that core infrastructure, and they were still at it like four years later, like we're still replacing the core bits of it. So it's, it's, it's horribly time consuming to scale something up quickly if you're not prepared to it. if you cannot do that, then I think you're in a much better, better place.

So that's what we've done, and that, is what I would suggest people, if they're, able, like, obviously, you need some money, and you need to have a bit of luck as well in order to, sort of, get initial customer interest and maybe a VC invest in you so that you can sort of build it out a bit more slowly. But our take on infrastructure and the backend always has been to sort of preemptively build everything so that, we're prepared for the growth. We know where the next bottlenecks are.

We might know that, a year from now, like, this thing won't scale anymore. So we started working on it early on so that we can sort of put implementations in place that, Just work and it will sort of, , work nicely and are architected well so that no surprises come, come along.

I think that's a nice segue. And we've been mostly covering sort of like the, the more cultural aspects of Linear so far, given this is the local-first podcast where we haven't yet talked too much except for the beginning about syncing, et cetera. And I don't think we need to spend another hour and hour going all the way there, but maybe just briefly connecting the dots there. I think the reason.

that what gives you this competitive advantage allows you to build that high quality product is that you have laid that foundation with the, the sync engine that takes out of like the, the picture, the entire complexity nightmare that, moving data from A to B and back to A can be. And so you've solved that and like on your shoulders of Giant, now the, the the, the product can be built by people who don't have all of that knowledge of data syncing.

And I think that is like a superpower that enables new products like Linear. Yeah. I mean, I do have a talk on, your conference on that. It's, it's probably available on YouTube as well. If you want to, if you want to check it out and put it into the, I don't know, notes for this, this, this podcast. But yeah, in short, like, The initial idea of the sync engine was not to make it developer friendly. That sort of happened as an afterthought.

And that was, in my mind, maybe the more more important aspect in the end.

Like, we wanted it to be fast and support offline mode and enable, the application to be quick and that is important, but what we found out what, what we like even more was that engineers would be able to just ship features much, much faster without having to think about a vast, area of, of A functionality that usually takes quite a bit of time, which is sort of error handling or networking, waiting for things to come back, supporting two different code paths for like when

you make your local changes versus when somebody else makes those edits for you. It's all abstracted away so that you don't need to think about these things. And it works for certain kinds of applications.

Definitely not all like if you're building, something that has, a lot of information or building a search engine and obviously not, like, you need to be able to have that data locally or pretty close to your, to your clients and be able to sort of fetch the pieces that you see on screens and then keep them up to date. But for anything that resembles an application.

That has sort of a limited set of data, and that data piece can, like, the amount of data that you have in the whole application can be large, but it still needs to be limited to, what you can browse at a , given point in time. And then this model just works absolutely beautifully. And. I sort of had this inkling at Uber already, like, I don't want to build anything in the traditional sort of networking model anymore. Like, I think sort of sync is such a better user or developer experience.

And, and the Linear, like, it's, it's clear that, I, I, I, well, I won't ever have a job after Linear, but, if I did, I, I, I would not work in any other way than just doing a sync engine again. I'm working in this environment because it just makes the, yeah, the developer experience so much faster and you can just ship functionality. Like, the easiest way to think about it is to literally say that, you're effectively just building the front end.

You have, data in memory, you've got data objects, which you render on screen. Then you modify those and that's it. Your feature is done. Everything else is handled, the synchronization, other users making the same edits. There's nothing else you need to do in order to build a feature. You just build the frontend and you're done with your entire feature. And that's pretty powerful.

And I think that also like empowers the already capable front end developers even further, since I think so far in this more traditional three tier web app where you have your, your front end that you're building. And then somehow like you're doing your, your fetches or RPC calls, et cetera. But then you also need to worry about like, okay, sorry, I need to serialize a bit of data over there, send it over here. Now I need to do something there. And like, Oh, what if.

This now changes and I need to send this back. If we can take that entire part out of the picture and front end developers are only dealing with like the, the client side state management, and that's it. And then either you have, you're relying on like a external sync engine that already works super well for you and you just need to integrate it, or you have the luxury of having someone like yourself in a team who builds your own, runs it, et cetera, which I think will be not always required.

I think the better the off the shelf sync engines will get the more products can already be built with that. And I think someone like yourself will rather be needed when a product really diverges from that, from that standard path. And so I would probably say that maybe in a couple of years from now, you could probably build something like Linear in terms of like the data syncing capabilities with like something like automerge, et cetera. Some of those.

Upcoming sync engines, and then it's probably rather a matter of can it also handle all of the scaling patterns and the extra user experience patterns that you want to really nail. I want to give an example of, like, how hard RPC actually is. Because I don't think people understand, like, before they've tried it out and then run into these edge cases, which always are edge cases. But once you run into them, you're like, oh, shit, what do I do now?

You need to rethink your entire architecture in order to make that, make that work. So A simple example, you've got, some sort of model object and it has two properties, and the user makes a change to those properties and sends it out as an RPC call. And you're also connected with a WebSocket to receive changes that other people do. Now, you send out the RPC call and wait for sort of acknowledgement for the server um, that, you know, everything was applied fine.

While that's going on, you receive a packet that, another user updated a certain property on that model object. What do you do? Like, and that becomes a really, really hard problem because suddenly, like, you, you really don't know what to do. Like, you can't rely just on that RPC call coming back. Because, again, your backend has multiple servers on it, so you can't rely on the timing of these things. It's not just, one single server running things, you know, serially.

It's multiple servers writing to the database, and then somebody is able to sort of send you a message, and the RPC call might go through. have already been sent but hasn't reached you yet because the network is slow. So when you receive that RPC code, you don't know if all the values in there are up to date. And now you need to figure out what to do with the updates for that model object.

And when you realize that, you're like, Yeah, I effectively need to implement another sync engine in order to make that happen. There needs to be a queue of sorts. And it becomes very, very complex. It's funny.

So like, it's a sort of a boiling frog situation where you start out with like your, your blissfully ignorant happy path of just like doing a fetch call to your backend and like, you get your data back and you test this on localhost with like your one client over there and your locally running server over there.

And like, everything just works and like you ship the feature, like you mark the issue as done on, on Linear, but then as it goes on production and like multiple users hit it, you get some really cryptic error messages that you, you even have a super hard time replicating that locally and you, you've spent hours on it. Hours and hours and days and days, like reading through log messages. Oh, we realized I actually, we don't have the right log messages for that in place.

So you'll need to spend another two weeks shipping that until you've like, finally have all of like the signal that you pull out of the giant bag of noise. To finally, like, have at least some confirmation of that something is going wrong. And once you have that hypothesis to even replicate it locally that's already takes heaps and heaps of time.

And then, like, The way how you pull yourself out of that is by step by step, applying changes that will ultimately lead you to a sync engine, but that's such a painful and inefficient way to get there. I think it's, primarily probably a problem to get, get us from.

A to B, like A being the status quo of the world right now, where like everything is built with the sort of RPC ish way to B where most products where it's a good fit are built with sync engines is probably just that instilled tribe knowledge that by now like all the technologies are sort of like.

Fostering that, that status quo where like all the libraries are built around RPC and we're, we're kind of blind to, yeah, it's kind of the spoiling frog situation where it's already cooking like crazy, but we don't realize it yet how much complexity we've built for ourselves. And how simple things could be. For sure. So it becomes simpler to not you know, implement that WebSocket and just have the user hit refresh to get the latest version of that page and be ignorant about or bliss.

Yeah, exactly. Which just dials up the temperature, but this is where I'm so excited about Linear and the success of Linear since people can't ignore products like Linear. There's like, Oh my gosh, what makes it so great? And then people want to.

understand how did you like explain the success and sure a lot of it will be attributed to like oh they have such those great people and they have such great design and they have that amount of like border radius but then a lot of it will also come down to the to the implementation this is what I where I hope that this will drive a lot of like Similar to how Nike focuses not as much on the products, but on the great athletes, you're the great athlete.

And I'm very much looking forward that people want to be like you. I really, enjoy working in a local-first environment, and I hope that everybody else picks that up as well. And there's starting to be tooling around it, around the, local-first as well, that you can use out of the box. That will probably work for most of the cases. It will still be hard to scale that up. But at least you can get started and maybe then figure out whether you need to build your own sync engine or not.

Perfect. I think we can leave it at that. Thank you so much for this amazing conversation. I was really looking forward to it. And Linear continues to be a huge inspiration for me. And it's been so, also like so interesting and fun to hear. That a lot of like what has inspired you and led you and like explorations you've done where you had sort of like what you do attribute to luck, but I think is also just great taste, et cetera.

That I see a bunch of parallels there to how I'm approaching Overtone that gives me a lot of energy and motivation to continue on my path. So thank you so much. Thank you so much. And waiting for that invite to Overtone. That's all, but when you're ready, like when you feel that you can, you can move on to the next customer group. Sounds good. I'll send you the magic link. Perfect. Thanks so much. Thank you for listening to the Local First FM podcast.

If you've enjoyed this episode and haven't done so already, please subscribe and leave a review. Please also share this episode with your friends and colleagues. Spreading the word about this podcast is a great way to support it and help me keep it going. A special thanks again to Rosicorp and PowerSync for supporting this podcast. I'll see you next time.