#20 – Adam Wulf: Muse

Even if it was out of our control and we had to just walk away and we didn't have time to, to land the plane softly. I think that's the wonderful thing about Muse and its architecture is everyone still would have been able to use Muse and still would have had access to all of their data and everything still would have worked.

Even if the sync engine had gone offline, it wouldn't have been ideal, but that's the wonderful thing about local-first in the architecture we chose is the The kind of the worst case was actually still pretty good. Welcome to the localfirst.fm podcast. I'm your host, Johannes Schickling, and I'm a web developer, a startup founder, and love the craft of software engineering. For the past few years, I've been on a journey to build a modern, high quality music app using web technologies.

And in doing so, I've been falling down the rabbit hole of local-first software. This podcast is your invitation to join me on that journey. In this episode, I'm speaking to Adam Wulf. The engineer and solopreneur behind Muse, a local-first canvas based tool for thought. In this conversation, we talk about the evolution of Muse as a product, company, and the people who made it, reflecting on the joys and struggles of building software as a team of one.

Later, we're diving deep into topics such as analytics and distribution of a local-first app. Before getting started, also a big thank you to Convex and Electric SQL for supporting this podcast. And now my interview with Adam. Hey Adam, so nice to have you on the show. How are you doing? Johannes, really good. thanks for having me. I'm thrilled to be here, frankly. I had you on the backlog list for this podcast for a long, long, long time.

And frankly, without you and another Adam Wiggins and Mark from the co founding team of Muse, this podcast probably wouldn't exist because the MetaMuse podcast has been a huge inspiration for me. I've learned so much about it. I'm still a bit bummed. That is currently on pause. Hopefully it's coming back at some point, but I wanted to dig deeper into all things local-first. This is why I've started this podcast roughly a year ago, and now I'm super, super excited to welcome you and the show.

So for those who are listening, who don't know who you are, would you mind giving a background? Yeah, I'm Adam Wolf. one of the early members of the Muse team. I think number five, it was Adam and Mark, Julia and Lennart. And then I came on board, almost five years ago now, gosh. so it's been quite, quite a long journey, with Muse. And then of course, I've been solo for a bit over a year now. We can, we can get into all those details, but I've been a developer, an entrepreneur my entire career.

So. Early in my career, I started on the web, co founded a web calendar startup, right before Google Calendar launched. And then, worked in enterprise software for a while, lived in Portland, Oregon, which I loved, the Pacific Northwest, in the States is absolutely beautiful. after that adventure, moved back to Texas, worked with Flexbits for quite a long time. I don't know if many of your listeners use, Fantastical, but it's a wonderful calendar app on the Mac.

So I worked with them for, I think, five or six years. which was wonderful until Muse and then, jumped in on the Muse train and have been here ever since and I've, yeah, I've been loving it. Yeah, boy, I mean, already 5 years. I remember when I was sitting down with Adam Wiggins and he's been telling me about this idea for, for Muse and he showed me some first prototypes and, I was blown away by, like, We're just coming along at this point.

And I think there wasn't really, there wasn't really the killer app for iPads yet. And, I remember how, like almost obsessed Adam was at this point with like, just trying to like use the pen. And I was like aware of the existence of the iPad pen, but for the metum for the. The Muse app, this is where it really clicked for me. Oh, like this meeting, this, this makes so much sense. And, yeah, that was five years ago. And since then Muse has gone through quite the journey.

So, without going too much into it myself, maybe you want to walk us through, what did the last five years look like on a high level through the chapters of Muse?

Yeah. Yeah. so Muse is now on version three, I think in some ways. You could chop it up into Muse 1, Muse 2 and Muse 3. Muse 1 was, iPad only. It was, local-first in a very direct way because there was no sync at all. All of your data just lived on the iPad and that was it. so it was just you and your iPad and your local data. It was just a private thinking space. Muse 2, we spent a lot of time building the sync engine, which it still runs on.

And then that brought in Muse for Mac and still with the local-first roots. So all of the data lives on the Mac, all of the data lives on the iPad. And then our Sync server, helps keep those in in track together. And then Muse three, which we launched, in late 2024, was collaboration. And so still local-first, but now not only could you sync with all your devices, but you could start sharing and collaborating with other people in real time as well. And so those are the big pieces.

since I live in the code, I often think of the chapters of Muse in that way. Like, how did the code change over those chapters? That's not the only thing that changed really, right? There's also like the people behind the code. Yes, exactly right. What are the chapters there? Exactly right. so I believe the very first chapter predated me. It was Mark. Adam and Julia were the three founding members at Ink & Switch, and it started there as a research project.

And then after they decided, Hey, I think this has legs. Let's try and productize this. Let's pull this out and really make a go for it is when Lennart joined the team, as the designer. And so he came in, it was the four of them. I want to say Lennart was there maybe three to six months before they reached out to me. Might've been there a bit longer. I came in, gosh, 2020. everyone remembers that year and nobody wants to. so it was, it was right as the lockdowns were starting, right.

As everything was, was going on. it was funny. I've, I've worked remotely for gosh, 15 years now, something like that. And so, Of course, everything changed in 2020, but, working remotely for an all remote team was a very natural thing for me. And so, it was a wonderful, distraction from the current events, of course, but it was just a wonderful team and a wonderful way to work after that. We brought in a couple new folks.

Linda came in and Henry came in, Linda came in as a storyteller, to really help Adam, especially on the, the marketing side, kind of the web content side, she did lots for the website and helping tell the story of Muse and bring the story of Muse to more people. She did a lot on the, with the video and with YouTube and, really great work there. That was.

essential, I think, for Muse. And then Henry came on at an important time, building the, the Go server, which is the backbone of the sync engine. So he and Mark really carried the load on the server.

Building that and I think it's worth noting that at that point, Muse, unlike the way how it operates today, at this point, it was really more like a traditional startup where, they, they brought in venture funding to build up that team and to get this off the ground before there was a product that had revenue, et cetera. So that was the foundation that this was even possible to bring on all of those people. Right. Yes, that's right. Yeah. I think I'm trying to remember.

I don't remember the numbers. So don't ask me how much, how much we raised, but we did raise from, quite a few angels, Adam and Mark, at the beginning, brought in a significant portion. I think even by the end, they were the primary investors.

But it was that investment money that let us grow that team and, build from, from scratch, which is gosh, one of the hardest things about building any new software product is either you don't have any investment and then it's just you working alone in your garage, trying as hard as you can, going as fast as you can, which is often what I'm doing right now. Not necessarily in a garage, but still, yeah, yeah, exactly. I think lots of people do that. I've done that quite a few times in my career.

And, A lot can come from it, but of course, your, your velocity, you know, the speed at which you can develop is constraint with time and money. and so having, having those investors early on was a huge help to be able to grow the team and get that vision out there. Of Muse within those first few years and to kind of foreshadow already the next second big chapter in Muse's history at some point, Muse, the founding team, et cetera, including you made some pretty big changes.

So tell me more about that. So it was, mid to late 2023, I think actually this whole time, as I've been talking, I've. I've had my years backwards. So it's 2023 when this is happening. Not 2024. 2024 was, after all of this, it was mid to late 2023. We realized, this is not able to sustain the team. And so what are we going to do? there's a couple of different options. the obvious one is. Peace out. We enjoyed it. The whole thing shuts down and the lights turn off and good luck to everybody.

We, we didn't want to do that. we know we love the app. We'd love to be able to continue using it, even if we just had to use it offline. But we wanted to at least a graceful way for all of the existing users to either continue using the app. And at the very least, like table stakes was. Muse is local-first, the entire purpose and premise is, is having local access to your data and protecting your data.

And we want to make sure that that continues regardless of what happens to the app on the App Store and all the other things. How can we make sure that, people still have all of the wonderful work that they've put in exactly and to just, draw like one bridge to, last year's Local-First Conf, where Martin Klepman gave the keynote. I'm not sure whether you've seen the keynote. and I highly recommend anyone who's listening to check it out if they didn't see it.

But he was pointing to one aspect of local-first, which he calls, our incredible journey proof. So since for a lot of ambitious startups, at some point, the lights go out and there's a last block post that comes along with it, which is our incredible journey, either being acquired by company X and the product gets shut down or product just gets shut down like that. And. Martin framed it as such that local-first apps should be in our incredible journey proof, which is a very nice way to put it.

And I think that's exactly the bar that you've just meant that you've motivated that you want to hold yourself accountable to.

Exactly, exactly. And I think even if, you know. Even if it was out of our control and we had to just walk away and we didn't have time to, to land the plane softly. I think that's the wonderful thing about Muse and its architecture is everyone still would have been able to use Muse and still would have had access to all of their data and everything still would have worked.

Even if the sync engine had gone offline, it wouldn't have been ideal, but that's the wonderful thing about local-first in the architecture we chose is the The kind of the worst case was actually still pretty good. The worst case was actually still pretty good. And it was way better than kind of the usual, startup company that disappears. But we really talked about, okay, how, how can we actually do even better? How can we land this plane softly?

How can we make sure that everyone gets the data they need? We could, spend the last few months building export tools and integration tools to help people get their data out. Before the server shuts down. and I offered and said, I'm entrepreneurial. I've done this sort of thing a lot. I know we haven't been able to build legs enough to carry the whole team, but I think that as a single person, I can keep this alive and I can keep this, I can keep carrying that torch and keep carrying that dream.

so I put, I put my name in the hat. We. kept looking, we looked, we talked with, some potential acquirers. We talked with, of course, Ink & Switch. we tried lots of different things. Adam Wiggins has a blog post that really talks through, the whole story of Muse and especially that last chapter of Muse. So if people haven't read that, you can look, find that on his website too. and so, the team talked and. That's what we decided to do.

We decided to say, hey, if there's a chance that we can keep this thing alive, then yeah, let's, let's find a way to, to be able to hand it over to, to me, to try and keep carrying forward. And so, the official transition date. was early October 2023. I got the year right this time. So, yeah, about 15, 16 months ago. So it's been, it's been a long time and I was thinking just recently, like, oh, my gosh, I cannot believe it's been over a year already.

but yeah, I've been, it went from a team of 7 to a team of. Just me, that, that early October and, that was a transition. I can tell you that. That was, it was, it was rough for all sorts of reasons. I think it's super fascinating because this has given Muse a second life and a second life that, I really haven't heard of other startups, products, et cetera, who've. been on a similar path.

I thought about it in a way where the initial joint team effort, the investment resources, et cetera, has kind of gotten Muse into escape velocity and on some sort of, trajectory. That now, that you're out in outer space where you need less resources to just keep, keep on the path. now you can keep going by yourself. That's obviously not something that can be easily repeated since typically the intention of investment is to make a big multiple.

And I think that might be no longer the assumed path for yourself. So, I think you're now in a much more sustainable path. So, in a way that gave you a unique opportunity. So, I'm, I'm curious, what were the most surprising things for you over the last year or so since that transition?

Man, so many things. It has been, such a wonderful year and such an incredibly tough year. And I think there's so many things throughout the entire five years that I can look at and really enjoy. And the older I get, the more I realize that You know, life has chapters and that there are moments in time and then those, you know, enjoy them or you don't. And then the moment is gone. And so I, I look back and, the early years with the team was amazing.

the Muse team by far has been the best group of folks I've ever worked with. just an incredible team in terms of just the people, but also the interesting technical, problems that we all over came together and, Transitioning from that very supportive team, and just very efficient team. We worked, we worked really well together. we made decisions well together and we moved forward together.

Well, to suddenly be solo was, it was a tough transition And, kind of to use that metaphor where, because it's local-first, and because we're You know, a small scrappy team. We're not, you know, professional house builders that build neighborhoods every week. Like, we're a bespoke house builder. And so then, we've built this wonderful house, and then the rest of the team leaves. And, I suddenly have to find out, like, huh, why, why is that pipe knocking?

Or, oh, there's this weird leak over here. Or, huh, yeah, I forgot. I do need to vacuum this room once a week. Or, you know, like, I I don't know where the metaphor ends, but you see where I'm going there's, it used to be able to be maintained and, and held up by the team of seven that we were. And then suddenly to be holding it all by myself, because this happened right at the time we launched Muse 3. So right as collaboration changed, that came with a pretty sizable database migration.

For users where the local corpus, the local database they had on their devices needed to be migrated as well as their synced data on the server needs to be migrated. So there are lots of new moving parts and any big new release comes with. You know, exciting new bugs. that, that was by far the, one of the hardest transitions ever was, everyone packed it up really nicely and handed me the box and said, good luck out there.

but then suddenly to be standing there holding the box with all the stuff and realizing, okay, like, I've got to do this, you know, I've got to hold on. And so it was, it was a big transition those first few months. Lots of support tickets, lots of code, lots of bug fixes and all the usual suspects, in terms of a big new release, none of the bugs were huge or terrible. It was just lots of little bitty things and typically Just after launch, this is where you have increased everything.

Like you have increased bugs, bug reports. You have increased messages that you need to respond to increased public things that you need to comment on, like make sure to leverage the positive buzz, et cetera, respond to more critical things, et cetera. And that would have been hard enough. To pull off, with, the full house, but now you've got to take on like all of those increased, issues by yourself. So hats off to, to having, obviously having gone through that.

Yeah. Yeah. Thanks. And, I mean, hats off to the team as well for, for helping that transition because every single one of them knew that this was the process, you know, that last month, that last two months and. Everyone put in a tremendous amount of work to help that transition go smoothly. And so I owe, so much to their work through that transition. to make that possible. I mean, it was huge. It couldn't have been done literally by just me.

It was the team that helped that transition go through and. Yeah, it was, but it was a, yeah, it was a tough spot because of course, there's a huge, a huge blog announcement of "Muse is closing", but not really. We're not closing. By the way, here's a giant new release. By the way, here's a bunch of new press and here's a bunch of new users and feedback and questions and all that kind of stuff. And so, yeah, it was.

It was a lot to, reply to all of those things and fix the bugs and try and prioritize as, as best as I could. So, like you say that that's a, that was a long and big transition, but I think now you seem to have made it quite cozy for yourself in that, new old house. so how did you go about just making things sustainable for yourself where I think you just need to Come to grips to like a new kind of pace and cadence for what is a realistic roadmap?

How do you slice and dice your week into, this is the time I allocate to support. This is the time I allocate to marketing. This time I allocate to bugs. sometimes just unexpected things happen and you might be suddenly facing a bug that is really critical. But might be like of the shape of three weeks. how did you handle those sort of situations? Yeah, I think, I think the biggest change was as a team, we were fighting for scale.

And so the biggest thing that we needed to do was find large numbers of people. That fit Muse, so that we could grow revenue dramatically. So that means the kinds of things that we're focused on are broadly speaking, of course, new outreach, new features, of course, we said like the majority of 2023 was focused on teams and that was in collaboration. And that was because that gave us an entirely new customer segment.

That we could potentially go after everything has trade offs and so in, in reaching for those new, customer segments, we're building new features, which necessarily means that time spent on bug fixes or small improvements or small tweaks, things like that, are second place to the big new features because the big new features bring in. A bigger quantity of new people than the incremental smaller fixes would.

That I think is the biggest thing that has changed because then going solo, I don't, I don't have the resources to try and reach for enormous new audiences. The most important thing to me going solo is, okay, I built this house. Let me make sure everyone's happy living here. Let me make sure all of the current customers are happy. the. Kind of professional user, the solo user who kind of thinks privately and deep thinks in Muse.

That's their, their cozy place to kind of retreat to and think through. That's my core customer. I don't need to expand beyond that. And so the big shift was, then focusing on, okay, let me take every time a support ticket comes in, that's a priority because as a single person, I don't have near as much time. To handle support tickets. What was a very low percentage of support time for seven people became a very high percentage for one person, right?

And so, so as a single person, I can't, I just can't dedicate that much time to support, which means I needed to prioritize all of those little things that people would. email in about, man, I can't even think of them now, but you know, just small little like, huh, isn't it weird that when I tap over here, this other thing lights up. Can we just not have that happen?

And that's been a bug that's been there for three or four years, but kind of doesn't matter because it's just a little thing and people work around it.

But. When it's a, you know, a little burr on the edge, when it's, when it's just a little rough area that kind of collects support tickets, that's what I focused my attention on those first few months was, okay, how can I smooth out all of these edges that we had known about, but we're never the priority of the team because as a team, we were focused on the bigger sustainability question.

And now that that big sustainability question had essentially been answered, that's what I needed to focus on was all of the small little tasks. And so, you know, card alignment was one. And so now there's a little keyboard command to just, shift cards and into card alignment. Um, a few. You know, small little bugs with selection or with the way of the cards worked or, one that, that I, put out, I don't know, relatively recently was, links to apps, app links, as opposed to web links.

So there's a handful of other apps that quite a few folks use with Muse that have. Local app links, and they'd like to be able to drag those in and create cards. And so smoothing out the URL card, the link card flow in Muse to better support, various things, things like that, right?

Like it's taken individually, no one would notice them, but then taken collectively, it actually makes a significant impact on the support load, which then frees up a bunch of time to say, okay, now, now what do I want to think about? What's the next big step, but that makes so much sense to me. And just to reflect on this also a little bit in regards to, to my personal journey, working on Overtone and working on, on Livestore.

I also didn't have the luxury to work on all of this, kind of in parallel with, distributing the work across an entire team. I think of myself as single threaded. I need to work on things sequentially. And the longer I'm working on one thing, the more I'm starving another thing. So I need to be like very, very careful of what I'm putting my effort on and what I'm taking on. And, also, if.

What I'm working on, if my attention is sort of like a bucket, if there's like, if there are holes in it, and every time I'm trying to do something, but it's constantly dragging me down, I need to plug those holes first, since it's not just hurting maybe someone else who has a bad time using this, but I'm also having a bad time and one thing I've really noticed about myself is like, I really need to, prioritize for my own velocity and my own happiness.

Working on this only with that, I can build momentum and keep the energy up since I think that's probably also, something that, you've experienced going from a team to working solo. Like a team provides sure, like, sometimes a team can be, there can be some things that, take energy away from you, but a good team and you had a fabulous team.

Gives you so much energy and now you need to, be sort of like on subsistence, economy for like, you need to, make sure that you bring in your own energy and anything that erodes that energy is so critical.

So, yeah, I have a huge amount of admiration for like, how you've been able to, to go, and what you've been mentioning in terms of maybe you didn't for the longer time work on some bigger parts, but just making all of those, you already had a big part done in the past as the foundation of Muse. And now working on like making everything smooth, ironing out the little kinks. And I think that's the best case scenario for Muse users because now things are getting better.

It's already in a shape that as a Muse user, that's what I wanted. And, I think also one of the biggest, question marks of like, is this app going to go away long term has also been answered. So I think Muse, as long as it's sustainable for you, I think it's a fantastic outcome for, a product like Muse. So I'm, I'm very happy about that.

Yeah, exactly. I think you've summed it up perfectly. it's as much about. Muse the business, of course, and to make sure that that stays sustainable, but. It has to be sustainable. for me as a single person as well. And so prioritizing which of the holes in the bucket do I need to prioritize for my own sanity sake, regardless of what everyone else needs, right? It's just either taking up too much of my time or it's too much of a drain. the community has been wonderful.

and, there's a discord community where, lots of the folks chat. And so they'll bring up. Some really great ideas. They've been a wonderful way for me to bounce my own ideas off of to say, Hey, I'm thinking about this. What do we think about this? I've noticed people have asked about this. because the biggest part for me of losing that team is, losing the people to talk with right? Like, when you live on a deserted Island all by yourself, you go crazy. You need other people to talk with.

And so the community has, has helped fill that role for me in many ways to, to be the sounding board, which has been great. And then prioritizing those gave me my time back.

In terms of the support load, because those are the tickets I prioritize first, and then I was able to say, okay, now, from the business standpoint, what is it I need to do for Muse as a business, as opposed to Muse as a customer for customer support or personally or anything else and this past year, 2024, I focused on two things primarily. The first one was Setapp integration, so I don't know if your listeners are familiar with Setapp. It is essentially an alternative App Store.

You subscribe for a monthly fee and then for that single monthly subscription, you get access to everything in their library, every app. So Muse is now one of those apps. And the way that's, that's Setapp, I don't want to get into the weeds about the, how they manage the business and revenue share and all that kind of stuff. But the point is, is out of that monthly subscription, it is revenue shared with the applications that that user actually uses.

And so if they change what they use months, month to month, the revenue share changes month to month. And so it feels fair to you as the app creator. Yeah, so it's fair to me as the app creator because I get paid based on usage. it's also fair based on kind of the type of app. And so what would be. A 99 cents a year menu bar app in the App Store, takes a smaller share than Muse, which is a significant, subscription. And so it's fair, both for time spent and for, the revenue split.

Which is great. And so that has been wonderful because it has brought in an entirely new wave of subscribers who would otherwise never purchase a subscription because they're on Setapp specifically because they don't like subscriptions. So they're going to have one to Setapp and use everything inside of Setapp instead of having 7 or 10 or 12 on the App Store that they manage individually.

And then similarly, the people that do have individual subscriptions are typically not the people that are going to have a Setapp subscription. And so it's really, you know, the Venn diagram has very little overlap, which, brought in a. completely new segment of customers, which was helpful. Where do you, yourself fall into this Venn diagram and how did you arrive at that?

This is integrating with Setapp actually deserves to be like on your roadmap for a given year, since there's only so many things you can do. So choosing your priorities is really, really important. How did you arrive at, prioritizing working on a Setapp integration? Yeah, it was an important piece because so throughout the life of Muse, the early years revenue grew and then that last probably year and a half revenue declined. and so as I took Muse over solo revenues, declining month over month.

And so every time I'd wake up on the first of a month, I would have less money coming in than the month before. Right. which is fine in the short term, but obviously like everyone knows where the, where the slope intersect. hits the zero axis. So that that was a big priority was okay. How can I, how can I change this trajectory? it needs to not be going down. And so focused on, new revenue and new customers was a very important. Piece of solving that.

And that has been, really my guiding principle over the past year was out of all of the App Store users, how can I. You know, take a very kind of traditional product management approach and measure. I get this many people from App Store browse. I get this many people on the product page in the App Store. I get this many downloads. I get this many people putting their email address in. I get this right. Like you can go down the entire, the entire funnel.

And where people getting stuck, where is it confusing? Where's the biggest drop off between people who think, oh, yeah, maybe I'll get this thing Muse a try. Oh, it looks neat. And then sometime later they go, eh, no, thanks. Right? Like, why did, why did they go? No, thanks. Like, what, what was the miss? So I focused a lot on, that on what's called the bottom of the funnel. So after they download, after they log in, what is that first time user experience?

And there's still quite a bit more that I'm, I'm still focused on there. And the other thing I worked on this past year was Setapp, which was top of the funnel, bringing in a completely new pile of users that had otherwise essentially not had access to Muse because they would never use it on the App Store. And so the combination of those two things has really helped flatten that decline.

And so the Muse revenue over the past year has stopped, declining so dramatically and has really started to level off, which is important. So from use going forward over this coming year, the goal, of course, is to continue that trend and start growing again, start growing that user base. And that's going to be, more of that same strategy more, of course, at the bottom of the funnel.

There's lots of things I still want to improve about the first time user experience, first time onboarding, kind of early customer education with a website. we used to have a, a wonderful video handbook that showed all of the fantastic gestures in Muse. So building something like that again to help, to help new users become familiar with the very unique. interactions that Muse has, as well as some things at the top of the funnel to bring in more, more customers.

but I think holding all of those perspectives in my mind has been one of the weirdest things and I think is one of the most difficult things about being a solo entrepreneur because with a team, of course, you can say, okay, this other person is going to handle, you know, broadly speaking, they're going to be the marketing person. They're going to handle the funnel. They're going to think about partnerships.

They're going to think about content, marketing and social media and all that kind of stuff. I get to focus as an engineer on just the sync engine and just a lot of the problems and just bugs and customer support. And this other team member gets to write, like, obviously you separate your concerns, but when you're working on your own, You have all of those concerns in your head at the same time and a lot of times those compete with each other.

that's been a very, I don't know that there's a correct answer. I've kind of, come to my, my Zen place and realized that I cannot do it all. I cannot do what I want. I don't have enough time to do what I want. And frankly, I don't have enough time to do what I need. So it's, you know, I, I can only prioritize as best I can, but there is way too much on the plate. And so I, I've just had to accept that, you know, sometimes I'm going to pick stuff up off the plate and it's going to be a mistake.

Oops. Let's get back to it and go to the next thing and keep pushing forward and prioritize as best I can, which, was another kind of realization over this past year was just the act of prioritizing. Takes away from the time you have to do right? And so everything, everything is a trade off. Deciding what to work on is a trade off. Working on it is a trade off. Like you're always giving up something. that has been.

Easily the hardest, the hardest piece of doing this alone, there's a few aspects to this that might not be super intuitive unless you've done them, which is if you are so far, mostly like the engineer, or you're mostly, someone who's working in marketing or doing something else, you don't really do like the context switching between switching between the entire modes.

I think this might be most intuitive to a founder who has started out by themselves or with a very small founding team in the early days where you're switching between the hats constantly. But that context switching is a double-edged sword. It might, the positive side is that through the perspective of engineering.

You might have a much more informed perspective now to be more effective with your marketing hat on, but also that context switch, doesn't come for free that might, when you come back into engineering, you might've already forgotten a lot about the context that you had before. and another thing that I've actually for my own health. sake, mental health sake, I actually give a quite a bit of weight in terms of prioritizing what I work on.

in terms of what I feel I have the most energy for, what do I feel like I have the most inspiration for? This might be not the most, if, if someone is like super structured, like a very rational mathematical in terms of like, okay, by all of those metrics, this is the most important thing. I might still work on this. Second or third, most important thing, just because I know I'm going to have so much more energy working on that and I can build up momentum this way.

So this is something I've, I've seen for myself that this works the best factoring into, into my decision making on like what to prioritize. I can totally see how this is one of the hardest things in, in your journey. but given that you're still on this journey, I assume you're, the kind of person who sees the glass half full.

So, I'm curious, like, what were some of the highlights of the last, or since this new chapter, transitioning from Muse as a team to Muse as a solo endeavor, what have been some of the, like, the true highlights?

the piece over the past year, year and a half that I have loved the most by far is, I've started two things and they're, they're related. So, in some ways, they're just one big thing. I call it the Muse for Muse interviews. And so Muse, of course, means inspiration, right? So, like, who is the inspiration for Muse? It is all of the people that are, that are using Muse. It is the new people that are just finding it and are excited to get that, where it just really fits for them.

there are still so many that have used Muse since, you know, version one, since it was just a, twinkle in the eye and test flight and hadn't even been out to the App Store yet, but were the very, very first. Kind of test users. Do you call them users? Uh, yeah. So I was talking with my wife and she, she called them Musers instead of users, which is fun. So yeah, but I've started, scheduling interviews and saying like, Hey, I just love to, to learn. What do you do every day?

How does Muse fit into your workflow? what else, what other apps do you use? What have you also, have you tried? What really grinds your gears? What are those little rough edges for you that are just annoying, but kind of don't matter, but just take you out of the flow. Maybe a little bit. Those have been wonderful, both just for the energy and the excitement to hear from them and, to hear how Muse is making a difference in their workday and in their flow.

And then, and it's also, wonderful because you can start seeing patterns and the way that, people react and that the types of things that they bring up dark mode is a common one, right? Like there's so many times in support where I still get requests for dark mode. And so this coming year, I would love to do something for dark mode. but as an example, as I'll talk with somebody on one of these interviews, maybe it'll be 30 minutes, sometimes an hour on a zoom call.

It won't just be an email that says, dear Adam, please make dark mode. Thanks. Bye. Right. But I, I actually hear, Oh, this is where they're doing it. This is why they want dark mode because they're in this library or in this class, or they have this thing or who knows what, right? Like, another one I get is, Oh, please enable more zoom options. Okay, great. Right. Like that's, that's a neat feature.

But then when you're talking with somebody and they're talking about how, Oh, The font size in this scenario is actually a bit too small or sometimes when I don't have my glasses on or my readers on the other side of the room, I'd really like to be able to zoom. And so you start hearing how the accessibility feature that to an engineer's mind is just a feature really fits into the day and really fits into the flow. And so that's been super inspiring.

And you might also find some things that were just, you as an engineer note, oh, this is such a small thing. You just haven't done it yet. And it might for someone who's using it, just make all the world of a difference to them from taking the app from like. being wished for that they couldn't use it to actually using it on a daily basis.

And it brings, like I say, it brings so much energy and motivation to you as a builder to hear those stories and like, knowing, okay, here's Alexandra over there and Alexandra is like loving it in this use case, and I didn't ever, plan for that and it's happening. And that, that's great. Yeah, exactly. Exactly.

And so that's something that, mean, early in Muse's life, of course, it came from research and so user studies and user interviews and interactions and stuff were a huge part of early Muse's life and, and really a huge part of, of its early success. I started doing these interviews, probably about four months ago, something like that. And gosh, with the impact they've already had over those four months, I wish I'd done it on day one. You know, and I wish we'd done it, every day since then.

And so a big piece of going forward is how can I get a consistent flow, especially a brand new users coming into Muse? And what is that brand new user experience and then a consistent flow of longer term users, because I don't want to over optimize for the long term users, because then no new people are ever going to be able to fit. But I also don't want to over optimize for the new users, because then they're going to be super happy for 6 months until they're a long term user.

And they find out that long term user problems are never solved. So it's a balance of making sure that I'm. Like, I mean, like we said, a thousand times already, it's trade offs kind of all the way down, but having those interviews with real people using the app in a real experience and just talking to them about their life and about their flow, no matter what stage they're at, whether it's earlier or long term has been really, really valuable.

And I think that the second thing that I'll bring up that has been. Just a big joy and kind of a wonderful, wonderful new thing. I'm starting, highlights for how different people use Muse. And so we have one, that was just posted. that's up on our YouTube. the Muse YouTube channel with, Conrad Levely, and how he uses Muse as part of his, research. So he has a whole handful of different apps that he uses to explore various different topics.

he's retired and as part of his day now, he just loves learning and loves researching and loves reading. And so it is about how he uses Muse in that workflow and over the coming months, I'm going to be releasing more of these and inviting more, both long term and, and new Muse users, to share how Muse fits into their life. Cause that's something I've heard consistently from folks is boy, I really love Muse, but I'm really curious. it's such kind of an abstract tool. Am I using it right?

I think this makes such a huge difference that someone is aware of a certain product and think it's cool, but then they think, okay, what does it have to do with me? And then move on and just seeing sort of the usage scenarios, since like, obviously that person who's using it seems to have figured something out, that makes them more effective, productive, joyful, more in the flow.

And, I want to be like that, but, I need to see it first before I can connect the dots and say, ah, yeah, this is how it fits into my life. Exactly. Exactly. Yeah. Muse is such a flexible tool. It's a, you know, you hand somebody a stack of paper and everyone's going to do something different with that paper. Someone's going to bind a book and someone's going to make post it notes and someone's going to make a small journal and someone's going to sketch, you know?

And so, I think there's a lot of inspiration that can happen seeing how different people, use Muse and seeing all of the different ways it can fit into your flow. And fit into your day. So, yeah, I think those 2 things have been the biggest piece for me is interviewing and then, also just highlighting and then being able to share, how community members use Muse with the rest of the community has been wonderful.

So both the interviews as well as the highlights are very strong on terms of the anecdotes of a particular person and you can still remember that. But the. flip side, that's the anecdotes and then the other part is like actual data, that can inform how you're prioritizing, working on something, et cetera. And that can be, I, for me, anecdotes are a lot more intuitive and I've tried to measure enough things that I know, okay. Those measurements are always, only like a partial picture.

Sometimes you, particularly in a local-first context, you don't want to just like flip on telemetry for every user where privacy is really important, et cetera. So how do you modulate between or prioritize between anecdotes versus data and how do you even have you done anything to measure things? And how did you go about that in a local-first context?

Yes. So data is interesting because It's so easy to collect enormous amounts of usage data. Was this feature used? Yes or no. How many times per day was it used? Was it used this week? You know, was it used in the first month of the person? Doing it or only after a month to, you know, like you can, you can slice things a million different ways. so in products past, I have often said, well, I don't know what's important. So I'm just going to collect a bunch of data and I'll figure it out later.

And then later comes around and I have a huge pile of data that I don't know how to look at. And it's just overwhelming. So I wanted a completely different path this time on, this was December, 2023. So a handful of months after taking over Muse, I'd already done a lot on bug fixes. It was starting to kind of get, okay, new users are happy, existing users are happy, the fires small as they were, they've been put out for the new release. Let's look at the data and figure out what's important.

What do I need to look at? so in times past, I've had way too much data and I didn't know how to pull out the answers from it. And so this time with Muse, I've been very purposeful about saying, what are the important questions I need answered? Let me clarify to myself. What do I actually care about? What is the most important thing that I need? And then let me go collect data specifically to answer this question. And that's it. And maybe that data could be used for other questions too.

And there's all sorts of different stuff there, but I'm very purposefully limiting what I look at to only the questions I know matter. And so the biggest question, that I had initially going into it was that customer funnel, how many people hit, hit the App Store page, how many people download, how many people log in, how many people. subscribe, and then there's kind of a, a middle one, which I call activation. So between logging in and subscribing, it's, are they getting value out of from Muse?

Like, have they done something that they've at least played with it enough that yeah, it seems to be, they understand what they're saying yes or no to. So the first thing I did is I downloaded, We, we don't use generally any third party trackers. So all of the data we have about user behavior is on the Muse server and is not shared with anyone else. So it's not used for advertising or for, you know, various other things. that's been a very important piece. And so I've been able to look at that.

Kind of feature usage data. We don't collect any data in terms of what are you physically typing into Muse? It's all about, did you use note cards? Did you use links? Did you use boards? That sort of stuff, right? Do you pull this out out of the sync data or is that a separate thing that's completely separate from the sync? It is completely separate. And so, and there are no circumstance in my poking around inside of sync data. that is a hundred percent kind of. Private tucked away.

And then there's a separate piece that is just product usage data. And so that, and that collects none of the personal information that you're putting into Muse. It's only collecting. You know, sort of, did you click this button or not kinds of data so the first thing I did is I downloaded, did people use this feature? Yes or no, across 30 different features, 30 different, 40 different things. And then did this person subscribe or not?

And I gave me a giant table of data that I looked into and said, okay, which of these. features using which of these features is or is not correlated with subscribing and I narrowed it down to, I think, six and so if people use all six of these features, then they are more likely to subscribe than not and. What that means to me is, it's obviously not just, okay, great, let me go force everyone to do these six things and then clearly they're going to subscribe more.

No, what it means is that, okay, doing these six things gives them a real good feeling for what Muse is. And once they have a good feeling for what Muse is, those kinds of people are going to more often than not subscribe. So I have that activation. That's what I call activation. so the report that I run connects to, app figures, which connects to the App Store for App Store metrics.

I can also connect to the App Store directly because there are sometimes information that I want to get kind of the raw data for instead of app figures, aggregated data. I connect to the Muse server to get, more detailed analytics about subscription and about activation and things like that. and I connect to the, we use Fathom for website analytics. So it is a very privacy conscious website analytics tracker. And so that gives me number of visits, number of click throughs, things like that.

so I pull all this data from three or four or five different sources. And then together that gives me full visibility from number who see the website, click through the App Store, download link all the way down. And so once I have that data, that's when I can say, okay, let me look at new user onboarding. What happens if I provide this kind of video, or if I provide this kind of tutorial, or if I change this kind of thing, is that better or worse for this single step from download to activation?

Not even caring how it affects subscriptions or anything else, but like, can I just change this metric? and so the times I've done this over the past year, year and a half have been for onboarding, of course. So the first tutorials that people can get. Also, Setapp has helped because Setapp takes out the subscription altogether. And so then that very last step from download to log in to activation to subscription p user.

The only thing I need to care about is download to log in to activation once they're using these consistently, then that's when Setapp recurring revenue comes in. so that was important on the Setapp side. On the App Store side, I implemented, sign in with Apple because Muse requires an account, for the sync server. That means the first time download experience, people load up Muse and they see, hi, give me your email address.

Muse is very conscious more than I think almost any other company I've seen or worked with about privacy. But when the first time user experiences. Hey, buddy, give me your email address. It doesn't, it doesn't inspire confidence. and so I implemented sign in with Apple and then that lets people say, okay, let me use that. I can choose a private email address. I can maintain my privacy, but still kind of create the account that allows for them use sync service to work.

So that helps the download to login step of that entire funnel flow. And so it's been rewarding to. focus on very specific places in that funnel and say, okay, this piece right here, right after the download, what kind of context does that person have? What do they need? What would be helpful? maybe new images in the App Store or maybe. better tutorials on the website, or maybe, you know, fill in the blank, but how can I get this from 92 percent to 96%?

And then in theory, that will also have downstream effects at the bottom of the funnel, but if for whatever piece that I'm looking at, that is the biggest. problem that has been very helpful from a prioritization standpoint. And that has been very helpful, to keep me focused because they're, you know, like I've said before, there's too many things for me to work on that I have time in my life to physically do.

And so when I am building, it can be motivating and really helpful for me to say, Okay, Adam, remember, you're focused on helping this person at this step in their journey. they would love to use Muse, but they can't because they're stuck. And so you're going to help them. How how can you help this kind of person get unstuck? and see what Muse is so that they can decide whether it's a good fit for their life or not and for their workflow or not.

and so that's been very helpful to collect very specific, and still privacy preserving data that helped me make decisions in terms of that. That flow, there's a handful of other statistics I look at in terms of like App Store revenue or Setapp revenue, subscription counts, cancellations, those sorts of things. But broadly speaking, that funnel data has been the most important and for prioritizing my, my work and in the world of data, it's a very small piece, compared to the data pile.

I've seen at other companies or in previous things, it's it's really helped keep me focused. In terms of Muse being a local-first app, as opposed to being like a more traditional, cloud based SaaS app. Is there anything that you thought about different when it comes to, getting better insights through data into how users are using it?

So, there's this interesting balance between, uh, local-first really tries to preserve the privacy, a user and you with the best intentions of like, Building this app for the people who you want to serve. And yet you need a little bit of visibility into this. Have you thought about this for Muse differently than for previous apps? And did you build the analytics stack from a technological perspective in any different way than you've built previous ones?

Yeah. So when I, joined Muse, in 2020, the analytics stack that's still being used was built already and that was, implemented entirely on the Muse server. So that way, none of the analytics data went to a third party. It kind of stayed within Muse. And so that was very helpful. And then, like I mentioned before, that analytics data that we collect is entirely separate from the actual synced data of a person's library in Muse.

Is there still like the same sort of identity behind it or how does, user privacy preserving look like at that point? Do you, for example, like have something that is, identifying a user, but you hash it so you can't like, correlate it anymore or, how are you going about that? Yeah, so it does use the same user ID. And so I can see, which is helpful for our support tickets. And so when a support ticket comes in, I can see, obviously, when the person signed up, if they're subscribed or not.

And I can also see, which devices they have synced to the sync server and how recently those devices were connected. Because far and away one of the most common support requests I get is Usually a one line email that says: Hey, sync, is it working? Or, Hey, there's a problem with my iPhone. Uh, how can I fix it? And so I can immediately look and say, okay, I don't see an iPhone on their account, clearly it's not connected correctly. And so that helps me reply.

but that, that is kind of the only connection is that user ID. So I do see. User behavior, and then there's a separate bucket that has all the user synced data. But the most important guiding principle through the entire life of Muse has always been, the user's synced data, their library data is off limits. It, there's just, it's just never looked at. It's never looked at by a human and it's never looked at by a robot either. Like we don't run analytics on it.

We don't run scripts to see how things do like it is. It is its own little box in the closet that is not touched. And then that way, the only data that we see that is used for analytics is, the feature usage data that we specifically send, that does not contain any of the actual library data. None of the text, none of the ink, none of the boars, none of the content, none of that kind of stuff lands there. It's just, oh, they made a board card. Okay, great.

I need to know if people make board cards or not, because if they don't, what are they doing? Because Muse is based around boards and whiteboards. Yeah, I think it's this interesting balance where with local-first, we obviously want to move beyond the status quo of how software is being built traditionally yet, or in terms of how software is deployed and architected in a way traditionally, but yet a lot of the more traditional. Product management learning still apply.

Like we still don't want to fly blind. We still need to understand what the users are doing, et cetera. So there is a slight tension there between still like knowing how are our users successful with the app? Are they struggling? Where are they falling off? And yet, The, that the user's private data is sacred and you don't touch it yet. You don't even have a way to look into it as it's encrypted, et cetera.

So I'm curious, like what will the ideal analytics stack for local-first apps, maybe look like in the coming years to have some intuitions or some wishes for like, this is what the ideal stack there would look like. And someone should build it.

I think the way that we've done it at Muse, is a really good first step and is, is really good. I think it's, table stakes for the way that any business should operate where the user's private data is on one side of the world and the data you use for analytics and for product decisions is on the other side of the world. And those two just never meet. because there's no, situation where any kind of product person should have any kind of visibility at all into someone's private data.

And so that, I think, is the most important piece, that was there from day one at Muse and continues today at Muse. collecting as little as possible, I think, is also important. And, that's been true with Muse where the third, it's so easy to say, Oh, look, a new data provider. Let me just go like, let me go integrate mix panel. Let me go integrate apps fire.

Let me go integrate, you know, you could put in four or five SDKs and suddenly start sending out analytics to five different advertising companies with like three lines of code, right? Like it's very easy to do. and I think being very cautious and purposeful about what kind of data you're collecting and making sure you're doing it to answer specific questions is really important. And that's what I've done at Muse over the past year and a half.

And that's what we did at Muse in the years before that as well is making sure that we, the data we do collect. stays just within Muse and doesn't leak off to other third party advertising, firms, and that we use that data responsibly and that one of the ways that we do that is that we don't collect more than we need and we don't collect private things.

Your private data doesn't land in the product decision repository, and that's, I think should be table stakes for any company, but especially for local-first, where, where privacy is, is job number 1 and is really purpose number 1 in many ways of local for software. So slightly shifting gears a little bit to another aspect where we need to kind of reinvent the wheel, a little bit for local-first software, which is how do you charge for software?

And I think in your case, I think you have a somewhat easier, foundation for that already, given that you started in the Apple ecosystem where you can say many things about the Apple App Store, et cetera, like how it charges an arm and a leg.

But, at least from the user perspective, there's already a well trotting path for how are you going to get some money and now you've extended on top of that with Setapp, I think a lot of other local-first apps are built primarily starting from the web, where I think it's a lot more challenging, but yeah, how much of a easy versus difficult part was the getting actually paid for working on the app and, do you have thoughts on, what that could have looked like

when you would have started in the web?

Yeah. I think my default is to always think about things in terms of the almost every single time I go back to the customer funnel, which is essentially what it was, the customer experience. As you mentioned, the nice thing about the Apple ecosystem is the customer experiences. Oh, do I want this or not? One tap on the subscribe button, the prompt comes up and it's either face ID or a fingerprint. And then, so it's essentially like one and a half steps from decision to money on the web.

It's often significantly harder, and that is, okay. Do I want to do it? Okay. Yeah. Let me go click in. Okay. probably have to choose a plan. Let me choose a plan. Okay. Well, now I have to enter my credit card information. Okay. Now it wants my address. Well, now it wants my billing address, which is the same as my address, but it has a separate, separate field. And so then I click okay, and then it gives me the summary and then I click checkout. Right?

So suddenly that's like a four or five step regardless of the, even separate from the decision of, is this a subscription or is this a one time payment or relatively one time payment? so the biggest thing that I think about is how can you make that experience much simpler? and how can you make that experience trustworthy and the nice thing about the App Store is it gives you both. It is trustworthy because it, the purchase is the exact same every single time and it goes through Apple.

So people don't have to trust me. They can just trust Apple and on the web, you have to overcome both barriers. You have to become trustworthy enough that someone says, why should I put my credit card in this random website? And you have to make it simple enough that. On step three out of seven, they don't say, man, this is so much trouble. actually nevermind. part of it, some, I think Patreon helps with some of that, subscriptions help with some of that.

sometimes even if it's a web based service, there might be, iPhone app components to it or Android app components to it, or native Mac components to it, helper apps, things like that. And sometimes those could be paid for even when the web is free. it, it really depends per business, but it's difficult.

Like that's, that's one of the hardest things, especially as an independent software developer to decide what your business model is, is a difficult decision to physically implement all of the infrastructure to make that business model possible to take someone's money. Is difficult and then finding out, huh, this payment provider has four steps, but if I'd use this other payment provider, it would have been two and a half steps. Should I spend another 2 months moving?

I think this is sort of a reoccurring theme that, to pull off local-first. is very hard and to pull it off in the web is the hardest mode so far, since, not just from the perspective of having all of the technical capabilities that a native platform provides that you have it in the web, it gets increasingly better with things like the file system APIs, WASM, et cetera, but on macOS.

At some point you click on that download button, maybe you've paid before, maybe afterwards, and now you have a DMG file. And that is, you can still put it on a floppy drive if you want to, and that's yours. That's hopefully still gonna work. It's most likely still gonna work unless it's like all sassified. But in the web, you have like, Visited a website before and in Safari, if you haven't visited that in so long, it's going to like wipe all of your cash. So what is the equivalent of a DMG?

And then you haven't even started about payment. so that's a lot harder. And I think you've been, smart about choosing, or I guess that's just been inherently an implication of The beginnings of Muse to start in the Apple ecosystem where you could, sort of sidestep a bunch of the still open questions around local-first software by, like piggybacking on a more mature ecosystem in many regards. Yeah, absolutely. I think that's the, that's easily the hardest part about.

Building any new product is the technical challenges of whatever platform you're on, the customer challenges of finding a way for them to pay. in a way that is fair for them, and they are comfortable with, and that is trustworthy. And whatever that process is, is going to carry its own technical ballot baggage of implementation that you have to carry. and so it's just a difficult thing to balance. what is that business model?

how can I implement this business model in a way that the customers are comfortable with? Are comfortable with and even if you figured out those first two, sometimes the technical hurdle to implement it is too big. You know, like we said before, it's trade offs all the way down and that sometimes those, those trade offs, even affect that business model or even affect the payment model.

in terms of the platforms, given there's multiple platforms and more than we talked about so far, looking at the history of Muse, you started on the iPad. A bit later, there was a Mac app. And, if I'm not mistaken, there are at least plans to conquer a few more platforms going forward.

I'm curious whether looking back, you think this was the right sequencing of platforms or whether you could have seen like an entirely different path, maybe going all the way with the web first, looking at, I'm sure whether you see it as a competitor or as a similar app, something like TLdraw. they have obviously started out their journey all the way in the web. And I think they're embracing the openness and the, like, everyone knows what to do with the link.

You click it and then you're already in a new app without having to install it. So entirely different possibilities, trade offs. So how did you think about the sequencing of the platforms and any regrets in that regard? So we started out on the iPad. And this was in the time, right before I arrived at Muse where Inside of Ink & Switch as part of its research and as part of its kind of human computer interaction design research was, what does that tablet experience look like?

And what does it mean to have that form factor to have a pencil where you can write ink and to still be able to type and manipulate with your hands? How can we, how can we make this interesting thing? And so starting out on the, as the tablet was really the heart and soul of Muse and I, I can't see a way that you would get. Muse without starting with that seed. So I think that was, and yeah, in many ways that, yeah, that was the important place from there. Where do we go?

I think, I think we did make the correct decision to go to Mac next. The iPhone was always kind of a helper tool, for, collecting content and for bringing things into your Muse. The next big workhorse was the Mac app. And I remember us thinking quite a bit, we had some experiments for publish to web. We had some experiments for what would a web sync look like. And this was one of the, I mean, really one of the business and resource, decisions and constraints. In some ways forced our hands.

it definitely made the decision much easier because the Muse Mac app shares. 95 percent of the code base, with the iPad, the entire sync engine code base, is the same. all of the board rendering and navigation is the same. It has some differences in window management and tabs and toolbars and that sort of thing. But broadly speaking, the code base is able to be shared, which, of course, dramatically lowers the maintenance cost for our small team.

We thought about web for all the reasons you've mentioned, but of course, that would mean an entirely new code base or an entirely new way to share the code base. You can kind of cross compile swift sometimes in certain circumstances, but it was a much, much heavier lift to have a full web sync platform. We experimented with publish to web, which has.

come on and off of the back burner a handful of times over the years, and it's something I would still love to do so that way it would, it's easier to share out content at the very least, even if it's not a full Muse local-first client on the web, there's at least a way to take your local content and publish it out for other people. I think there's still value in that. let me put it this way.

I think for us to be able to have gone to a full web local-first client, we would have had to have taken dramatically more, investment money, which would have dramatically changed the entire shape of the app. And audience for the app and purpose for the app, in a way that might even be, antithetical to, to Muse as a whole, right. Since I think the overlap of the audience that Muse has as users and customers, and the folks who use Apple products, I think that's not a coincidence. I think.

there's a lot of similarities and the values, and sort of the pursuits as the bicycle for the mind. Like you've really like started pulling on the thread a lot since like this entire product is sort of a foundation for the mind to be more powerful. Yeah, I think if we had started today instead of started, you know, five years ago, six years ago, I think we would probably make different decisions just because we're in a different world now than we were five years ago.

one thing that's very exciting is the daylight computer, which was, android based tablet, but share so many of the Muse principles of, you know, calm, quiet. Space, safe computing. It's not advertising based. It's not, you know, in your face, pop up notifications and red badges and that sort of thing, but it's very much designed for kind of, purposeful, quiet contemplation. So that device fits the Muse. Principles and values perfectly, but is, of course, android.

And so if we started today, I think we have a very different discussion of, okay, should we start on that device on android? Should we start on ipad? should we? Use some sort of technology that could cross compile. So we can share code. Like, I, I think it would be a very, very different discussion than it was with the options that we had 5 years ago. the downstream implications of choosing 1 platform or another are just on such an enormous scale.

I've heard from a friend who's been briefly working at Humane where like Humane. are all like ex Apple people, like really brilliant ex Apple people. And, well, it turns out the software platform they've built is on top of Android of all things. So, and that has many, many consequences. But, coming back to the, to the web, just because that is, typically been my, my home where I started computering and where I'm still, spending most of my time on.

I'm wondering, how did, even though you didn't get yet to fully build it and ship it. Given that the sync architecture, as I understand it of Muse, it started, as a local only app. So all data was created and lived on one device. And with Muse 2, you've introduced a sync server and that data could then, didn't originate in the server still originates on one device, but now through a server.

Is able to flow from 1 device to another, but the server really has no further role than to facilitate, this transition and, maybe also facilitates a backup in case a device. gets lost or, something else happens to it. so in regards to the, to the web, how did you think about implementing that published web?

Since, one way I could imagine, where you don't really, preserve user privacy as much is that the server facilitates this, that the server kind of like looks at the sync information and compiles a kind of like a snapshot out of that. But I don't think you have that option because everything is encrypted. So is the logical implication of that, that the snapshot that you want to publish is actually created on the client?

Yes. So there's a couple of different things. So the Muse server right now is not encrypted at rest. So it's not end to end encrypted. Although it, the sync protocol is designed for that. We, we kind of put that option in there for the future, but it was too heavy of a lift at the time to fully do. So theoretically, there would be the ability to add web as a sync option and connect into that.

however, it's still really important to keep that end to end encryption as the correct architecture and allow for it. it's something we planned, to build the entire time we had the team. And it's something that's still on my mind that I would love to be able to implement. So that limits what we thought about for the web. One was that, we could share the link and within the link that you share, Is.

The information for the key to decrypt on the web, and then in your account, you would be able to revoke that key whenever you need it to. So then you could share it. Somebody with the link would be able to load up, in the browser. The browser would connect, pull down the encrypted data. It would have the key locally, be able to decrypt in the browser and show everything that you needed.

or later on you could, revoke that key and then, anyone who loaded it up would be able to download encrypted content, but their key would no longer work. So that was idea number one. That strategy generally requires the browser to load. Your entire library or the entire shared piece, which for quick sharing of, Oh, Hey, let me send you this thing real quick. Let me just create a link real quick, send it over to you.

You load it up in your browser thinking we're going to collaborate real quickly on this document I made. and then you have to sit there for seven minutes while it downloads all sorts of. Encrypted things. So your browser can decrypt it and actually decide what's useful or not. Right? there's a whole other big pile of, very difficult, local-first encryption, key sharing problems that are a part of that. And especially when you have lots and lots of data, which many of the.

You know, Muse customers have lots and lots of data that just makes that problem exponentially more difficult it's one thing if you wouldn't have launched Muse yet and you can basically design the system from scratch with like all you can leverage all the degrees of freedom how you can build it but you don't just need to build it all by yourself but now you also need to migrate a live system.

from place A to place B and migrating data, I think is still one of the hardest things and one of the scariest things that's even tricky to do it with the comfort of a team setting, but then doing this all by yourself, that is no small undertaking.

Yeah, and I think it's as much about the, you know, the kind of time in life we are with local-first, trying to do that today is going to be a lot easier than it was trying to do it four or five years ago and doing that five years from now is going to be even easier. And so, having the tooling and having the patterns from other software and having the systems built from other software is really going to help. Future creators kind of stand on their shoulders.

So much of the new sync engine we had to build from scratch. And if we did encryption, we'd have to build that from scratch, which is of course, a huge, a huge lift and then building multiple platforms from scratch. So being able to use, Automerge now, or some of the other libraries now, lets folks start off in a much. more comfortable place, or capable place, than the starting point we had five years ago. And so that, that makes a difference too.

Right. Which I mean, that's the question you've been already paying so much of the innovators tax here. You've been had to innovate and pioneer so much. You had to roll your entire own sync system, both client side server side had to solve other problems. Sometimes just without any reference points where aside from using an off the shelf technology, you couldn't even talk to someone like, Hey, how, Hey, team X, how did you, how did you solve that?

Looking back, maybe you would have been faster not building this in a local-first way. Do you sometimes think about was this the right decision to, to build back then already local-first?

Yeah. It's something I think about a lot because we, We paid a huge cost in terms of developer time to build our sync back end to build a sync on the iPad. we're essentially building the network protocol and an entire database layer, just to get off the ground, right? Just to start building the product features on top of that. So it's a huge cost. There's probably. A different path we could have taken.

if we had not gotten local-first, the way that I think about almost everything is, it would not have solved our problems. It just would have changed our problems. We, so we would just have different problems. I think it would have probably given us some time back, but at the expense of. a different sync issues because sync is hard. Sync is hard for local-first, sync is hard for not local-first. and I think for what Muse is, offline capabilities and a really fast local feeling.

Experience, were paramount, no matter how that data got synchronized, whether it was kind of a traditional sass app, we would still want, a very reliable and thorough cash on the local device. so it would have just changed the problems, but I, I don't know, I, I, I think about this every couple of months, but I always kind of land on, I think we made the right call. This was the right decision. It was a difficult decision.

In the end, it didn't work out for the company, you know, essentially in many ways, which is unfortunate, but I'm, I'm not sure that that was the, crux of it. I don't think that was the reason. That it couldn't work out well, I'm very, very thankful and happy that the Muse team early on made all of those decisions. it brought me on as someone who is just, I came for the values and for the mission.

And for me, it would have, I use like Miro and the past, et cetera, like what really captured my attention was sort of like the, yeah, the thinking different about it. And, I think you've stayed true to this. And even though you had to pay so much of that innovators tax and surely, if you would have started out today, like something like Automerge is a, in a fantastic spot. so you, the giant shoulders are already in a pretty comfortable spot to build on top off.

And yet there's other unsolved problems today, particularly for the web. so I think it's never the perfect time. I think it's a matter of like, is it a fit? For who someone as a builder is, do they feel comfortable, paying a bit of that innovators tax and then also reaping the benefits? and I think ultimately it's a, it's a journey that you're on and you should figure out what is the sort of, the analogy of the problem founder fit is sort of like the journey builder fit.

And, that's something I think a lot about, and I'm paying that, tax a big time right now while trying to build the actual product, the music app, I also roll my entire data layer, which includes the database, which includes the sync system, includes networking, cross platform and for the web. So everything on hard mode. But for me, the most important thing is like enjoying it, enjoying the journey and doing something that, that feels like has a purpose. so I'm, I'm very happy about that.

Yeah, exactly. Exactly. And I think that's really what keeps me back coming to the, yes, we made the right decision. Because building that local-first sync, was the right option at the time for the technology options that were in front of us that were on the table. it really fit our values for the kind of app we wanted, but also the kind of data safety and privacy that we want to be able to offer people.

I mean, like I said, even in that worst case where I was not able to carry Muse forward, the Muse apps would have continued to be. Functional and useful long into the future because it was built on local-first. And so that's the most important thing for me to carry forward as a solo developer is to keep those values, keep that local-first value of this is your data. It's on your device and you can use it for as long as that device still has a battery inside of it.

And, I think the benefits you get from local-first, you do pay the huge tax, but you get such a wonderful reward for the capabilities that local-first software, enables for you. I think it's worth the trade off then. I think it's worth the trade off now and it's. How I want to build software in the future, you know, it's just a wonderful world to live in. I totally agree.

And the good news there is like more and more of the hard problems, have already been solved and are continuously being addressed and solved. So the entry ticket is cheaper and cheaper. And we are getting closer and closer to that dream where all of like the caveats are getting chopped off one by one. Year after year, month after month, this is also one of the big things that has drawn me into the local-first space that has just attracted for me. already had the smartest, and brightest minds.

And this is what really, gets me so excited that there is just such a wealth of problems that are worth solving that the 2nd order effects of all of those being solved, materially change software and technology for humans in a way. That I think almost no other technology solves. So, and yeah, thank you again for being the inspiration that brought me in and, brings in other people. So, maybe ending on a note, what are, what are you most looking forward to for, for the year ahead?

well, I'm an engineer at heart. So a lot of things that get me excited are things that I want to build. And, end to end encryption is exciting. It's super difficult. And it's one of those things that, whenever you build, if you're building encryption yourself, you're doing it wrong, generally speaking. so I think I probably won't be doing end to end encryption anytime soon. But instead, yeah. I still want to solve the problem of privacy.

I've had lots, in terms of people being scared or uncomfortable or. Unable to use a third party sync server. I've had, lawyers reach out, psychologists reach out, doctors reach out and say, Hey, I love Muse. It's super helpful for my work. it is physically impossible for me to put patient data in a thing that lands on a third party server. And in some cases it remains impossible.

Even if there's end to end encryption, just solving that technical problem does not necessarily solve their business and privacy problem for their patients. So instead, something I'm really excited for is, peer to peer sync. And so instead of going through a Muse server at all, you can have your iPad and your Mac synchronize their full data together entirely over local encrypted connections. And so it's not talking to a server. It's not talking to my server. It's not talking to Amazon server.

It's not talking to anybody's server. It is your devices inside of your home on your Wi Fi talking encrypted over your local Wi Fi to stay in sync together. I think that to me really embodies local-first and opens up, even more opportunities.

For workflows and customers, that have privacy considerations, I think that solves the problem even more than kind of a traditional SAS end to end encryption would in many ways, because it fully decouples Muse the app from Muse the sync server, which is, I think the gold standard for local for software is to say, Hey, this is your, your device, your stuff, your software, your data. It syncs between your devices like you don't need anybody else.

You just need to download the software and away you go. and so I, I love that vision for the future for local-first generally, but especially from you. So I'm really hoping I can dig into that this year. I would love to, to be building on that. I'm super, super excited to hear you say that since it always just like drives me crazy to have devices have like my iPhone and one hand and have maybe an iPad on my table. Maybe there's some hiccup in the internet connection right now.

And those two things, they're not even separated by a meter. they're just like completely ignorant of each other existence. And, with an app like Muse solving that and allowing those to Talk to each other who are clearly in proximity to each other. That should be both an inspiration and also a provocation to other apps to do better. And I'm really, really excited about not just for the sake of Muse users who have a better time because of that.

And I think that's one of the coolest things in terms of like a new product version. That all the features that you know, in love before are still working the same way, but now an inherent limitation is just gone. And it's like. Obviously, it should have been like that all along and, ideally inspiring and provoking more apps, more builders into falling on the same path. Yeah, yeah, absolutely.

I think it's the, I'm a big believer in local-first software and, there's really no reason that, like you said, my laptop sitting here should send its data encrypted or otherwise to the Amazon U. E. US East data center, just to have it sent back to my phone, three feet away. I like it. We, we don't need to be doing that. it's kind of silly. And so keeping that data private and keeping it local, I think you end up getting better performance. You get better privacy. You get better.

you get better everything in so many ways. I'm excited for it.

Hey, Adam, thank you so much for sharing so much about your journey, for five years now with Muse, I've learned a lot more about the journey, that has led to Muse and has led through the various chapters of Muse. I've taken away a lot here for, for my personal journey, see a lot of similarities, have a lot of empathy for your journey and hopefully some of the audience who are thinking about, starting a similar journey. Maybe there are on a, on a similar journey already. I've learned a lot.

I'm, I'm sure folks who are listening have learned a lot and yeah, just thank you for sharing all of that. Yeah. Thank you so much for having me. always happy to chat and always, especially to another, uh, local-first developer, I empathize with you. It's always wonderful to chat with someone who a understand software, but B understands, no, I don't work for Apple. I know I'm, I have an app on the App Store, but no, I just understands the world that I live in. So it's been wonderful.

Thanks for having me. Thank you for listening to the localfirst.fm podcast. If you've enjoyed this episode and haven't done so already, please Please subscribe and leave a review. Please also share this episode with your friends and colleagues. Spreading the word about the podcast is a great way to support it and to help me keep it going. A special thanks again to Convex and ElectricSQL for supporting this podcast. See you next time.