localfirst.fm

A podcast about local-first software development

Listen

Conference

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

The guest of this episode is Tuomas Artman, co-founder and CTO of Linear. Prior to Linear, Tuomas had already built sync engines for over a decade at companies like Groupon and Uber. This conversation will explore how local-first and software quality was crucial for Linear’s success and how the concept of a startup MVP should be rethought. 

Mentioned in podcast

Links:

Thank you to PowerSync and Rocicorp for supporting the podcast.

Transcript

Intro
00:00And like from the get go, we knew that we just like, the way for us
00:03to win was to build Something that was excellent, like build a product
00:08that would just feel so good that you wouldn't want to use anything else.
00:13You have to build something much better in order to to be able to gain market share.
00:18And convince users to switch over.
00:20And because our mission is to help companies be better at building software,
00:25like, We should make a product that is an inspiration to them as well.
00:29So we should make sure that, know, when they use the product, they're like,
00:31oh, man, like, ooh, this feels good.
00:34Like, I want to make my product as good as this freaking project management solution.
00:41Because if you can make an issue tracker that is, that is aspired to, then like,
00:45then you can make any, any application as, as, as nicely, like an issue tracker
00:50is hard to pull off as being a very nice and cool looking and, intuitive app.
00:56Welcome to the Local First FM podcast.
00:59I'm your host, Johannes Schickling, and I'm a web developer, a
01:02startup founder, and love the craft of software engineering.
01:05For the past few years, I've been on a journey to build a modern, high quality
01:09music app using web technologies.
01:11And in doing so, I've been following down the rabbit hole of local first software.
01:15This podcast is your invitation to join me on that journey.
01:19In this episode, I'm speaking to Tuomas Artman, co founder and CTO of Linear.
01:25Prior to Linear, Tuomas had already built Sync engines for over a decade at
01:29companies, including Groupon and Uber.
01:32In this conversation, we explore how local first and the focus on
01:36software quality was crucial for Linear's success and how the concept
01:40of a startup MVP should be rethought.
01:43Before getting started, also a big thank you to Rosicorp and PowerSync
01:48for supporting this podcast.
01:50And now my interview with
01:51Tuomas.
01:52Welcome Tuomas.
01:54So nice to have you on the show.
01:56It was such a pleasure to also have you in Berlin for the Local-First Conference
01:59a couple of months ago, and super excited now to dig in even deeper into
02:04so many things local-first with you.
02:06Would you mind introducing yourself?
02:09Yeah, of course.
02:09Um, and thanks for having me and having me at the local first conference, which was I
02:14guess the first conference that, you know, was about local first, which was awesome.
02:18I thoroughly enjoyed it.
02:20I'm Tuomas.
02:21I've been engineering my whole life.
02:23Like I started way back in, in 96, doing CD ROM multimedia presentations.
02:28if you can imagine, when the internet was sort of not there yet,
02:32if you ever had a Nokia phone that usually came with the CD ROM, with
02:35instructions on how to use that phone.
02:37Chances are that, that was made by the company that it
02:39was working for, or even by me.
02:41I did a few of those as well.
02:42but you know, ever since then, obviously the intern came around
02:45much, much more interesting.
02:46I, started the consultancy for nine years until I realized that,
02:50that's not what I want to do.
02:52Did startups a few in Finland, went to China for a year, doing a startup there.
02:56until I got the opportunity to move to, Silicon Valley,
02:59joint Groupon, and later Uber.
03:02and, finally, I found myself as the co founder of Linear,
03:05you know, six years ago.
03:07and, I've been, working on essentially the harder technical problems.
03:10I do enjoy working on products, More, but, somebody needs to
03:14take care of all the tech stuff.
03:16so I found myself, like, working on the sync engine in the early beginnings,
03:20and, that's what I'm still, working on.
03:22So I've, done anything from CD ROMs back in the day to sort of, you know, early web
03:27HTML applications, then going into mobile.
03:30and now I'm doing sort of, sync engine and infrastructure.
03:33So I'm, I'm literally have gone, full round and I'll end up with, probably
03:37doing CD ROMs in the future as well.
Sync Engines
03:39That is super impressive and very inspiring.
03:42When you've been building software got shipped on CD ROMs,
03:46I was four years old in 96.
03:48But.
03:49It seems like a theme throughout at least the later years of your engineering
03:54career and path has been sort of like gravitating towards syncing engines.
04:00So when was the first time you thought about the concept of
04:05syncing engines and used the term?
04:07Um, that was in the consultancy back in, Finland, like we had a consultancy
04:11doing all kinds of, you know, campaign stuff and internet things.
04:14Um, Flash was pop then, um, and, you know, we did a lot of Flash campaigns and Metro
04:19Media had this, plugin called Shockwave.
04:21I don't know if you remember.
04:22and it had a 3D component, so you were able to do, 3D accelerated games on it.
04:27and we did one of these games, and it was a sort of multiplayer shoot
04:30'em up game, which was amazing back then, and I loved it, and it
04:33looked, you know, super awesome.
04:35and it, it was multiplayer.
04:37It was like four people against four people.
04:39so it, it needed What I would call a sync engine, like you needed to sort
04:44of, you know, send over the coordinates of, you know, all of these ships.
04:47it was, you know, fully real time, 3D rendered, stuff, so it
04:50needed to be really, really fast.
04:51And that was, you know, the first time I wrote, could be described as sync
04:55engine, where you would annotate some properties saying, like, these need to
04:58be transferred to all the players in that room, and it would automatically pick up
05:01on those and then send them over whenever they changed, which happened, like,
05:04effectively, locally, then, the Client code would just change those properties.
05:10So that still looks very similar to what we have today, where, like, you
05:14annotate your properties, and then they automatically get picked up and sent
05:18over to the server to do something.
05:21So that was the first time I built a very simple sync
05:24engine, a bit more complicated.
05:27One, I built one in China for this, you know, I was working at a gaming
05:30company or a gaming startup that had a lot of smaller teams building games
05:35for, one of their portals that they had.
05:37And I was, one of the CTOs there, like we had two CTOs, weirdly,
05:41like a Chinese CTO and then me.
05:43And I was responsible for sort of the, trying to build out a common
05:47stack for, their real time games.
05:49So I built another sync engine, and this time with Yeah, I don't remember
05:53what the first one was built on, even, but the second, like, my second
05:56sync engine was built with Node.
05:58And it had a Flash client and a Unity 3D client.
06:02And it would essentially do the same thing as, know, the first one that I built.
06:07Like, it would pick up properties and send them across the room.
06:09It was a bit more intelligent.
06:11Like, it did more stuff.
06:12And it became, better.
06:14And then my third sync engine was built for Groupon when I joined, um,
06:18in San Francisco in 2000, probably 12.
06:23and I was working on a point of sale application, for high end restaurants.
06:26Like you would have an iPad in the, or multiple iPads in the menu.
06:30and you could take orders, you could swipe credit cards, you could
06:32sort of, print out tokens to the kitchen for them to prepare the food.
06:36and all of these iPads need to be in sync.
06:38Cause.
06:39Otherwise, you could take sort of the order twice, or you
06:41could charge the customer twice.
06:43So, I was like, hell, I know how this stuff works.
06:47They had a very complicated thing built that just didn't work very
06:51well, and they wanted to pull it out.
06:52And I was like, I can try something.
06:54I can sort of, you I tried to reinvent how this should look like, so I built
06:59in a sync engine, this time with Objective C, and a Node backend, because,
07:04I was pretty good at that already.
07:07And, yeah, it shipped into production, it would synchronize all the iPads
07:11at the menu, and just make sure that everything was nice and tidy.
07:16And it had offline support, even.
07:18Even back in the day, because, um, we realized that, many of the
07:21customers had, pretty, flaky Wi Fi.
07:23And so you would, constantly lose, your connectivity to the backend.
07:26and we want to do something about it.
07:27So it would, you know, buffer all these requests on the iPad.
07:31And I think it tried to even talk to the other iPads to synchronize
07:34between them before sending it out.
07:36to the internet, and that sort of worked, but, you know, obviously
07:40immediately somebody, somebody took it, to the next level.
07:43And, we never said that there was offline support.
07:45We've just said, like, you can turn your, you know, Wi Fi off for a second.
07:49And we had built in these precautions of like, what happens if you
07:52don't have connectivity and you, you take a credit card charge?
07:56we would store, that credit card securely.
07:59On device, like encrypted, and make sure that, you couldn't get at it, you know,
08:02otherwise, and then when you got back, you would replay those, those orders and,
08:07hopefully they would go through, obviously it wasn't no guarantee because we couldn't
08:10check with the payment provider, whether that been true, that went through, so
08:15we never anticipated for anybody to sort of be offline for a long time.
08:20And then there was this company that operated the train across the Rocky
08:24Mountains, and they had a restaurant car.
08:27And what they immediately did, they bought the software, which was called Breckrum,
08:31and they started just charging everybody.
08:34in that restaurant car for two days.
08:36Like, two days they didn't have any Wi Fi connectivity and took all
08:40these charges and then, regained connectivity once the trip was over
08:43and, luckily it all worked out.
08:45yeah, it could have gone really wrong and would have been very, very expensive.
08:49but, I don't know what happened to that.
08:51We probably told them to never do that again.
08:53and, it wasn't really meant for, meant for that, but.
08:55Yeah, so that was the third sync engine that I, that I wrote.
08:58and the fourth one was for Uber.
09:00I mean, I joined like literally every single company I've done in,
09:03in, in the past, five companies.
09:05I've built a sync engine, engine for them.
09:07Um, At Uber, I joined at a time when hyper growth was just going on.
09:12I think we were 300 engineers when I joined.
09:15Later we will be like 4, 000.
09:17And I tried to build a sync, or I actually did build a sync engine with a Go
09:22backend together with a former colleague of mine who was a Groupon as well.
09:27And we shipped a sort of, small beta product out on it.
09:31Like, I think if I remember correctly, it was sort of a courier service in New
09:35York where you could Just order a car and the car would come and pick up your
09:40stuff and then you could sort of, see him deliver those things in your city and we
09:45built that thing in effectively a week.
09:46Like the sync engine obviously took quite a bit of time to put together.
09:50But after that, building the application was a week and with that in mind, I, went
09:55to, my managers and, tried to explain to them how, how freaking awesome it is that
10:00you can build an application that does, sort of, all of this out of the box in
10:04a week and we should sort of just, put the whole Uber application onto this.
10:09And I sort of got the green light to try to do it but I just wasn't able to,
10:16like, the company was moving so quickly and everything was just, on fire all
10:20the time around me that nobody really cared about, like, my nice initiative
10:24to sort of put a sync engine in.
10:26And it sort of bothered me very much because, like, even a year later,
10:33like, the way that Uber client did sync was what we call ping.
10:39It would, every three seconds, call the server and receive everything, everything
10:45that it knew in this one huge packet, every three seconds it would go in and
10:49fetch the entire state of the world.
10:52And then like including, user accounts and credit card, credit card that you had in
10:56the application, all the cars around you.
10:58you know, Literally, literally everything.
11:00And it was like, pretty big packet.
11:02So it, it, it felt so inefficient.
11:04And, then we started optimizing it a bit and effectively build.
11:08some small, you know, sync like functionality into it,
11:11but it was never the same.
11:12Like, I think that Uber would have been so much better off if they
11:14had, just gone with a sync engine, put it in and build it effectively
11:19like a local-first application out.
11:21It would have saved so many, so many engineering, engineering
11:24hours, and the product would just be much better because of that.
11:27Yeah, it didn't happen.
11:28So, that actually was open sourced.
11:30It's called JetStream.
11:31Like, I think it's somewhere still on GitHub, if you want to check it out.
11:34We had a Swift client and a JavaScript client, and even an
11:39Android client and a Go backend.
Linear origin story
11:44And then came Linear.
11:45And um, yeah.
11:47What do you start, that product with, like, you just come out of Uber and
11:51you're sort of super excited about local-first and think that, that's the
11:54model of the future of how you should be building any kind of application
11:57that has a limited set of data.
12:00And I, I was excited just, trying out things and, getting back to
12:04web, like I hadn't worked on, on, on web technologies in, in ages.
12:09It probably was like six years that I had spent on mobile, mobile engineering.
12:13So when I got back, like I was like, holy crap, like what is all this React stuff?
12:16Like this, this looks awesome.
12:17And the technology has just, progressed so much that I you know, had to learn a
12:21lot of stuff, which was super exciting.
12:23And the first thing that I, that I did, like, , Jory and I got together
12:27on hacking on, on just some issue tracking, because, we were excited about
12:31or we weren't excited about this space, but we thought that somebody should,
12:35do something about it should figure out like, to do a project management
12:38system that actually worked nicely.
12:40Because we had heard all these stories at our respective companies of like,
12:45how, how people just disliked whatever they were using back in the day.
12:49And we were like, oh, it sounds like an interesting challenge.
12:52And so we started, effectively just.
12:54hacking on it.
12:56And through just making a few prototypes with a local-first architecture, we were
13:00like, holy shit, this is pretty good.
13:03You can, rather really quickly build something that is
13:06immensely fast and is real time.
13:08And it just feels like a modern application that, isn't really a
13:11web app anymore, but just a desktop app that just runs in your browser.
13:16That is fascinating.
13:17So through those technical prototype explorations, you build for
13:21yourself the conviction, Oh, we can build something much better.
13:25And that has then led to the building, the conviction to start out Linear.
13:29Do I summarize the starting point there correctly?
13:33I think so.
13:34Like, so we were struggling with the, with starting the company or not struggling.
13:38Like we, we didn't want to spend 10 years of our time doing project
13:42management because it felt such a boring space to be initially.
13:46Like when you think about like, we were always like, very often we we're just
13:49having a drink first with only Jory.
13:52And then we tried to, recruit Kari as well.
13:54But he was even less interested in, in this space, like project management,
13:58what the hell and We always had the, the weird, idea of like, it seems such
14:03a simple thing to do, like, it seems like such an opportunity to build, start
14:08with an issue tracker, because like, you don't need much more than that in
14:11order to sort of cater to startups.
14:13And it felt like such a market opportunity to build something
14:16really good in that space.
14:18And it really shouldn't take too much time.
14:20Like, it was a relatively simple application and we immediately knew that.
14:23We would be able to build it.
14:25But we always came back to the idea, like, why hasn't anybody else done this before?
14:29And thinking about that problem so many times, we were like, the only the
14:32only reason we could come up with was that nobody who sort of was able to
14:37create beautiful applications wanted to spend their time on project management.
14:42And thus, nobody had done it before.
14:43And we were sort of struggling with the same thing as well.
14:46Like, We didn't want to spend our time with project management.
14:49Like, it felt like an industry that was kind of boring until later.
14:53And, my co founders might have a very different, view on, on how this happens.
14:56This is how I felt.
14:57Like at some point at least I understood like that it's, it's not about
15:02building a project management solution.
15:04Like it's, it's about helping companies be better at building software.
15:07And that sort of became our mission statement in, in the
15:10early days, like helping companies be better at building software.
15:13And that was sort of a selfish mission as well.
15:15Like I enjoy using software, like I, I love using, great applications and, when
15:20the iPhone came around like that, that mechanism of using, your mobile phone
15:24in a, in a very different manner in a much more intuitive manner was, awesome.
15:27And I wanted to enable people.
15:30To just build better software so that I can use it myself.
15:33And I think we did these sort of, technical trials at the same time as well.
15:37Like we did some prototyping and I was, I was just hacking with Couchbase or some
15:41other tech to sort of, put together a few, few demos just to, catch up with.
15:46With the rest of the web stack that I hadn't used in ages.
15:51but yeah, that's, that's sort of how we, how we got started.
15:53And like from the get go, we knew that we just like, the way for us
15:57to win was to build Something that was excellent, like build a product
16:02that would just feel so good that you wouldn't want to use anything else.
16:07Because, like, again, the incumbent solutions have been around for,
16:10for ages and they're so ingrained in all the software companies.
16:14You have to build something much better in order to to be able to gain market share.
16:18And convince users to switch over.
16:21And because our mission is to help companies be better at building software,
16:25like, We should make a product that is an inspiration to them as well.
16:29So we should make sure that, know, when they use the product, they're like,
16:32oh, man, like, ooh, this feels good.
16:34Like, I want to make my product as good as this freaking project management solution.
16:41Because if you can make an issue tracker that is, that is aspired to, then like,
16:46then you can make any, any application as, as, as nicely, like an issue tracker
16:50is hard to pull off as being a very nice and cool looking and, intuitive app.
16:57Totally.
16:58I'm friends with some of the folks who built Wunderlist back in the days.
17:01And I mean, I think that there's a lot of similarities there
17:05where I don't think there's like anything sexy about a to do list.
17:10But yeah, Wunderlist was so well built and felt so great to use.
17:15I think there's a lot of similarities there.
17:18And yeah, if you think about it, like a issue tracker is sort of
17:21like a more evolved to do list.
17:25And this was like over a decade ago, and I think you've now just set the new bar
17:30of what a high quality app looks like.
17:33Where did you put your focus on when you said, okay, we want to,
17:37to build an app that feels great.
17:40And so the early technical explorations were also like an ingredient was snappy
17:45data with that sync engine, but which other parts did you feel like this
17:51is what we have to really get right that otherwise it won't feel good?
Initial focus: Command menu, native feel, real-time
17:55Yeah.
17:55So we have three points three things that we want to achieve, like
17:59Superhuman was around back then.
18:01So Superhuman was an inspiration to us.
18:03Like their command menu was, an inspiration.
18:06So the, the first, like we started using Linear, the, the
18:09week we started building it.
18:11So we have all the old tickets in, in there, you know, still.
18:13And the first ticket that is in Linear LIN1 is about
18:17implementing the command menu.
18:19The first thing that you start with when building a product is
18:22implement a command menu like that.
18:23That tells you something about sort of the.
18:25Yeah, the interest that we had, like, we wanted to play around with, with
18:29sort of new ways of building UI and new ways of, keeping or making our
18:34users sort of, be super users without having anything else in the app yet.
18:39So that was the first thing that Jori started implementing.
18:43And I, I started implementing the sync engine cause like we like, yeah.
18:47So the first thing was like, we need keyboard shortcuts and command menu.
18:51Like we need to enable the application to be super fast for, for super users.
18:56So if you're a, you know, high end engineer that just wants to get,
18:59things done very quickly in their issue tracking software, we should enable
19:02you to just, use keyboard shortcuts and the command menu to get things done.
19:07The second one was that, the application should feel like an
19:10application, like a native application.
19:12We, like, we knew that we couldn't build a native app because then we would have
19:16to do a Windows version and Linux version and it would just, and a web version as
19:20well, because, like, often you, you, don't have your computer with you or you have
19:24your iPad and you just need to sort of go onto the internet and see your tickets.
19:29So we were like, well, we need to cut corners there, but let's try to make
19:32an application with web technologies that feels like a native application.
19:37So that was the second thing.
19:38And then the third thing was sort of the real time aspect of it.
19:41Like, we wanted it to feel real time.
19:43Again, coming from these other solutions that we had used ourselves like, it
19:49was a thing back in the day when, you had to refresh the page in order to
19:52see if anybody else has updated it.
19:56It's kind of strange that that was the case.
19:58There was no background push, for most of these, these tools
20:02and everything was a page load.
20:03And you know, maybe a fourth one was the speed as well.
20:06You could couple that with the sort of native application.
20:09Like, speed of the app, like, I mean, native application is fast.
20:13So, our web application needed to be fast as well.
20:16And one concerning thing that, happened, or not concerning, but a
20:20weird thing, was which relates to sort of not trusting everybody's feedback.
20:25I, when we had an early prototype of the application with the command menu
20:29and keyboard shortcuts, and it was super fast and all that I showed it to
20:33a friend of mine in Finland when I was here, here on vacation and you know,
20:38showed him all the, all the cool things that I thought were super exciting.
20:40Like the, the, the quickness of it and the real time aspect of it.
20:43I had two windows open and then I changed here.
20:45It changed here.
20:47and, he was like, well, I don't really get it.
20:49Like I, my current thing is, is fast enough.
20:53Like I really don't need the speed.
20:54I don't really use keyboard shortcuts.
20:56Who needs that real time stuff?
20:58And I was devastated by that feedback.
21:00I was like, what the hell?
21:02Am I wrong or is my friend just wrong?
21:05It turns out my friend was wrong.
21:07And those three things are the things that we're known for today.
21:11And that people appreciated the product.
21:13The quickness of it.
21:14The ability of using keyboard shortcuts to do many, like, all operations effectively.
21:19Maybe not so the real time aspect, like, nobody calls out the real time
21:22aspect of it, but I think that comes as a given, like, in a modern time,
21:26you'd expect your application to be up to date without you having to refresh.
21:30The page, it would have all kinds of problems if it didn't do that.
21:35So, so yeah that's why, why I started with the sync engine.
21:37Like, I'm thinking about a regular sort of, startup story or a journey
21:43of a startup, like those are the last things that you should do.
21:46Like, the common knowledge is always, build a, quick and
21:50early MVP to try out your ideas.
21:52Get in front of users.
21:54And we spent like half a year building out, the sync stack and the command
21:58menu and all this, all this stuff.
22:01And I think that was, that was a great success.
22:03Like, it could have had a very different outcome if you had just built an issue
22:08tracker before and then in the end, try to sort of hinge in a sync engine or
22:13replace whatever we had built, as a REST API, and put it into a Sync Engine stack.
22:19So I think we we totally did the right thing, at least in hindsight
22:23of, focusing on, on sort of the tech first and obviously the design as well.
22:27Like Kari jumped in and started doing, designs and it took us some time to,
22:32get it right and, and make it work.
22:34But the first version that we launched was already looking very
22:37much, of, of what we have today.
22:39I see so many parallels to also how I intuitively tried to build Overtone
22:45the, the music app where I think it was probably after I implemented
22:50like initial list of tracks and some playlists where you could switch
22:55between those lists of tracks.
22:57I remembered, okay, I'm not going to just click on those playlists.
23:01I have to use a command menu for that.
23:03So, I think also at some point where I just needed a break from, like, many of
23:08the more low level harder SQLite things.
23:11I treated myself to implementing that command menu and I haven't now
23:16attached it for two years and it just works and makes the app feel so nice.
23:20And that's always like, it's one of those features where someone sits
23:24next to you and he sees you using that and it's like, Oh, what is that?
23:28And I think by now it's just shout's power tool.
23:32And also the other aspects that you've mentioned that qualify that
23:37high quality goal that you set for software is like that native feel.
23:42Since I was also on a, on a similar fork in the road, like how should I build this?
23:47And I think one very interesting path could have been to say like, I'm,
23:51I'm a Mac OS user, I'm a iPhone user.
23:54So.
23:55Like being also led by building things for myself, I could have
23:59selfishly just said, okay, I'm just going to build this in Swift for
24:03Mac OS and for iOS and that's it.
24:07But then also with my web background, I knew that was going to be extra
24:12hard to do it for the web, but the distribution of the web is so powerful
24:18that it's probably going to worth that effort, but that has like, what drew
24:23me to, Native macOS, native iOS, is that like that notion of it's native
24:30and people ask like, Oh, is it native?
24:32And when you ask them, well, what, what does it mean for you?
24:34It's kind of gets fuzzy very quickly, but I think it's even more
24:38important that it should feel native.
24:41And building a web app that feels native was always like a intuitive
24:47north star for me that I had to.
24:49Like pin down more and more.
24:50What does that actually mean for Overtone?
24:53For example, for Overtone, I have decided that the cursor is actually not
24:58becoming a pointer on when you click on a button, but it stays like a default one.
25:03I think this is one where I think the internet is deeply divided
25:07whether they know it or not.
25:09But that, but I, I've like, I was led a lot by Mac OS Finder as an
25:14inspiration for how an app should feel.
25:17And so this is where I spend a lot of time just thinking about that
25:21and tweaking the little details.
25:23So this, this is a story about the, the only time that we've, you
25:27know faltered, in our judgment.
25:30We had, The pointer cursor in there for every button that you had, like,
25:35your pointer would turn into a finger and then we removed it because we're
25:39like, no native application uses that.
25:41It's the right thing to do.
25:43Our application, should feel native as well, so it remains a pointer.
25:46We just highlight things underneath.
25:48And we shipped it, and, we had, we didn't have too many users back then.
25:52So every feedback was important to us.
25:55And I remember this one user mailing us in, like, literally, Maybe an hour
26:00later, after we shipped it, and his thing was like, Linear has went from the best
26:05application in the world to the worst.
26:07Like, he was so unhappy with us removing the finger pointer
26:13from there that we got scared.
26:14We were like, oh shit, like, did we really do something that is
26:18ingrained in people's minds?.
26:20And there were a few other feedbacks that we got from that as well.
26:23So we put in a preference where, they could turn it, turn it on again.
26:27And it's still there.
26:27Like, if you search for your personal preference, you can turn on the finger.
26:31And after that, you haven't heard anybody do anything.
26:34It's just when you change things that then people notice, but otherwise you
26:37come in and you don't really realize that, something's off because it, it, from the
26:41get go feels like a like an application.
26:43And that's, that's totally the way to go.
26:45I love that.
26:47That, that is such a meta thing to like pull out the, oh, let's
26:51make it a preference last resort.
26:55yeah, we should not have done that.
26:57we should have just stuck with it and be like, no preference.
27:00It is what it is.
Rethinking the Startup MVP
27:02So you've been talking before about sort of like that the typical startup MVP and
27:10best example by the project management where there's many project management
27:14tools is no longer really cutting it.
27:17And you've written a great blog post about that, which will be put in the
27:21show notes called Rethinking the Startup MVP, Building a Competitive Product.
27:26So in this article, you.
27:29outline that, yeah, the traditional way of thinking about an MVP, where you just
27:35build something quickly, ship it quickly is maybe no longer cutting it today.
27:41Can you dig in a little bit more?
27:44Yeah, sure.
27:45Cause it, it sort of was Was what we did with Linear effectively like, yeah, so
27:51Eric Ries invented the MVP you know, ages ago um, in a world where the internet
27:56has just came around and people were, you know, didn't know really what would
28:00work and what didn't like, I, it's hard to imagine that Airbnb was controversial
28:07back in the day, like when they went to YC you know, they, they barely got in
28:11because, people were like, who, who wants to invite strangers to your home and who
28:16would want to sleep at a stranger's home?
28:18Like, that's, that's a crazy idea.
28:20And in those cases, obviously, like if you're, building out something that
28:23is, that is, completely new, where you even don't know if the idea works, an
28:28MVP is a great, thing to test it out.
28:30But unfortunately, we don't find ourselves in that situation anymore very often.
28:35Now, maybe with AI we might have a bit more leeway in there, like there might
28:40be new things that come up that we need to try out because we just don't
28:44know if people are comfortable with.
28:46Doing some of the, things that will, will happen.
28:49But other than that, like it, most of the time you find yourself in a
28:52space where you're already competing with, with other people, like you're
28:56entering a space has already, you know, incumbent applications or services
29:02and, and you need to somehow be better.
29:04Like, why would anybody use your product?
29:07if you enter that, then.
29:08Build something that is not as good, which is effectively what an MVP is.
29:13It's a, it's a quick and dirty hack to try things out.
29:15Like why would anybody jump over to you?
29:17if it's not better in any fashion.
29:19So there is an aspect of quality that you need to have in order to be
29:24better at, at, doing an application or service than the incumbent solutions.
29:29So you need to rethink, you know, what, what it means to, to build out in that
29:33way and to build something, that can compete with the rest of the world.
29:37And that is like how, I think MVPs have changed.
29:41So if you think about a final product after it has maybe seen
29:4610 years of investment, I think there's sort of two axis, at least.
29:50One is the breadth of the functionality, whether you have that many features, if
29:57you're thinking about like a product like Linear, for example you've like added
30:02more and more features over the time.
30:04And another one is the depth and the quality aspect to each of those.
30:11And so what you're inviting people to think about and do is certainly increase
30:17more the effort on the qualitative side.
30:21But that also begs the question, like, do you Just go for 10 years
30:26right away and like build up all the features and then launch.
30:29Or if you can't do that to be competitive with alternative existing
30:33products, then you kind of need to cut down the scope significantly on the
30:39features that you and the functionality that you initially launch with.
30:43So, and I think that's a really interesting and challenging
30:47exercise so how did you wrestle with like which features you pick?
30:52So ultimately you need to do both.
30:55Like you need to have the depth and the breadth of features if you want
30:58to compete like at the large scale.
31:01But you know, then you run into the problem, like you can't build it.
31:03You don't have 10 years to build out a thing before you try it out.
31:08Well, Figma was a good example that you have some leeway there.
31:11Like you can work on the technology for four years and then ship it.
31:15And then actually, very quickly find product market fit.
31:17So it is possible.
31:18to do it.
31:19And even like, they were probably quite niche as well.
31:22Like it's just a design tool, right?
31:26How hard can it be?
31:27Like there's not many features that you, that you need.
31:30But, but for us, it was like obvious that we can't go after sort
31:33of, larger customers immediately.
31:34Like we needed to scope down our set of functionalities
31:38and still find a consumer..
31:40Or a target customer that would be happy with that.
31:43And for us, it was easy.
31:45And then, there might be cases where it's harder.
31:47Like if you're trying to run, you know, create a banking application,
31:51like, yeah, you need to build up quite a bit of stuff in order.
31:55To be able to service even your first customer, like you need a bank, and
31:58that is a pretty hefty undertaking.
32:01But for us, like, we found this target customer, which
32:03is very, very small startups.
32:05Startups that have just been incubated, that are maybe, 2, 3, 4 people
32:10large that go through YC maybe.
32:12What do they need?
32:13Like, they don't need any project management.
32:15They, they don't need a lot of functionality around labels.
32:19Like, they will have not too many tickets.
32:21Like, literally what they need is an issue tracker, a way of just tracking a few
32:25things and then marking them as complete.
32:27And that is the first thing that we built.
32:29We built an issue tracker, and even on our website said that, the issue tracker
32:32that you'll enjoy, you'll enjoy using.
32:34And I always hated that website.
32:37Like, I, whenever I went there, I was like, no, this is not what we're building.
32:40We just have to lie to everybody that we're doing it now, because you
32:44want to focus on the target segment.
32:45And the, the idea always was to sort of, go and do project management.
32:50And even, even beyond project management, because, we wanted
32:53to help companies be better at building software, which encompasses
32:55literally everything in that space.
32:58But we had to start with sort of the small customers.
33:00So that's what we focused on for the, for the first few years.
33:03Just make an issue tracker that works nicely.
33:05Start with small companies that were super excited to give you feedback.
33:09Like startups are great because like they, they know how it is,
33:12how hard it is to build a product.
33:14So they'll be happy to help, help you build your product as
33:17well while they're using you.
33:19And so we had a lot of customers that, gave us a lot of feedback,
33:22which we could always invite for a Zoom call and just learn stuff from.
33:27then like the idea was to gradually grow with them.
33:29Like we knew that, once we got those customers, like it would probably
33:33stick around if we were able to, to, to grow our feature set as they grew.
33:37And we knew they were growing, they would raise seed round then, eventually
33:40a series A, like 50 people series B.
33:44So we, we said like, I think we can build out the functionality
33:47of features that, that our initial customers need as they grow.
33:51. And it's sort of a wrap.
33:52Like, we were able to have a few customers that started very early with us that now
33:55are sort of pretty huge companies and they've been sticking around with us for,
33:59for, for the entire duration and we've been just building more stuff for them.
34:02And that enabled us to just grow into larger customers.
34:06Starting to go into sort of, series A companies and growth companies
34:10and now sort of eyeing not, not yet the enterprise, I'll take, take
34:15some time more, but, established companies and IPO companies.
34:18And that was sort of our strategy to, build something of the highest
34:22quality but just reduce the scope in the beginning so much because we
34:26were able to identify those target customers that didn't need much.
34:30I think that's fantastic advice and a great strategy how to go about picking
34:36the right narrow initial scope is not to primarily think about like, Oh, which
34:41features should we build first, but really starting out from like, okay.
34:46We are set on that we want to have that rethought MVP.
34:50We want to aim really high in terms of the quality.
34:53Otherwise, like, why do we even get started in the competitive landscape?
34:58So that is, that is a fixed assumption.
35:00But then instead of thinking about which feature do we start first, is like, who
35:06as a customer segment do we start with?
35:09And that then implies the, the kind of features that are most
35:13important to start out with.
35:15And I think that also aligns Hopefully nicely with the way how
35:19you can also charge for the product and build not just like a product
35:24that people use, but also pay for.
35:27And I'm not sure whether you got lucky there, but it seems like
35:30things certainly lined up very nicely for, for yourself there.
35:35And I think One aspect as well to maybe highlight there is that you've been
35:41seen as the company that other companies also aspire to as sort of a role model.
Hiring and Company Culture
35:52Yeah, I, know, obviously it's, it's been mostly luck as with any startup.
35:57Like, we sort of stumbled into this way of working cause we enjoyed ourselves.
36:02Like we want to build nice things.
36:04And we had the, the, the lack of sort of, wanting to inspire people
36:09with, with our own products.
36:11That meant that we had to build the company in a certain way.
36:13That meant that we had to.
36:16Sort of hire people that we could trust to, not have to sort of look after them.
36:21Because again, we were a remote company from the get go.
36:24And we wanted to make sure that, anybody we hired was just so good that, we knew
36:29that they could do whatever without literally, even talking to us if we
36:33went that way and just, you know, ship something, something awesome which
36:37again meant that, we hired effectively senior people not only that reason,
36:42but, the second reason was, was that we didn't know how to mentor junior
36:46people in a remote environment.
36:48Like we were afraid that we would be doing them a disservice.
36:52Like, hiring somebody who needs to learn and hire them into a remote setting.
36:58We wouldn't know how to mentor them or how to grow them, so therefore we didn't.
37:03And later on we sort of find out that, it's actually pretty nice to having a
37:07very senior team around you that you just trust with building out the vision
37:13or even them having the same vision as you do, being able to drive the product
37:17forward because they're good engineers.
37:18They know what they want from a, a, initially issue tracker and
37:21then project management tool.
37:23And that also meant that, you know, we were, it was hard for us to, to grow.
37:27Like, we wanted these, Overly qualified people which were super hard to find.
37:33So we grew slowly and in the end, like, we became profitable very quickly.
37:37I think two years in, we were profitable not because we wanted to
37:41or because we needed to or because that was the grandmaster plan.
37:44No, it was just, effectively luck.
37:47Because we did these things, we grew so slowly and then the sort of
37:50revenue just overtook our expenses.
37:53And then like the downturn came and now everybody was sort of wanting to be the
37:57Linear, like wanting to do the same thing.
37:59Everybody's looking at like, where can we get profitable?
38:02We don't want to raise another round or ineffectively do a
38:05down round in that scenario.
38:06So.
38:07Everybody started looking at building things in a similar fashion.
38:10So I think there's there's a lot of luck involved but also sort of, our passion
38:16and our backgrounds sort of directed us to build out this company this way.
38:21And we're still on that route.
38:22Like we, we still go down the same way, like we don't want to go through
38:26hyper growth and we will never, yeah, we will never hyper grow.
38:31Like I've seen that at, at, at Uber, Kari saw that in Airbnb Jori in
38:35Coinbase, I don't think anybody of us, really, Enjoyed that experience.
38:39It was nice to see once but, we don't want to go through that again.
38:43Like, we want a product team that is excited to building something
38:46great and not just sort of a, cog in the big wheel of, working on some,
38:51remote infrastructure piece that maybe gets open sourced one day.
38:56We want to make sure that, know, people who build Linear are sort of, they're,
38:59they're craftsmen that, enjoy building something beautiful and, want to see
39:05their work out there, and hopefully, are and can be proud of what they ship.
39:10So even though that's very humble of you saying most of it has
39:14been luck there is this this nice quote, which I think goes along the
39:18lines of luck favors the prepared.
39:21and I think there's a lot of intentionality also that
39:24went into building Linear.
39:26I think it's always like this dance between open ended experimentations,
39:30like seeing, Oh, this is actually great.
39:33And then that becoming like a strong intention of like, Oh,
39:36this is, this is who we are.
39:38So, and I think you've probably maybe got lucky and like, like found a few
39:43things that you think, Oh, this is actually, we should really do that.
39:46But then you also embrace that and some companies call those
39:49like values or principles.
39:51I think quality is certainly like a strong aspect there, but have you
39:56ever like formalized this in some way?
39:59Or if you bring on someone new to the company who hasn't been around
40:03over the years, how do you tell them like, Hey, this is who we are, how
Values and Vision
40:12Yeah.
40:12Um, We, like, we just had our offsite in, in Mexico where we, flew the whole team
40:17in, and Kari was preparing some slides and, we've been talking about having,
40:23some sort of, value statement or values of the company and a vision statement.
40:26And we never did it because we always felt that like all the values
40:29of companies are somewhat fake.
40:31Like they.
40:33just tell what they want the company to be, but not really
40:35what the company is, right?
40:36Which never felt good to us as Finns.
40:38Like we don't want to lie about things like.
40:40We're honest people.
40:42So, again, we didn't go down the vision or, the values route and we said
40:46like, ah, let's not have any values.
40:48So Kari started working on slides to sort of, show everybody how we got here
40:52and what we've done, over the past five years in order to, get to this place.
40:57And he had like, five things that he pointed out that, that, that
41:01we had done and showed that slide deck to, to, to somebody on the
41:04team and that team member was like, huh, these look like values to me.
41:09um, so we were like, yeah, I'm, I, I guess they are values now.
41:13And our values are literally based on, on, What we've done in the past
41:16and what we want to continue doing.
41:18And yeah, there's a small, small set.
41:20Like the first one is trust.
41:22Like we, we've always trusted our engineers.
41:25We've made sure that we hire people that, can work on their own,
41:28that can sort of bring something, something into, into the company.
41:32And we want to be open in, in, in our doings and we are open in our doings.
41:36And secondly, we've always built sort of with the customer in mind with
41:39hiring or, building our functionality by asking customers what they need.
41:43So customer focus is one of the things that we've been doing, which is now
41:48a value of ours, not building things in isolation and making sure that
41:52we built something for our customers and that we built something that,
41:55people, people value and people need.
41:58Um, And it gets more, important as, as, you grow higher and you start working
42:02for functionality that, you wouldn't necessarily use yourself like for PMs
42:06or CEOs and CTOs at larger companies.
42:10The third thing that sort of came out of how we, built the tool, like, we were sort
42:15of opinionated about, what we want to do.
42:18We didn't want to have that, like, we, it wasn't really a great
42:21value to have to be opinionated.
42:23That sort of sounds a bit negative.
42:25But what we, what we've turned it into is like, we built purpose built tools.
42:28tools, like we built for a specific purpose, for a specific
42:32target customer in mind.
42:34We want to, build software for software companies.
42:37And if you stick with that, then we can build an excellent user
42:40experience and excellent functionality.
42:42If you start diverging and building everything for everybody, then, you sort
42:45of diluting, the aspects of the core of your application and it usually becomes.
42:50Less usable or less great.
42:52And then, the fourth one being quality.
42:54We've always, wanted to build a high quality product and, put so much effort
42:59into making sure that, everything is It's great and working and works fast and
43:05all the small details are taken care of.
43:06And if you do all of these things well, then you inspire people.
43:10And that's sort of the last thing that we wanted to do.
43:12Like, we wanted to, be a company that helps companies
43:15be better at building software.
43:17And we think that inspiration is part of it.
43:19Like, inspire people with the quality product that you've built
43:22for them and make them want to build an equally great experience.
43:27From what I can tell from the outside that all rings true and sounds very
43:33authentic that's more of an assessment of how I perceive Linear then.
43:38So I, I think you've met your, you've reached your bar
43:41of like that not being fake.
43:43But very authentic.
43:45And I love how that is like also in terms of the yeah, that the craft
43:50of everything you're doing, how that's also rooted in the quality.
43:54And I think becomes like a core pillar of how the next generational
Advice
43:59So maybe taking one quick step back to the blog post you've written
44:04about the rethinking the startup MVP.
44:07Do you have a take on what is the rethought startup MVP?
44:12Is there like a new three letter acronym that people should use in the future?
44:16No, I, I, you know, I, I don't think there should be a three
44:20letter word for any of this.
44:22Like it'll really depend on what you're building.
44:24But you know, it is about competing in an existing market.
44:28Like, and being better at something.
44:31What that something is, it might be literally anything.
44:34But yeah, you need to be better at something.
44:36Like, you can't just throw things at the ball and see what sticks
44:39because, the ball is already covered with, with all kinds of things.
44:43And people will just not, notice you or do anything about it.
44:47So what sort of advice would you have for builders and founders,
44:52people who want to build those next generational high quality products?
44:56What of the traditional wisdom, startup wisdom still applies?
45:02So you mentioning sort of the, the hyperscaling maybe is no longer an
45:07attractive ingredient to, to get there.
45:11what would you recommend as like, what to focus on and what to be careful with?
45:17in, in order at least to get started, like, I think the most important thing
45:21to do is to, scope down and find, find a target segment that you can
45:27deliver something competitive for.
45:29Again, like we've talked about not being able to build everything for everybody.
45:32So it's important if you can find a way to sculpt a new product and
45:38then, put something that people need.
45:39If you find something that, is a pain point for those users you
45:43immediately have a following.
45:44You can You know, sort of, build out a nice waitlist.
45:47And then with that waitlist, you can, you can iterate on
45:50your product and make it better.
45:51Like you're, you have a waitlist and you have five users selected
45:55probably for that waitlist or maybe from your friends and you're
45:57iterating with them to make it better.
45:59And then you're happy when they have no feedback anymore.
46:02Then you go to your waitlist, you invite a few others to see if, they
46:06have new ideas of what you could build and how you could do things.
46:09So building things with, your customers is , it has been done
46:12obviously already, with startups.
46:14Like that has been the wisdom so far and that hasn't changed.
46:17Like use your customers and use your, waitlist users to, iterate on the
46:21product to make it better until you're sort of ready to sort of go public
46:24and have everybody have a go at it.
46:29Hyperscaling, like, obviously comes to mind when you're competing against
46:32somebody, like, Uber, it was, like obvious that, and the story of Uber is sort of
46:38sad as well, like, how it all went down, but obviously, like, in the end, it turned
46:43out good, but, being, being in Uber during that hyperscale time was pretty harsh.
46:49Like you have, you, you started off with building out a, prototype.
46:54Like there was an iOS application that was a shitty backend that,
46:57I don't even know what it was written in, but it wasn't great.
47:00And then it started taking off a few users in San Francisco started using
47:04it, more black cars came available.
47:06And the, the thing where, when Uber took off was like when effectively
47:10sort of Lyft invented the model of, okay, let's have normal.
47:14People drive their own cars and be the driver.
47:18And suddenly you realize that's the way to go.
47:20And now immediately they're in a competition.
47:22So now they have to get some money in and start scaling and
47:26start conquering some areas.
47:28And your infrastructure is still horrible.
47:30You haven't built out any of the stuff.
47:31You were just trying things out and your application looks horrible.
47:34And now you're suddenly having to run.
47:37And it takes off.
47:39And suddenly you've got tons of users coming in and you have
47:42to scale your infrastructure.
47:43So you have to hire people as quickly as you can in order to just keep the
47:46flames, not reach the outer walls.
47:48And, two years later, when, when you've grown rapidly you, you end up with sort
47:53of having an infrastructure that is just.
47:55Coals and ash.
47:57Your team is burned out because they had to fight fires the entire time.
48:01And then you have to sort of replace that whole thing while you're
48:05still serving all the customers.
48:07And, the weird thing was, and I, When I left Uber, they had started already
48:13sort of redoing much of that, that core infrastructure, and they were still at
48:17it like four years later, like we're still replacing the core bits of it.
48:21So it's, it's, it's horribly time consuming to scale something up
48:26quickly if you're not prepared to it.
48:28if you cannot do that, then I think you're in a much better, better place.
48:32So that's what we've done, and that, is what I would suggest people, if they're,
48:36able, like, obviously, you need some money, and you need to have a bit of
48:41luck as well in order to, sort of, get initial customer interest and maybe a
48:46VC invest in you so that you can sort of build it out a bit more slowly.
48:50But our take on infrastructure and the backend always has been to sort
48:54of preemptively build everything so that, we're prepared for the growth.
48:58We know where the next bottlenecks are.
49:00We might know that, a year from now, like, this thing won't scale anymore.
49:03So we started working on it early on so that we can sort of put implementations
49:07in place that, Just work and it will sort of, , work nicely and are architected well
49:13so that no surprises come, come along.
The Importance of a Sync Engine
49:16I think that's a nice segue.
49:17And we've been mostly covering sort of like the, the more cultural aspects
49:21of Linear so far, given this is the local-first podcast where we haven't
49:27yet talked too much except for the beginning about syncing, et cetera.
49:31And I don't think we need to spend another hour and hour going all
49:35the way there, but maybe just briefly connecting the dots there.
49:38I think the reason.
49:40that what gives you this competitive advantage allows you to build that high
49:44quality product is that you have laid that foundation with the, the sync engine that
49:51takes out of like the, the picture, the entire complexity nightmare that, moving
49:57data from A to B and back to A can be.
50:00And so you've solved that and like on your shoulders of Giant, now
50:05the, the the, the product can be built by people who don't have all
50:09of that knowledge of data syncing.
50:12And I think that is like a superpower that enables new products like Linear.
50:17Yeah.
50:17I mean, I do have a talk on, your conference on that.
50:20It's, it's probably available on YouTube as well.
50:23If you want to, if you want to check it out and put it into the, I don't know,
50:26notes for this, this, this podcast.
50:28But yeah, in short, like, The initial idea of the sync engine was
50:32not to make it developer friendly.
50:34That sort of happened as an afterthought.
50:36And that was, in my mind, maybe the more more important aspect in the end.
50:41Like, we wanted it to be fast and support offline mode and enable, the application
50:45to be quick and that is important, but what we found out what, what we like even
50:49more was that engineers would be able to just ship features much, much faster
50:55without having to think about a vast, area of, of A functionality that usually
51:00takes quite a bit of time, which is sort of error handling or networking, waiting
51:03for things to come back, supporting two different code paths for like when
51:07you make your local changes versus when somebody else makes those edits for you.
51:12It's all abstracted away so that you don't need to think about these things.
51:16And it works for certain kinds of applications.
51:19Definitely not all like if you're building, something that has, a lot of
51:23information or building a search engine and obviously not, like, you need to be
51:26able to have that data locally or pretty close to your, to your clients and be able
51:31to sort of fetch the pieces that you see on screens and then keep them up to date.
51:35But for anything that resembles an application.
51:37That has sort of a limited set of data, and that data piece can, like, the
51:41amount of data that you have in the whole application can be large, but it
51:44still needs to be limited to, what you can browse at a , given point in time.
51:48And then this model just works absolutely beautifully.
51:51And.
51:52I sort of had this inkling at Uber already, like, I don't want to
51:55build anything in the traditional sort of networking model anymore.
51:59Like, I think sort of sync is such a better user or developer experience.
52:04And, and the Linear, like, it's, it's clear that, I, I, I, well, I won't ever
52:09have a job after Linear, but, if I did, I, I, I would not work in any other way
52:14than just doing a sync engine again.
52:16I'm working in this environment because it just makes the, yeah, the
52:20developer experience so much faster and you can just ship functionality.
52:22Like, the easiest way to think about it is to literally say that, you're
52:27effectively just building the front end.
52:29You have, data in memory, you've got data objects, which you render on screen.
52:33Then you modify those and that's it.
52:36Your feature is done.
52:37Everything else is handled, the synchronization, other
52:40users making the same edits.
52:42There's nothing else you need to do in order to build a feature.
52:45You just build the frontend and you're done with your entire feature.
52:49And that's pretty powerful.
52:51And I think that also like empowers the already capable front end developers
52:57even further, since I think so far in this more traditional three tier
53:04web app where you have your, your front end that you're building.
53:07And then somehow like you're doing your, your fetches or RPC calls, et cetera.
53:13But then you also need to worry about like, okay, sorry, I need to serialize a
53:16bit of data over there, send it over here.
53:19Now I need to do something there.
53:21And like, Oh, what if.
53:22This now changes and I need to send this back.
53:25If we can take that entire part out of the picture and front end developers are
53:30only dealing with like the, the client side state management, and that's it.
53:34And then either you have, you're relying on like a external sync engine
53:40that already works super well for you and you just need to integrate it, or
53:44you have the luxury of having someone like yourself in a team who builds
53:49your own, runs it, et cetera, which I think will be not always required.
53:55I think the better the off the shelf sync engines will get the more products
54:00can already be built with that.
54:02And I think someone like yourself will rather be needed when a
54:06product really diverges from that, from that standard path.
54:10And so I would probably say that maybe in a couple of years from now,
54:15you could probably build something like Linear in terms of like the
54:19data syncing capabilities with like something like automerge, et cetera.
54:24Some of those.
54:25Upcoming sync engines, and then it's probably rather a matter of can
54:30it also handle all of the scaling patterns and the extra user experience
54:35patterns that you want to really nail.
54:38I want to give an example of, like, how hard RPC actually is.
54:42Because I don't think people understand, like, before they've tried
54:46it out and then run into these edge cases, which always are edge cases.
54:49But once you run into them, you're like, oh, shit, what do I do now?
54:53You need to rethink your entire architecture in order
54:55to make that, make that work.
54:56So A simple example, you've got, some sort of model object and it
55:01has two properties, and the user makes a change to those properties
55:05and sends it out as an RPC call.
55:08And you're also connected with a WebSocket to receive changes that other people do.
55:12Now, you send out the RPC call and wait for sort of acknowledgement
55:16for the server um, that, you know, everything was applied fine.
55:20While that's going on, you receive a packet that, another user updated a
55:24certain property on that model object.
55:27What do you do?
55:28Like, and that becomes a really, really hard problem because suddenly, like,
55:33you, you really don't know what to do.
55:35Like, you can't rely just on that RPC call coming back.
55:38Because, again, your backend has multiple servers on it, so you can't
55:42rely on the timing of these things.
55:44It's not just, one single server running things, you know, serially.
55:48It's multiple servers writing to the database, and then somebody is
55:51able to sort of send you a message, and the RPC call might go through.
55:56have already been sent but hasn't reached you yet because the network is slow.
56:00So when you receive that RPC code, you don't know if all the
56:04values in there are up to date.
56:06And now you need to figure out what to do with the updates for that model object.
56:11And when you realize that, you're like, Yeah, I effectively need
56:14to implement another sync engine in order to make that happen.
56:17There needs to be a queue of sorts.
56:19And it becomes very, very complex.
56:22It's funny.
56:22So like, it's a sort of a boiling frog situation where you start out with like
56:28your, your blissfully ignorant happy path of just like doing a fetch call
56:34to your backend and like, you get your data back and you test this on localhost
56:39with like your one client over there and your locally running server over there.
56:43And like, everything just works and like you ship the feature, like you mark the
56:49issue as done on, on Linear, but then as it goes on production and like multiple
56:55users hit it, you get some really cryptic error messages that you, you even have a
57:00super hard time replicating that locally and you, you've spent hours on it.
57:04Hours and hours and days and days, like reading through log messages.
57:07Oh, we realized I actually, we don't have the right log messages for that in place.
57:11So you'll need to spend another two weeks shipping that until you've like,
57:16finally have all of like the signal that you pull out of the giant bag of noise.
57:21To finally, like, have at least some confirmation of
57:25that something is going wrong.
57:27And once you have that hypothesis to even replicate it locally that's
57:31already takes heaps and heaps of time.
57:34And then, like, The way how you pull yourself out of that is by step by step,
57:41applying changes that will ultimately lead you to a sync engine, but that's such a
57:46painful and inefficient way to get there.
57:50I think it's, primarily probably a problem to get, get us from.
57:54A to B, like A being the status quo of the world right now, where like
58:00everything is built with the sort of RPC ish way to B where most products where
58:05it's a good fit are built with sync engines is probably just that instilled
58:10tribe knowledge that by now like all the technologies are sort of like.
58:15Fostering that, that status quo where like all the libraries are built around RPC
58:23and we're, we're kind of blind to, yeah, it's kind of the spoiling frog situation
58:28where it's already cooking like crazy, but we don't realize it yet how much
58:32complexity we've built for ourselves.
58:34And how simple things could be.
58:36For sure.
58:37So it becomes simpler to not you know, implement that WebSocket and
58:40just have the user hit refresh to get the latest version of that page
58:44and be ignorant about or bliss.
58:46Yeah,
58:47exactly.
58:48Which just dials up the temperature,
58:52but this is where I'm so excited about Linear and the success of Linear since
58:58people can't ignore products like Linear.
59:02There's like, Oh my gosh, what makes it so great?
59:05And then people want to.
59:06understand how did you like explain the success and sure a lot of it will be
59:11attributed to like oh they have such those great people and they have such
59:16great design and they have that amount of like border radius but then a lot
59:22of it will also come down to the to the implementation this is what I where
59:26I hope that this will drive a lot of like Similar to how Nike focuses not as
59:32much on the products, but on the great athletes, you're the great athlete.
59:35And I'm very much looking forward that people want to be like you.
59:40I really, enjoy working in a local-first environment, and I hope that
59:44everybody else picks that up as well.
59:47And there's starting to be tooling around it, around the, local-first as
59:51well, that you can use out of the box.
59:53That will probably work for most of the cases.
59:56It will still be hard to scale that up.
59:58But at least you can get started and maybe then figure out whether you need
Outro
1:00:04Perfect.
1:00:05I think we can leave it at that.
1:00:07Thank you so much for this amazing conversation.
1:00:09I was really looking forward to it.
1:00:12And Linear continues to be a huge inspiration for me.
1:00:15And it's been so, also like so interesting and fun to hear.
1:00:19That a lot of like what has inspired you and led you and like explorations you've
1:00:24done where you had sort of like what you do attribute to luck, but I think
1:00:28is also just great taste, et cetera.
1:00:30That I see a bunch of parallels there to how I'm approaching Overtone
1:00:34that gives me a lot of energy and motivation to continue on my path.
1:00:38So thank you so much.
1:00:40Thank you so much.
1:00:40And waiting for that invite to Overtone.
1:00:43That's all, but when you're ready, like when you feel that you can, you can
1:00:47move on to the next customer group.
1:00:50Sounds good.
1:00:51I'll send you the magic link.
1:00:53Perfect.
1:00:54Thanks so much.
1:00:55Thank you for listening to the Local First FM podcast.
1:00:58If you've enjoyed this episode and haven't done so already, please
1:01:01subscribe and leave a review.
1:01:03Please also share this episode with your friends and colleagues.
1:01:06Spreading the word about this podcast is a great way to support
1:01:09it and help me keep it going.
1:01:11A special thanks again to Rosicorp and PowerSync for supporting this podcast.