The LoFi Movement: Building Local First Apps

Hey. I'm doing good. You know what? About 10 minutes ago, it Wes, clear sky. And right now, there's, like, already half,

right now. Oh, no.

Oh, it it is a certified winter wonderland.

15.5.

Oh, yeah.

Yeah. If you got shirts out there, just just send them along.

And this podcast is presented by Century. So if you need air tracking in your software, and this stuff that I'm about to get into in this episode is complex. Let me tell you. I have, you know, really spent some time in here, And it's and, unfortunately, it's not super easy. And with anything like that, you're bound to make some mistakes.

Now when we have all these systems that we're about to talk about, you know, there's a ton of potential for things in syncing process, in saving process, anything to go awry or to not behave like you're expecting it, and your visibility on that's going to be super low. So if you wanna have high visibility into your applications, head on over to century.ioforward/ syntax. Sign up and get 2 months for free. And, it's just an awesome tool.

So let's get into local first. Now local first or lo fi, which honestly, even if you Google lo fi local first, man, that lo fi beats to to code 2 or to study 2 has, like, really dominated Google. So if you're trying to research this stuff, I've included a massive amount of ESLint, including this, this really good one, which is local first web dot dev, which that in itself has a massive amount of links. So if you're if you're looking for further information on this, it's gonna be tough to Google, and I've tried to include everything as as you, you know, would need so in this episode.

So I think the the big thing here is that the local first movement as as it so put or local first development is more than maybe what you're thinking in terms of, hey. It works offline.

The way that they've defined this lo fi movement of coding is through several things.

And these are these are the kind of principles in which they're call them the 7 ideals of local first. And and I've pulled this directly from this Inc. And Switch blog post.

So this these are not my own words, but I'll I'll do my best to try to explain some of these. And you'll see different projects in this space representing all or maybe some of these ideals.

So number 1, no spinners.

They want instant loading.

And you can really get instant loading, like, in terms of from your database calls or your your data. If you're loading from an IndexedDB locally, I mean, cut like, for very minimal data, you could get as low as, like, 20 milliseconds. And it's for complex data, you know, you're only getting up to a couple 100 milliseconds, which is a far cry from a network call. Right? Yeah. I'm I'm sure you're gonna get into this, but IndexedDB is the Wes API. It's a database in the browser.

Yeah. Yeah. If you were saving data in this kind of context, like a full application, you're you're not gonna put it into local storage. You could think if you're trying to sync your database, you're gonna put it into IndexedDB.

There's some other options there too. People are doing some crazy stuff with WASM and SQLite.

But for the most part, number 1 ideal, no spinners. They want that data to load quickly. It's on your device already. It shouldn't take any time to load. 2, your work should not be trapped on 1 device.

As in if you go to your phone, your computer, whatever, that information should be able to sync from Node device to another. Okay? And it should happen preferably in real time. So that way, if I do something on my phone, it goes to my computer.

Now

There is a server, and this is part of the that we're going to get into.

Okay. Because that local first does not necessarily mean offline

Dude, it JS very funny because one of the the one of the things I watched when they they were describing they came up with the lo fi name.

They were like, at first, I wanted to call this serverless, but then the serverless folks took that. So I couldn't call it serverless, which is great.

Okay. So those are the 222 additional or 2 initial ideals. 3rd 1 is the network is optional. Notice how it says optional and not required.

So the network will be used for initial loading of the app. It will be used for syncing your data. It will be used for bringing in new data from the sync to database, those types of things. But the network should not be a requirement to use your app generally.

And this is for a number of reasons beyond just working offline.

It's so that if your network conditions are changing, the app experience doesn't change. If you're loading everything locally again, it's going to be fast. It's going to be on device.

Okay? The the most, like, reasonable thing I could say is, like, it's a it's an app on your phone that functions very much like a native app.

Obsidian comes to mind. Right? You can work in Obsidian whether there's a network or not. And when the network connects, it syncs. So seamless collaboration with your colleagues AKA multiplayer stuff. This is you know, you see this a lot where, you know, Wes and I are editing the same Notion document. That is seamless collaboration with your colleagues. So that is a tenant of, or an ideal of local first, which is funny because when I was researching, multiplayer stuff we did this for my Hack Week project at Century. I did a kind of a document editor, a multiplayer document editor. You see so many of the same folks, so many of the same projects, so many of the same connections with a different goal in mind. Right? The multi player specifically is a goal for collaboration, but it also plays an important part in offline first software, local first software.

Next up is security and privacy by default. Everything should be encrypted. Right? Stored on your device. It's yours. It should be encrypted. That's part of their ideals.

Next step is that you retain ownership and control. Hey. The app is on your device, but also you can export that data. Yeah. If you ever see the actual budget project from James Long, that's a good example of this because, again, these these files are local. You can export them. You can import files. You can move them around.

One of the things they often talk about is like, hey. If the service goes down and you have the app on your phone, the app should just not stop working.

Maybe they take the app down. It's yours. You should be able to use it. Yeah. You wanna wanna hear a crazy story about that?

Yeah. And I think about this a lot with Obsidian, Right? Which is one of the reasons why I like it so much. The only thing that Obsidian doesn't do well is multiplayer stuff. Right? Like, you and I Sanity edit an Obsidian doc reliably at the same time, at least not in the same way we can in Notion.

But I like about Obsidian is that it is a folder of markdown files. I could go and publish them to my website. I could go and, open them up in Versus Node, and it doesn't have any impact on whether or not I'm able to use those files. So if if Obsidian goes away for some reason, I still have every single method that I have. That's we've said that so many times on this this show is if whether considering whether to buy into a proprietary

Yeah. And we'll talk a little bit about some of those things even in projects right now within this episode.

Good reading on these ideals and their general thoughts on them, this ink and switch, blog post I have linked directly below these in the show notes is like the best place to get a great handle on just the the big picture of local first if you like in-depth reading. Because this is it's a big read, but it's a really good read. They they talk about, like, all these different softwares and compare them and say, alright. Are they fast, multi device, offline collaboration, longevity, privacy? Do they have user control? And then, you know, there there's a lot of great information here. So, you're probably thinking like I was after, getting a nice little intro to this stuff. Holy cow. It all sounds amazing. Let's go.

Let's just do this. Let's do local first. Yeah.

And then, that's where the the fun part comes in because nobody has really I mean, there are people who are, like, attempting to nail the local first complete solution.

The problem with a local first complete solution is the stuff is hard. The stuff is complex.

And typically, most people aren't starting a new project.

You're working on a project and you might say, oh, man. Maybe local first would be a good opportunity here. Well, that's not really you didn't have the opportunity to do a local first, so now I have this whole tech stack. What do I do with my tech stack? Right? Yeah.

But if you are looking to to start a new project, there are some new services that we'll talk about later on that do get you more things out of the box with less effort, but they do require some buy in. They do require subscription costs. They do require things like that. So there's a whole dimension of how much do you want to do yourself and how much pain would you like to have in your life? Because,

The answer is, in this very first thing under I have here, the next heading JS the tech. And a big thing that you'll see over and over in the space is the, acronym CR DT, conflict free replicated data types.

And a conflict free replicated data type is basically how you do just that. How you take 2 bits of changes and know which one took place and how to conflict free merge those changes, merge that data.

CRDTs are the thing that kind of powers the whole syncing engine. Right? You have a change in your local database.

You have a change in your remote database.

How do I know which of those is the most updated one? But not only that, you have a change on Node device. You have a change on another Yeah. Do you know which of those changes the most? Run Node that other time. On Wes computer and a change on my computer. How do you know which one of those goods in in what the order they they get updated into the document? Because it's not happening simultaneously.

of which there is a lot of these things and many of which are not a ton of fun to use. The the big boy in this space is Yjs.

Now Yjs has a learning curve. I'm gonna tell you that right now. Now I have a repo that I'll post into the show notes that shows the same app in both Yjs and Replicash. But Yjs is really the high performance CRDT that has a big community, that has a lot of people using it, and is more of a lower level tool to build these conflict resolution things. Okay? So you can hook up a CRDT to a WebSocket server, and you could hook it up to an pnpm DB.

And in those 2 steps of hooking those 2 things up, you can keep 2 browser windows in sync.

Next thing you do, you hook that Yjs up to your server, your API server, then you get it syncing to your database server. Now those aspects are much more tough, and we'll talk about some services there. So the tech is you need CRDTs, the con the conflict free res merger data. Yeah. There are others of these, but, again, JS is the biggest one. There are easier ones of these, but many of them do cost money to use. There's licensing fees involved.

Yjs is free and open source, but it is probably the most difficult.

That's I don't know how to spell it, I'm gonna be honest with you. What? I don't know how to spell crudites.

I'm not. Yeah. We don't. Yeah. Yeah. We call marmots, marmots.

Yes.

Yeah. I think the answer is that it does its best. What you're not you're not gonna get from this is you're not getting, like, a Like a ESLint interface or Yes. My understanding is that because this stuff is deep, the algorithms are there's different types of CRDT algorithms.

My understanding is that this uses, like, timing involved in, like, a an actual, a specific clock that has, like, a central clock, not these 2 users' laptops' clocks, essentially, that are able to save, you know, the last one out JS the the winner.

apps that you see. Yjs specifically is a very widely used, project for for doing that type of thing. There's a really good, talk from JS from James Long called CRDTs for mortals, which, does its best to explain these things for normal people, and I think it does a great job. Alright. More more on the tech here. WebSockets.

Definitely used WebSockets. Typically, you know, there there is ways to do it with WebRTC, but the way that people are doing typically syncing data is with WebSockets.

You use a WebSocket to connect to other machines or other windows that are opening the same app in the same room necessarily, or you use WebSockets to talk to your server so that when you make a change locally, that server also gets that change so it can save in the database.

Right? Or perhaps the database needs to sync with the client, and therefore, you're getting that information through a WebSocket.

More tech here. IndexedDB, we went over. It's the local database. Again, some people are storing things in SQLite, but most people are doing indexed DB for this. The SQLite stuff is some proprietary interesting stuff going on, maybe, some different projects doing interesting things there. 99% of the time, IndexedDB.

Last piece of

Yes. It's gonna be great. Some really, really smart, talented folks. We're bringing all kinds of different interesting projects here, and we'll talk a little bit about some of those and what they can do. But most of those projects that you might wanna check out are on local first web Scott dev. So The last bit of interesting talk here is service workers.

A service worker is basically caching the code that you need to run your site to run it offline.

If so if you think about it and I have I have a a repo that I'll share with everybody that just bare bones examples for this. But if you have a service worker that's loading the code and you have an IndexedDB that is fetching the data client side, you don't have to go outside and you can have your whole application load locally.

Because, again, it's getting that data local on your device. It's getting the saved website essentially from the service worker. All that hopefully just works just fine. In my repo that I'll share, it has a very basic implementation of you click a button, it updates your IndexedDB, and it works offline. You click that button a whole bunch offline, still updates the DB. You come back online. It works the exact same.

So let's get into some software options here. I have 3 different projects that are I think are the most interesting in this space. RepliCache is the one that I think is getting a lot of hype right now. RepliCache is interesting because it is closed source and you sign up with a license.

But the license is pretty reasonable as far as pricing goes. You can get it's funny. It's like monthly active profiles.

If you're less than 1,000 monthly active profiles, it costs nothing. And this is only if your project is commercial.

If your project is noncommercial, RepliCash is free. So if you're just trying this out and you're not making money on it, you can just use this thing.

So that's great.

Replicash handles a lot of things for you. It handles the syncing to an IndexedDB.

It handles, syncing in general, syncing over WebSocket. You don't have to worry about the WebSocket code. And it handles the conflict resolution stuff.

So what you end up getting out of it is you get something that works with anything because you just point it to a URL for your push and pull for your API layer.

You connect it to your application. You could connect it to a database, And you are essentially able to with 1 step well, not 1 step. It still takes a little bit. I have a I have a a folder that shows you how to do this in the SvelteKit app. But what it's cool about this, again, it handles a lot of the kind of pickier stuff that Yjs will do.

And that's great. As a friendlier project, I'd say this one is definitely friendlier.

Okay. So it's Yeah.

Yeah. Pretty much. Yeah. Or you could either way, I did it as I synced it to a, a Sveltekit rune, like a state rune, which is just just keeping it in sync. So I was using the Svelte rune as my local data source, but then it would keep it inside. And you could probably also use, like, a, like, a proxy,

Yeah. Okay. So Replicache is a more simple version of Yjs.

Yjs, you gotta do a little bit more yourself. That's okay. In fact, when I lined up the code by code with Replication in Yjs, Yjs, in my basic example, wasn't that much more complex. That said, I think over time it would be. And lastly is Electric SQL, which aims to be Electric SQL aims to do even more for you than Replicash.

And, again, I think this one is a little bit more of a buy in. Again, they they say it's the missing sync layer. So this one, again, is trying to be a nice sync layer. But in reality, you kind of end up using it like an ORM in many ways. You do connect it to your own database.

It does work with Postgres.

It's specifically for Postgres, which is, you know, people using SQLite or or MySQL are out on this one, but it does more. If you're looking for a more and more friendly option, Electric SQL is the one. And there are, by all accounts, more even more expensive and more simple ones. That's kinda how it goes. Right? Yeah. So let's talk about the very most basic offline or local first app. Okay? The very most basic one.

You initially load the app the very first time you load the app.

Your app gets cached via service worker. The data gets stored into an IndexedDB.

You go offline or anytime you load the site, even online, it should load the site from the IndexedDB.

It should be instant. It shouldn't have to go to the network. So at its very most basic, that's it. Right? Where it gets more complex is when you need to go beyond just a local data store. Right? Which most websites probably do. Right? You probably need a remote data store somewhere at some point at some time.

So that this is where things get get tricky because, you do need this syncing between a local database and an external database, and that's where it really gets more complex.

Either way, the benefit of having a simple local first app in this way is that you get near instant writes.

Like, near instant writes, near instant reads. And if you're doing something that requires that or that would feel nice, maybe a here's a basic example that everyone's made a ton of, a to do app. Right? Yep. If your to do app is taking, you know, 200 milliseconds to return from the network just to check a to do, then that's probably a good situation where Local First could come in handy. In fact, I first got into this stuff because I was working on my habit tracker app.

And the way that I solved my habit tracker feeling slow is just by adding optimistic UI. Right? It it the UI thinks that it's a success even if it doesn't know that it's success. And then it, you you know, collects whether that was a success later. However, a local first is kind of better than that because, again, it's saving everything to your database and then just syncing in the background. Either way, you don't your application will feel native fast.

So Yjs will not touch your database.

Okay. I think there's extensions for it that that do, like, community based extensions that do more there. Yeah. But in in reality, you're using Yjs to understand where like, which piece of data. Is it this data or is it this data? Which one is the most up to date one? And it kind of puts them in a, like, a do this, then this, then this, then this scenario.

Well, it depends on what. You know? If you have an if you have an app that Yep. Is multiplayer like Notion you have something like Notion, that gets more tough. Right? Because you have data coming in from different sources. You have data in the database, and you have to understand. Data here. Data here. Data here.

If you have, like, a a to do app, that's way more simple. Right? It's like, I am a user. I've checked this to do. It goes up. Alright. Check the data in the database. Is it is it more recent or not? And the Fireflies will handle that stuff, but it's not easy. That's why a lot of these tools that you'll see around here are like, oh, we take care of the syncing. We take care of the local database, and we take care of the remote database. Okay. There are services out there that do that and do it well. I see. You're you're you're signing up for something. Right? You're you're buying all in. Whereas, like you said earlier, you might already have a database, and you might have a tech stack where you need to to work with that.

Yeah. You will see projects in all phases of this this, like, I do everything for you to Yeah. I just handle the conflict part to I handle the sinking part to I handle you Node, there there's all sorts of different projects in the space. Okay.

So in a much more complex app, like we've been saying, yeah, you have your your online app loads. It caches it to a service worker. It saves the data to a database, a local database, an IndexedDB database. In the background, it syncs to your remote.

The remote syncs back to your local.

The service worker is for offline. The data, once it saves local, it syncs to remote. If a data JS changed remote, it comes into a WebSocket and syncs to local.

It I was telling my wife. I'm like, I'm trying to learn this stuff, but I feel like that GIF of Charlie from It's Always Sunny where everything's, like, connected. I'm like, this is this is literally the technology I'm trying to work with right now. It's just lines connecting everywhere.

Yeah. So okay. Let's talk about some big concepts here. State lives in the database. They often talk about like, hey. When you use an app, and you leave the app Wes you come back to the app, usually, the state's like the same in all accounts, really. Right? You have Safari. You close Safari. The tabs that you had open are are still open. Those types of things.

So one of the ideas here is that a lot of people are putting all kinds of app state directly into the IndexedDB, and they're even putting it into the DB no matter what. Because that way, if I set something on my phone, it's the same way in my desktop, it's the same way elsewhere. Right? So a lot of the state lives in in IndexedDB or in your database in general, just just to keep state everywhere.

So that's like a really interesting, way that people tend to work in these things. Right? Just that that alone is a big shift from the way you typically think. And because of that, you'll see a lot of these apps, they do kind of take that space of a state management library like you mentioned. Right? Like, this electric DB has its own hooks, React hooks, if you wanted to have it be your React Native library. Yeah.

So let's talk about some questions that people have. What about SSR here? Like, what JS server side rendering look like in this world? Well, the initial load necessarily isn't as important as long as the data gets into the IndexedDB. And as long as the service worker works, that initial server side could be a client side render only. It could be a server side render. It could be anything. That's not necessarily a concern. But I think that one thing you'll notice when you look into which application specifically benefit from local first architecture, SEO is not typically a concern for them. Yeah. Right? Maybe it's your landing page. Your landing page doesn't need to be local first. I mean, it that that could be simple. That's just a service worker. Right? But, like, does your to do list need to be server side rendered? Probably not. And because of that, you end up getting into spaces where you're only doing client side rendering and it makes things way easy. I know we we just had episodes on HD max. It's like throw everything back to the server. Yeah. And largely in this world, it's like, no. No. No. No. Throw everything onto the client so much to the point where everything runs on the client, even the database. You know? Man. Wes, eventually,

cowboy. And it happens more than you think. And it's Scott, like, not necessarily offline conditions, but just slow conditions. I go to dance practice every Thursday.

My Wi Fi signal, for whatever reason, a dance practice sucks, and I I need an app to help me practice. And I'm sitting at practice with my app to help me practice, and I click a button on it. And I gotta wait 10 seconds for a database response, and I Wes like, screw it. I I can't use this, and I made it. You know? I'm like, I'm responsible for this, and I can't even use it. Yeah. That well, that's another good example is,

Yeah. There's tons of applications where this makes a lot of sense, and there's tons of applications where it doesn't make a lot of sense. Would your does your blog need to be local first? No.

That's the same concept. Right? You're saving these things for offline or even you think about, like, you know, I I go on a flight with Netflix, and I wanna save some movies offline for my kids. Right? I mean, there are a lot of instances where this stuff makes a lot of sense. Yeah. MB has that, and MB JS built on Wes tech. Right? So, what about this Apple PWA nonsense? Because I know it's inevitable that people are gonna be like, I wanna do local first, but Apple killed PWAs.

And you're not wrong. Apple sucks for that, but it doesn't really affect many of the things that we need here. Right? IndexedDB still works.

Service workers still work. WebSockets still work. So regardless of what Apple does here, many of these these technologies that you need to do this stuff won't be affected by that. Did you see?

So hopefully that that changes. They look at it so hard that, they they feel Apple feels really bad and changes their decision. You Node? Yeah.

You just look in your life. I'm disappointed. I hope so too.

Yep.

Okay. You might be thinking I recognize a lot of these things from real time in multiplayer. We talked a little bit about this, but, yes, the same technology is frequently used in multiplayer stuff. You'll often see CRDTs talked about just as much in multiplayer application as you do in WebSockets.

Figma has a ton of articles on CRDTs and and technology that they've developed there or how they do syncing.

That stuff is extremely fascinating even if you're not building Figma.

You might be thinking, hey. This all sounds like too much work. Well, triple it Scott dev is just one of many services that I found that handles everything for you. If you want, like, the supabase of this stuff, Triplett.

Triplett is an open source database. You can host it yourself that syncs with data between the server and the browser in real time. It gives you TypeScript, real time sync, offline support, relational queries, works everywhere.

Doesn't doesn't matter which, frame front end framework you wanna use it with, even React Native. Right? So if you want the easiest possible solution, there's stuff like that.

Again, you're paying for it, or you're hosting Vercel, even better. Right? That sounds neat.

Electric SQL is like the next step down. If you don't mind a little bit of work, Replicache is the way to go.

There's more like evolu.evolu.

Oh, I don't know. Play on the word evolution or something Scott dev, which is also really interesting because it use Keasly, which is an ORM that people are liking.

It has a CRDT. It uses SQLite in the browser.

Yeah. A lot of cool stuff. If you wanna go as deep as possible and you wanna become, you know, a Jedi master at this stuff, go to Yjs.

It's it is intimidating.

It will kind of make you, a little frustrated at points and just a little bit frustrated at points, but it's, definitely worth it to if you're interested, like, seriously interested in this tech, it's worth it to spend the time learning Yjs even if you're not going to use it simply as a means of getting a better handle on this stuff overall. Sometimes I think that, like, people always reach for the service. Right? Why reinvent the wheel? The wheel's already been fixed. But sometimes, reinventing the wheel exists to help you understand concepts and help you learn, even if maybe that's not what you're shipping. But there's no harm in learning the underlying tech behind a lot of this stuff even if it is obnoxious and hard.

I have some links for you here. Local first web Scott dev is the best place to really get a handle on the players in this world. There's a great, YouTube channel where they post their monthly meetings. In fact, Wes, one of their meetings is literally going on right now. Kyle Simpson from You Don't Know JS is speaking right now on Discord, and this will be published later on the low.phi_dev YouTube channel that we'll have linked up. The Ink and Switch blog post is well worth your time.

And then the local first Reddit, they post all of the past shows, the same stuff that's on the YouTube if you are interested in that. The last link I'm going to have for you here is something I'm putting up right now.

And you you don't it's not in the in the notes yet, Wes, but I'm putting it up at this very second. And it's a repo that I made.

It's SvelteKit, but the SvelteKit stuff is kind of minimal. Okay? And what's interesting about this repo is I did a basic offline or local first counter. Just counts up. Doesn't even count down. Just counts up.

And I did it in both JS, and I did it in RepliCache. So I did it in both of those 2, and you can kind of compare them directly and say, alright. This is what it looks like in RepliCache. This is what it looks like in JS. And it's just the local parts. This does not get into the server side or syncing to a database just yet. But I I hope to expand upon these little demos even more because it's truly fascinating stuff.

Yes. I'm my eventual goal here is to get my habit tracker working in a way that's offline.

But if you're trying to add this to an existing site, man, there's so many moving parts and, like, I don't wanna mess up my existing database and data stuff. Scott, like, what I'm doing thing. It's tricky.

I'm getting I'm getting, like, basic examples working, then I'm getting a to do list working, and then I'll integrate it into my habit tracker. But that's the eventual goal. Right? Did you just open source it, your local first

And I'll put it in the show notes. Local first and text. It doesn't have a read me just yet, but, again, it's just 2 2 SvelteKit sites, Replicash and Yjs. They're both client side only.

They both have instructions, WebSockets. They have a service worker. They they have all the important stuff. They both work offline, and they both sync across browser windows.

So sweet.

Let's get into some sick picks.

Oh, Chanel? Like, the bright

Are you talking about, like A wool The French Scott luxury brand? Or no. That's Chanel. Node that's what I was I thought you were talking about Chanel. Chanel.

.dev. Nice. I, I got a lot of letters, like, varsity letters in high school, but I never got the jacket. So so I have the the the big letters, but I never got the jack because our our school colors were orange and brown. I was like, who wants an orange and brown? Yeah. I don't want that.

Carnies were blue and white. They were way cooler.

Well, I got my varsity letters for do you wanna guess what I got my varsity letters for, Wes?

And then Node of them I wish I'm a bad jumper.

No. I'm gonna tell you right Node, neither of them are cool. I got, 1 Node letter for academics, for maintaining above that.

For maintaining a high GPA for 3 semesters or something.

Oh, And then my other one was for band. So I got band and academics, which are probably the 2 coolest varsity letters you can Keener.

Is it? Kieners Canadian. Yeah. It's a Really? Dictionary.com says a Canadian informal

Yeah. Yeah. I I famously, tested into English as a second language in college. They they my the adviser was like, yeah. I know you you took the test. You did your well, you got into the University of Michigan, but, unfortunately, we think your writing is so poor that we wanna put you with the people who don't speak English.

Okay. My sick pick is going to be monarch money.

You know, since ESLint shutdown, a lot of people are looking for a mint replacement.

This one is not free. So, it's it's not necessarily a Mint replacement in that regard.

But a lot of these financial tracking apps, I used Empower, which is formerly Personal Capital.

I've used YNAB for budgeting. I used Mint. I used a whole bunch of these. A lot of them fall short in a lot of different ways. Right? Like Personal Capital does investments really Wes, but sucks for budgeting, and the UI has been garbage forever.

YNAB is really great for budgeting, but sucks at everything else. And honestly, it has not seen an update in a very long time.

Monarch does everything really well. The budgeting features are great. The UI is really great. It's the same price as YNAB, so I was able to just swap them out.

And it does investments really well. One of my favorite things about this is that it, like, one of those charts where you can see, like, how data flows. Like, they're often used in analytics to show you how people went from web page to web page. Yeah. This shows you where your money is going. So it has all your money over the month, and then it shows this much went over to rent, and this much went to your car, and this much went to groceries.

Sankey guy. Ram. Visualize. Sankey.

There's a a lot of these financial tools,

that want you to export your information from your bank, import it into the app, or even worse, hand enter everything.

Yeah. There's no syncing. Right? So, like, they oftentimes use Plaid, for syncing, which connects your your to your financial industry, what or your your wherever your account is and imports all the transactions. If it does not have syncing, I'm not touching it. Not because, like, I I get that there Yarn some security implications there of, you know, giving some of them deals your credentials. Yeah. But if I want to actually use a tool, I'm not gonna keep up with it. Yeah. Every week, I have to input my my money. Oh, man. That drives me crazy. I've been

Yeah. Well and and and if you are gonna pay for 1, I gotta say, Monarch is great. The the the coolest thing, maybe not the coolest thing, is the web app is way better than the native app. Like, how often do you see that? The web app is is incredible.

The desktop app adds a whole ton of extra features. Either way, if you're even looking just for UI inspiration for this type of thing, they do a great job. I do have a referral code. So if you want, if you want to give me that referral, you can click that link. Otherwise, it's just monarch money.com.

So, yeah, a big fan of this. Obviously, not sponsored or anything. It works in Canada.

Peace.