Business of apps

Back

I remember the last time we did a paid upgrade. We had a feature done for almost a year before we actually shipped it because we knew it's such a huge feature that will bring in new customers and make it easier from them to understand by the half to pay again. Two and a half years ago, we switched to a subscription based business model, and this is also switching company development culture that you suddenly have to ship updates or features more often.

Hello and welcome to Metamuse Muse is a tool for deep work on iPad and Mac, but this podcast isn't about Muse product, it's about the small team and the big ideas behind. I'm Adam Wiggins here with my colleague Adam Wolf.

Hey everyone.

Joined today by Markus Müller-Simhofer of Mindnode.

Hello. Thanks for having me on Podcast creds from vie Austria.

Yeah, and you're in Vienna. And this is a city that's known for, let's say it's classical music history. Mozart is a certainly a name that springs to mind. Is that something you ever took advantage of?

Oh yeah, when I was still a student, I really like to go to the opera because they had those really cheap standing room tickets back then. I think they still have it, sorry. But nowadays, yeah, I have a hits nows and well the business, so I hardly have a fun time for that. Unfortunately,

A Wolf Styler is about to head off to university, so that is gonna be lots of room in your life for opera after that, huh?

Huh? Yeah, that's right. I just need to make the hour and a half trip downtown to go see it . So that's my other tho in my side.

Well, before we dive in here, just a quick housekeeping announcement. The Muse team together with a friend of ours named Darrun have put together a little website. It's at infinite canvas.tools and I'd like y'all to check it out. The idea here is to kind of give some definition to this category. We talked with Steve of tl, draw a few episodes back about infinite canvases, and I guess we were inspired enough by that we felt like that a standalone site that helped define the category better would be worthwhile to all of us and indeed Marcus. This is an interesting tie in with your history a little bit, which is, I believe you worked on a project of that exact name some years ago.

Yeah, that's right. Back when I was still at university, I did a student project and later on it's also turned into my final thesis, in fact, where I created an app that was called Infinite Kens, and it was highly inspired by a comic book or graphical novel by Scott McCloud. Scott did two interesting books about comics, one more general book describing what comics are, and a second book describing how he would reinvent comics for the new digital age. The book was also called Reinventing Comics, and in one of the later chapters he described the concept of infinite Canvas as a tool or method to bring graphic novels to the digital space. In fact, and as part of my studies, I created an app that allowed you to put graphics on an infinite canvas more or less, and then put uh, navigation area on top of that. So that allowed comic artists to create interactive comics that they could lay out and then present in a that based tool to their readers. And unless other kind of student project, this project actually found some comic artists who created their own comics and their own graphic novels of that. That was kind of cool.

That's really interesting. So it's not just an infinite canvas, which I think of as a very general, just giant space, but there's a specific navigation format or navigation structure that was built into it as well, my understanding that, right?

Yeah. When we considered that at first what we wanted to do, we had concerns that if you just provided an infinite chem to the readers, that they would have problems navigating this canvas. And so we came up with navigation layer on top of that, that allowed to redefine a certain path. You could take around this canvas and you have to compare it to a typical comic, which is laid out on a piece of paper, and then if you bring that to the infinite canvas or to canvas, that's infinite, you can lay out the panels all over the place. You would like to do, For example, there were comics that were just side scrollers or comics that took in all different directions. Unfortunately, many of those projects are no longer around because back then I used Java Outlet for the fewer part, and Travel Outlet is more or less separated and later reported it to Adobe Flash, and that's all unfortunate, not really available.

It's the never ending story of technology, I think

. Oh, that's true. Yeah. But if you like, you can still go to infinite chem.com and see how the app actually look like. But a fear most of.

Are probably no longer available.

And Marcus here the CEO and founder of Mind Node, which I think of as the quintessential or most canonical mind mapping app. It's been app of the day, it's been around the app store for pretty long. While to think of it as a well respected tool for thought from before that term was sort of popular or experienced, the modern resurgence that it has. But before we get to talking about my note, love to hear a little bit more about your history. Maybe what happened between the time of that student project and thinking about comic infinite canvases and the creation of the business you're working on today.

Yeah. Let me go a little bit further down my history. I have a major in computer science and back then the computer science curriculum was very, very general in Vienna. There we had many courses in mathematics, computer, uh, the rhythms, computer graphics and stuff like that. And going into study I was never really sure what they really wanted to do. My vision was, oh I just wanted to do something with computers cause I like games, so computers are the things I wanted to do. And having this exposure to all those different parts of computer science allowed me also to experience human interaction design. And this something I was never really interested in before. But throughout my studies I kind of always had those intersections with that. And I also had, what's kind of interesting, I had a course on Next Step, which kind showed me a new way to use a computer, which was kind different from doing side. I only knew so if the exposure of having experienced the next step computer and then also my, the growing interest in human interaction, I started considering getting a Mac and this was the time when Steve Chops announced the I'm actually four, which was this kind of cool looking computer that looked like Stand, which I have still somewhere in my office.

Is that the cube?

No, the cube was before that. That was the chief fortune. Okay. It was the second generation iMac. That's yeah. Where you had this kind of round stand and then you had to flat panel with hinges coming out of that. Oh yeah. Oh

That's right. Yeah. That was a beautiful

Machine. Oh yeah. It's kind of looks very similar or at least the hinges look very similar to the studio display. If you get the one with the moving very can move the display up and down. So yeah, back then I really had nobody around me that use the max. So it was kind of jumping into cold waters. But if you think about decisions you made in your lifetime, that was definitely one of the better decisions I made. And it was just one of those feelings that I follow that wow, that's probably, yeah, that's just a feeling there. But if I do that, it feels great. And this is when I kind of left the Apple platforms. This was also the time where the iLife apps were really popular. If you think of iTunes, imo, id, VT and I a for example, there were great focused apps that did one job really well and for they very designed for this one use case. And this was kind of influential in me. And then there was the second part, it was very influential and that was the upcoming of Indi Mac developers. Mm-hmm , if you think back, there was delicious library or net news wire. So after was not really sure what I wanted to continue to do, but having those people show what is possible, creating your own small max software studio, that's kind of something that really inspired me to try to do the same thing.

So the iMac G4 was introduced what year, do you remember?

20 years ago.

Wow. That long. Yeah. And then how long between sort of that device, seeing these in apps falling in love with the Apple platform and the founding of what would be the company that would make mine node?

I wrote a first on of mine to note into thousand and seven. So it's now 15 years since I started the project.

Wow. And yeah, give us the elevator pitch. What is my note? I've already perhaps tipped it off a little bit, talking about mind mapping.

The also thing about mind notice that I didn't create the app, the course, I thought, oh cool, mind mapping app would be something, a good idea. But I was kind of stuck in the Infinite Canvas project. We talked earlier, of course I had this big picture, a few idea that, okay, I have this app, it's kind of popular in this niche area, but let's try to bring this to more broader audience. Just imagine having an internet canvas where you can show your presentation. That's something that was unique at the time and I thought, oh, that could have potential. But as it's always with great ideas, you have too many of those and you don't have a clear vision on what you really want to do in the end. So after coding for a while, designing for a while I was kind of bumped out.

And looked into techniques that would allow me to bring back this focus, bring back or allow me to really discover what I really wanted to do. Did a little of research and discovered mind mapping and, well, I'm a computer engineer, I like coding. So the first thing you do when you come across and new concept, you want to it yourself. So as really great apps back then, mostly ports from vendors, I decided, oh let's look what app was doing with the I caps, what all those other India developers do. Just try to do a tool that does one job really good. And I started um, prototyping phase. I decided, okay, let's try it for one month. See it how it turns out. And then I can still decide if I want to go back to Infinite Canvas or if I want to resume my note.

It's really interesting. I feel like that's where almost all good products have that same kind of a route where they're solving a very specific problem. It's not just building neat software, but you were building neat software to actually help you think better, to help you do something better. It had a very specific purpose for you. Sounds like that gave a lot of vision and direction for you early on.

Yeah, all this feel that the best features in mine and other apps are the features that the developer itself uses. So if you develop a feature trust because a customer wants to use that, you will never create a great feature. You will create a decent feature. But if you really are the user and the customer of the app, then you really are behind the feature. You understand how the feature works, you just don't have some description of how the feature should look or behave. You actually lift the feature, you know, all the inset outs. You really know in what edge cases you can run. And those are often the features that turn out really great and awesome.

And originally this would've been for Mac because the iPad didn't exist. Am I right about that?

Yeah, I think that might have been announced by the time I started creating my node. Wow. But I think that was way before the sck. So I started initially on the Mac. This is also where I had the most experience and even after the SK and was announced, it was kind of ah, I did some experiments but it was kind of hard to create something with an expanding or infinite canvas to the iPhone before state. But I wasn't really designed that way. So I started with doing the Mac first and then later tried to bring that to the iPhone platform and then also to the iPad

And first saw it on iPad. And I think this was circa would've been more like 2017 or something when we were doing tablet research back at In and Switch. But one of the things I was struck by was how just beautiful and good the iPad hardware was, particularly when paired with the pencil, which was relatively new at the time. And I went looking for really good quality iPad apps and I was just shocked how few of them there were. So many were just iPhone ports. In many cases they were scaled up or you know, just like in a letter boxed thing. And so from my perspective, it felt like an app that just could have been born on the iPad. It was made for iPad. But maybe that also to me is the connection in my mind between a tablet is such a great device for open ended ideation, which indeed is what mind mapping is. You can sit back on your sofa, you can take it to the coffee shop, something like that. So it's interesting to hear that that was a very late comer to this product.

So when we decided to do the iPad app, we was just a one to one port of the iPhone app. We actually, when we released our iPad app, I still had no access to real iPad back in the days because they were only released in the US and not in Austria even had a, one of our customers send me one of the first iPads. So I could actually try and use the app on the iPad. But you always have to keep in mind an iPad app also has to be a good iPhone app. Of course you can always resize the app itself to be as small as an iPhone, an iPhone device. So that's all I think the real big challenge of doing a great app for all free Apple platforms or major Apple platforms that you always have to keep in mind. The app could be launched or could be a size like an iPhone, an iPad and a Mac. And I think iPad and Mac are starting to converge a little bit, especially now with iPad was 16. But you still have to keep those tiny iPhone screen in mind.

I'm really curious to hear how difficult it was to make that jump to iPhone and then eventually to iPad. Cause as I recall, the Mac APIs kind of in the late two thousands versus the iOS SDK were pretty dramatically different. And then they've kind of congealed lately and merged together in a lot of ways. But at the time pretty separate. Was that just a huge effort? And what were some of the risks or thoughts in your mind as you expanded into new devices?

Creating the first item version had several challenges. Looking back, definitely the very restrictive hardware and the really a huge problem of fitting everything into memory and the app getting killed if you'd used so much memory was always kind of an issue. Especially if you look at the technical side. We tried to use internal layers back in the time. Mm-hmm , those had really issues with fitting a memory. And if you imagine how uh, very graphic intensive apps like my Note has to do it, we have to use very large layers to draw all of our branches. So that was a really challenge. Another challenge was actually text because back then the iPhone only had simple texts. There were no attributed strings or similar. So when we poured my the iPhone, we actually had to define a new and custom file format that didn't use our extent use of attributed strings and had to tone down the file format a little bit.

And the search problem for really a problem was getting the data from the Mac to the iPhone. Back then Apple still used iTunes to sync everything over and there wasn't really a good way uh, to transfer files. So we had our own app socket kind of ad hoc connection between the iPhone and the iPad, which was kind of liked in really support sync. So you had to to transfer the document over and in this process the file was converted to minor version to file for more or less. And then customers had to move it back to the iPhone or the iPad got a lot easier when EdCloud. But that was, I can't remember when this was an answer thing in the second year or the third year of the iPad or,

Yeah. That's really interesting that you've weathered all of these changes, both introduction, new hardware, new APIs. Yeah, even it almost like, I can't even remember it in some ways I've maybe I've purged the memories from my mind, but yeah, this tethering your phone to your computer was a thing you needed to do for all kinds of stuff. That was just part of daily life. And that wasn't even that long ago. It was like 10 years ago. But now the over the air stuff and the sync fire, the internet and so on is just what we expect. And we've grown used to,

One of my favorite things to forget is the hardware limitations of those very early phones and iPads. It's just amazing that anything was ever written for them. In some ways , I think first iPad had enough memory for like basically four uncompressed screenshots before you got killed or just something ridiculous in terms of the lack of memory that your application could use before it got the hammer.

I think in the initial I phone version of mine, you could only create 90 nodes or so before the app was killed by the system course. It took too much memory pressure.

What's that quote? 32 kilobytes is enough of memory for anyone. There's some famous quote that I'm forgetting. ,

I feel like it was 640 k is enough for anyone attributed to Bill Gates, but that may also be a miss. There you go. Attribution. But yeah, for sure it's

.

You go back and look at what kinds of limitations, You know, you look at the hardware for eighties arcade games for example, and it's just, it's really marveling how little resources they were able to do pretty comprehensive pieces of software in.

But I have to say it wasn't all bad for us because in the end we really had to do a very performant iPhone version, which was very optimized for the memory pressures and the performance of the chips back then. And we later poured the core of this back to the Mac and this really brought us a lot of improvements also for the Mac version. So it's not all bad if you look back.

So fast forwarding to today, and my node seems to be this pretty successful app on the app store, and indeed you are not only one of these Indie Mac developers that you are inspired by, but indeed you have a whole indie company that is behind it. So tell us a little about that. How many people are on your team and how do y'all work?

I currently have eight employees and four freelancers on the team. And I grew the company really, really slowly in the last couple of years. I probably added on a new employee a year or so. So we only saw a very slow growth. And that's kind of also what helped me a lot to learn on the go, how to actually run a company course. Coming from an engineering background, I never really learned how to manage people, grow a company.

Do all the business stuff. So having a company that slowly grow every year, always a little bit, that really helped me to better serve the role of the developer and the role of actually running the business.

What's your split these days? Do you have a much coding on the core app at all? Have you become a peer manager as a result of your team?

I think none of my code actually goes into the shipping version nowadays, and this was really, really, really hard to letting go of that. So if you talk about my earliest team members, they will tell you that I always looked over their shoulders and re reviewed every line of code they committed on. And so, uh, it was a really hard time letting go of the code. But nowadays, um, my focus is, has shifted. So what I do from time to time is write some prototypes, prototype one feature, or I even have several feature that are called Marcus features that are in the app that nobody else uses, but only I . But otherwise I try to keep up with all the technologies. So I try to learn Swift GI and I also, you know, have Vapor, backend Vapor as a service that Swift framework which we use for business intelligence software and I try to use my coding for those non-critical areas nowadays.

I think that's a good approach. It reminds me of the old Ren and Repose blog. I'll have to dig up a link or something, but he is speaking about kind of the transition to engineering management and basically frames it as once you move into this kind of management or leadership, you should not code and also you have to code. And the way he resolves that is actually kind of what you described there, which is if you don't code, you lose touch with the technology, you can't recommend the respective engineers, you can't really make good decisions and understand what's happening cuz you're just out of touch. But on the other hand, owning stuff that goes into production when you have a bigger duty, a bigger responsibility to the people and the company is actually sort of irresponsible from the perspective of you're taking on too many conflicting responsibilities.

And so in that sense, yeah, prototyping or a little bit of pair programming or helping write some tests or that sort of thing is a good way to stay in touch but also not be in a position where you are the person who is really bearing the responsibility for something that customers are depending on. So our topic today is the business of apps and of course app is short for application and really refers to any kind of piece of user facing software. Certainly there are web apps and that has their own set of business dynamics, b2b, SAS and so forth. But today we're really talking about selling apps through an app store in particularly while there are many app stores in the world now, the granddaddy of all of 'em and still the biggest and most important and the best place to build a business is the Apple App Store in Marcus Hira.

Wonderful person to speak about that having over a decade of experience of selling through that Adam Wolf, I know your time and your various entrepreneurial ventures as well as other apps you've worked on like Fantastical, you've had plenty of contact with that. I'm a relative newcomer here having gotten into it just for the Muse venture. So I'll probably have less to say, but I'm looking forward to listening to the experience voices we brought to the table here. So maybe as a starting place, we could talk about just what is the app store, what do you get from a business perspective when you put things there and what are your options about how to make money?

When I started selling my note, I actually started selling it through our website. So the app store only came later, so I remember that before the app store we really had to think about how do you protect my app from piracy? How do I create a license codes, how do I invoice people? Initially I tried to do it myself, but very quickly switched to an app service that was called cgi. And uh, also learned that some license codes that are too long are also not really good. So I had a lot of learning effects back then. So the app store definitely takes away all those burden of having to think about how you protect your app and how you unlock certain features of the app. If you, with a very basic app store business model, So if you go with a paid upfront app, you basically don't have to do anything to sell your app on the Apple takes care of everything.

I think one of the other really important things is just the huge customer base that Apple brings to the table as well. That getting shelf space in Walmart is very difficult, but they have lots of traffic. But getting shelf space on the app store is very easy and they have lots of traffic.

And so just having that immediate visibility can be a really important first step as well. I think that's what's particularly impressive about, especially the early apps and early Mac apps, was the Mac app store didn't show up until significantly later compared to the iOS app store, and so you had to build that customer base on your own from your own website. What were some of the things that you did to bring in those initial customers?

What I initially did was post app on certain forums, for example, and developer forums where I had my initial feature version and where ask those developers there to provide me feedback on that. And also very helpful back then was a set on apple.com/downloads where they promoted first party software, and I had the luck that Apple already promoted our first free version, which we later turned into a premium version half a year later or so. And this premium version was again featured by Apple on this website. So this definitely helped a lot. What we also did was send out press releases, contact press directly, but it's very different, especially in the beginning of the app store where they weren't a lot of apps available on the app store. So basically every new app received the full attention of the press and the customer.

Yeah, it's certainly very different story today that where the huge, huge number of apps means that you really do have to do something to stand out. And certainly Apple does do a certain degree of curating their winners, featuring apps and editors choice and NAPA the day and things like that means it's been lucky enough to be the recipient of some of those. I get the feeling that my notice is a professional favorite. So I'm guessing that helps a lot with getting you surfaced. And then once you're in the productivity charts, I just took a peek and see you're pretty high up on the productivity charts and then people go and just kind of scroll through that and probably it's more likely to pop up when you search for mind mapping than anything else. So all of those combination of things means that it's a distribution channel that is to say that shelf at Walmart, you mentioned their wolf, the virtual shelf, in this case, the app store can be very, very good if you can do a good job of playing the game.

Yeah, I think nowadays just releasing the app on the app stores not enough. Mm-hmm. , but if you try to find a connection with Apple, try to find somebody inside Apple who can pitch. This is exceptionally helpful. So I always recommend contact the evangelists, contact your local app store managers, let them know what you're doing. And I think in our case, it really helped a lot that we always try to feature that. Apple's very interested at the moment. For example, when we first started, Quick Look was very new and we had a quick look extension right away and we continued to trend one of the first company who supported iCloud and we tried to always be there when Apple announcing new technology, for example. We try to have a really good support for stage manager this year, iPad us, and this really helps if you try to communicate with Apple, you show them what you're doing and if you're doing something that makes Apple and Platform stand out, then this is a good reason for Apple to feature you and list you in all those categories they have.

Yeah, that's a great point. We've, well, I would say we've experienced that mostly in the sense that we speak to our contact at Apple and they basically say, Which of these new APIs are you supporting? And more often than not, the vast majority of them are things that just don't really make sense for the type of app we have and or don't match up super well with the roadmap of things we think our customers want. But on a few occasions we have tried to hook in with those things in a timely fashion and then that potentially puts you in a position to be part of their story, part of their launch story. And that's the cycle I think for a platform. A platform is as good as it's developers. If a platform is as exciting new features built into it, but there's no apps that exercise them, then people aren't gonna care.

This actually is a trick. Now, I'm almost diverting back into our recent episode on platforms here, but I feel Nintendo's done very good job with this where they always have their first party apps like Mario and Zelda and so on, and these will be the ones that often showcase the brand new motion control or whatever the new gadget or gim or API is that they're mm-hmm putting in their platform. They could count on these first party apps to use those really well and show them really well. But I think Apple obviously does do a bit of that, but I think they've also been very good at engaging their developers on those new features. And it's precisely that that's kind of the bargain, which is if you can show up with a good implementation of something related to the new platform feature, then not the promise, but the possibility there is that then you'll make it into their marketing materials about that. And obviously they're a very, very powerful marketing machine.

That's true. If we look at our funnel, we always see that the app store is really the strongest part of it. And even app store search is a huge part of bringing customers to our app store page. So whatever we try outside the app store, nothing comes close to what the app store itself can offer to a developer.

Now when it comes to the payment side, you talked about the challenge of setting up your own payment infrastructure and license keys and so on, and there's certainly a fair bit of complexity to set that up and implement it well using store kit in your app. But as you said, so much is handled currency conversions and you don't need to really deal much with even certain kinds of customer service things. They're sort of a go between for basically everything payment related. But that also does mean you need to use one of their payment options for one of their models, let's say payment models. And I think you've been around that, you've seen the full evolution. You mentioned starting with the free app. Tell me how that went. You know, in those early days you could pay, but it was kind of a one time upfront fee. I believe nowadays you're on a subscription. What are all the different options there and what's been your journey going through all those?

So we basically started the free app for our website. But when we launched on the app store, we had actually three different versions on the different app stores on the Mac app store launch. We had a free version and the paid version because there weren't really a possibility to have a trials. So customers wanted to use the, or try the version before the purchase and this was a real problem or is there still a real problem if you are want to follow the paid upfront purchase model? And there is a second really big advantage in my opinion, if you choose the paid upfront version that you can't ask for. Uh, paid upgrades. So if you want to ship a paid upgrades after two or three years, you don't have a lot of options. You can still probably choose an option where you have an inner purchase for the existing app or you can switch to a new enter in the app store, a new sq. But uh, if you really do the switch, you lose a lot of listings in app store categories and worst thing. And we, we tried it so we have experience with that. Customers no longer find the old app so they think, Oh you removed the old app and I can no longer install it. You just have this new app and I have to pay again. And this kind of triggers a lot of not so nice to read customer feedbacks on the apps for itself and also in our support inbox .

Yeah, I feel like payment is one of the things that's most likely to be a really emotional topic. Yeah, you're reminding me of, I feel like this was a really common pattern and I see it a lot less these days, but you would have sort of a light and a main version or a main and a pro version. I think I did this once for just a little side project game thing where the light version had the first end levels and they had pretty specific, you know, rules about you couldn't upsell too hard, but we would just essentially say, you know, this is the first 10 levels, if you want more you can get the other one. And then that was free and then there was a paid one, I can't remember, it was like five bucks or something and that was all the levels and that was the solution for that.

And then similarly, the paid upgrades as you mentioned, I think things still does this and does pretty well with it, which is they're on things three or whatever it is. And at some point that was announced and was a paid upgrade and things two disappeared from the app store and you have to go through that process. But exactly as you said, there's all kinds of ways in which that's disruptive for your customers and confusing and wait, why do I have to pay again and so on. Although that actually is just channeling I think a very traditional model for software Microsoft Office or Photoshop back in the day or that sort of thing. It was just normal. They would come out with major new revisions every year or two and then at some point you would need to be on the latest version probably just to open files from your colleagues and or cuz you want new features. And so then you pay again. And I always saw those as being kind of a basically a software subscription as long as you were using the app, but at least there you can decide on your own timeline a little bit when to buy the new version. So there's pros and cons relative to subscriptions, but the reality is ongoing software development has to be paid for one way or another and paid upgrades are certainly a way to do it but just not well supported in the app store.

It might sound a little bit strange, but we still get complaints from customers that are seven year old version, which we continued seven years ago, no longer works on M one max. So yeah,

It's amazing. I almost feel like the very early app store just encouraged to race to the bottom on pricing where apps would go cheaper and cheaper or free just to get those users and like you said, it's the one time purchase and there was no upgrade path. And so then users got used to, Oh I'm gonna pay 2 99 for an app I can use for the next 10 years. Perfect. When that's just not sustainable. And so then migrating uh, 2 99 purchase from 10 years ago into a subscription is such a difficult transition for the customer and a difficult transition for the developer to bring those customers in onto the bus and onto the wagon. How did you manage that communication as you changed your business models and as you increase, there's obviously gonna be unhappy people, but did you take any extra efforts or extra communication to bring customers with you on that journey or what was that like to go from no options to suddenly now we have in-app purchase and trials and all sorts of things.

Yeah, we definitely had our share of trying to find a good working business model on the app store coming from a paid version, then doing another paid version as a paid upgrade kind of where we just lower price a little bit in launch week or two, then we try to move to um, free app with um, free a purchase to unlock a trial version and then in a purchase to unlock the pro features. And now we only two and a half years ago we switched to a subscription based business models and I think a lot of customers don't want to hear that, but every change we made, we always had the same amount of complaints and always people were angry either way we tried it, they were always angry and I always had a feeling if I do the subscription switch now I can get it behind me and I can no longer have to think about this part of running the business again, having to explain why they have to pay.

Now again, it's obviously that with a subscription I ask them every month or every year that they have to pay again. But that's part of the business model and that's part of a people understand. But I think a lot of customers or potential customers don't realize what a paid upgrade is. And this concept never really came from the Mac where it was a very prominent business model to the app store as Apple also never supported it and there were always this workarounds. So for me one of the more important learnings was every switch is painful and it's always hard to communicate it to customers. But in the end, after having done subscriptions, which I kind of feel relieved that this part of running the business behind me and I fully understand that uh, Sun Switch or subscription is something that can annoy a lot of customers. I think if an app I daily use suddenly asks me to have a 10 subscription for, so I'm also feeling angry to be honest as a customer. So we really have to be careful on how you communicate this and how you transition customers over from the, I call it legacy old version to the news or subscription model.

You know, I think one thing that really stands out to me is just the risk of the upgrade model versus the risk of the subscription model for the business. Cuz if you spend a year or year and a half building an update and you have an upgrade model, then 90% of your revenue is gonna come from that update and you need a giant slice, a giant pile of money on upgrade day. And if that doesn't come, then the past year and a half was a really painful experience. But then with subscriptions it suddenly smooths all that out and you have have a much more predictable revenue stream, which then makes new features and customer support, you know, actually a lot easier because it's just a more consistent and developer environment compared. That was with upgrade,

Paid upgrade, we had a feature done that the customers really wanted to have and we had it done for almost a year before we actually shipped it because we knew, wow, we have to delay this feature for the next paid upgrade because it's such a huge feature that will bring in new customers and make it easier from them to understand by the have to pay again. But sitting on a feature for such a long time is also kind of frustrating. And this is also mm-hmm kind of a switching company development culture that you suddenly have to switch over to shipping updates or features more often. And it also allows you to have incremental feature releases where you say, Oh, let's try, if this feature is something that I.

Basis interested in, don't fully implement it, try to work with mvp, that's good enough and then later build it out based on customer feedback.

Yeah, I think one thing that gets lost for the customer is they'll see the, oh, you're not offering upgrades anymore and now it's a subscription. Oh, I'm never gonna get upgraded software and I just have to pay you all the time. That stinks when the reality is they're getting those upgrades so much sooner than they would have and so much more consistently than they would have. I think the story of subscriptions is sometimes lost in the trees compared to what it actually provides for the customer.

Yeah. You asked me before about how we communicate subscriptions or the subscription switch to our customers and I think that's a really hard thing to communicate because you know in advance that customers won't be happy about the switch because you are also a customer father apps and you don't like that as mentioned before. But you really have to think about how can I make this easier for the customer? How can I communicate to him that feature development or simply adopting the app for a new Apple release just simply takes time. And what we try to do, and I was kind of happy with our end result, is we try to provide existing customers with um, basically cheaper version to upgrade to the subscriptions. We had different trial lengths for the introductory offer of six months or 12 months. Then we shipped a very large free last free update to our existing customer base who used to paid the front version together with the subscription. And we also tried to communicate it very early. So we told them two months before, Hey, we are going to switch to subscription. You will get the same features that we are planning to ship to our new subscription customers at the same time for this last release release. So they were had some positive connection with our switch to subscription because they also got a new feature at the same time. And I would say it kind of worked, but we still of course got our share of not so positive feedback.

Yeah. And I think that's inevitable, but that empathy for the customer I think really goes a long way when you, you know, understand their people just like us and have those same visceral reactions to change, but being able to empathize with them and understand and explain here's our motivation we wanna do right by you. Here's me trying to do right by you and here's the new world we're moving into. We would love for you to join us. It's a very difficult conversation to have with customers I think, but when done right and when done with the right motivation, I think it really does make a difference for the number of customers that will continue on that journey with you. Now I assume, Marcus,

That you're doing a freemium model where you can basically try the app initially with some kind of limits and then choose to sign it for subscription. Is that right?

Yeah, that's right. What we actually did is we moved our freemium version we had before where we only allowed to few documents to actually version where you could also make tiny or minor changes to documents themselves. So when you download the free version of minor, you can create new documents, can add basic content, and it also covers really all your basic brainstorming needs. But we unlock um, more premium features. For example, our new added outline behind a subscription now that we have two plans, a monthly and a year subscription.

And was the freemium something you experimented with? Cause there is the approach and actually someone we worked with in the past who has some subscription apps told me about a bunch of pricing experiments he'd done in discovered that for one of his better selling apps. Just putting the paywall literally the moment you run the app was actually by far the best thing because the moment someone downloads it, they have their intention for what specific problem the app is gonna solve for them. They're gonna hit the button. One thing that's also good I guess about the app store is that subscriptions are something you can cancel easily through the settings page and you have confidence in that. And so you just say, Yeah, okay, I want this, I wanna try it. So what was your thinking on giving those Yeah, the free capabilities sounds like somewhat extensive free capabilities versus more immediate paywall.

It's kind of interesting that you mentioned this because I've read about the same thing recently. We are currently in the process of reviewing our entire onboarding workflow and when we first envisioned it for our subscription, I was had a feeling I wanted to.

Get the customer from our tutorial directly into the app and experience how powerful mind mapping is. How they can start putting all their ideas and collecting all their ideas to have some positive impact on them before I actually force them to see the purchasing screen. We are still reviewing if we might want to change that in the future because the app store has the problem. When you only see that the app is basically free, you can download it for free, but there is no good communication. But the real business model behind an app is before the actually launched the app, there is this small section on the app store page where you can see label inner purchases and also subscriptions, but hardly any users scroll down. I think most users just look at the screenshots, the first text before the fold and then they click on download.

Yeah, and I think that's a real flaw on the app store page. Obviously they're inheriting the legacy of history, which was in our purchases were originally a tiny add-on and then subscriptions came from there. But that becomes the main way that least serious professional or serious productivity software is sold. Then it needs to be more front and center and yeah, that leads to angry reviews and things because people feel surprised or tricked or something like that. So yeah, it's really tricky.

And then imagine back in the day it was not called get how it's called now, but it was called free and you clicked on the button that said free. Mm-hmm . And then you kind of realize as soon as you launched app, the app wasn't free. There is an inner purchase behind that. So I'm really glad Apple changed that a few years ago. So as you can see, Apple is thankfully to some of the feedback we developers provide. And when it comes to subscription, I'm definitely seeing that this is a model that Apple very highly recommends and makes constant changes and improvements to how subscriptions work and how B as a developer can profit from them, but also make it easier for our customers to work with subscription. For example, last year they added a way to allow you as a developer, show a cancellation dialogue from inside the app to cancel the subscription. So that are some great improvements there as well.

Speaking of feedback from developers, I remember very early in the app store life customers could add a review, but then there was no way for the developer to reach back out to that person to reply to that person. So yes, Apple brings you a lot of, you know, customer visibility, but then they don't necessarily want you talking to those customers . So what were some of the challenges there in terms of just, you know, dealing with those reviews and I'm sure I , I brought some very sad memories back to you just now.

Oh yeah, I almost forgot about that. That was mm-hmm kind of frustrating if you have a customer writing a review and I think back a lot of customers also don't write reviews because they want to review there app, but several customers also wrote reviews to get support. So they thought, oh that's a great way to reach a developer. And they were never aware of that. Developers had no way to actually contact them again. So that was definitely one of the more frustrating things about the app during, in the beginning. But thankfully Apple changed that. And we also tried to respond to, if not all, at least most of the reviews. But I have to be honest, I'm not really sure how many customers get the feedback or I understand that we responded. So we get unfortunately not a lot of feedback from those.

One thing I'll note, and again I'm coming from the world of web software and seeing both the pros and cons but also just the differences of selling through the app store. And one striking thing is that it's clear that Apple or other app store creators are in the same boat, I would imagine are really inserting themselves between you and your customer. And for example, a non amenity that I can download an app and use it and the developer really doesn't know that much about me. And even something like Sign in with Apple offers you these abilities to obscure your email address or not share it at all. And one of the things we chose to do on Muse and sometimes actually does give us bad reviews, but we require you sign in with an email when you start using the app, which is totally standard in the web world.

People don't bat an eye, you wanna try a new service? Yeah, sure. You sign up with an email. That's just a normal thing. And we like that because it allows us to have a direct connection with our customers is important for support. It's important if we need to proactively notify them about a specific thing that's affecting them. And in general, we just think that owning the customer relationship is good for our business, but that is going against the grain a bit in the app world where the expectation is sort of a non-IT because of the platform provider being this third party go between the.

I can totally understand that. And we recently considered doing something similar just to have a way to contact a customer that their trial is running out. So we currently don't really have a way to contact a customer to let them know, Oh, you are currently on our free trial. The free trial expires in two days. We would love to have you as a customers, but if you're not really happy, here's the link to cancel subscription with Apple. This is something that we sadly can't do at the moment, but I think it would really help us to have a better standing with our customers.

In some ways it makes me think that you have two customers, you have the customers that use my node, and then you have Apple and you have to keep both of them happy to some degree. , have there ever been times where you've needed to kind of pick one over the other? They've competed a little bit in terms of attention or features or direction that you needed to take my node or has it been a fairly benevolent relationship with both of those?

I think they did a really good job trying to balance this in the past. There were not a lot of cases in the past where, for example, we had to remove a certain feature because the platform vendor wasn't able to continue to support it. Talking about sandboxing, another paint topic of the Mac app store back in the day. Mm-hmm. . But overall, I think we tried to find a good balance and if, as you mentioned Apple, it's always better to not get into the way of Apple when it comes to certain features. For example, if you know that this might be a feature that might not pass Apple Review, we personally try to stay away from this feature just to be on the safe side because having a pain to go through rejection of the rejection is probably not worth it.

Mm-hmm. ,

Which is kind of unfortunate to be honest, because it means that some features will never actually be considered to be explored by us and features that our customers will never experience.

I've seen that. Yeah. Sort of counterpoint I guess to the app review process, which you know, is sort of a controversial topic in some ways. There's a lot of ways it, it does protect the quality of the app store and create trust with the end customers, which is good for all the legitimate businesses that are running there. But on the other hand, it does create a lot of frustration and slow down, which happily has gotten better over the years. But this point of experimentation is a really good one that, yeah, I hadn't thought about like features on an individual app, but because I know folks have talked about whole apps that they had ideas for that they thought actually could be really valuable. But as I thought through, they're like, no, there's 20 ways that's gonna run into this app review gauntlet. I just don't wanna deal with that. I'm just not even gonna create it.

And even if it passes app review, you never know if it'll pass the next app review or mm-hmm. Devon coming after and we had similar issues with our business model where Apple was certain at some point of the opinion, Oh you can't use a free inner purchase to unlock a trial that's not supported by us. And then we had to go through the app review board and show them other examples of apps doing just that. And it's just always lost time and lost resources you could have spent other. Mm-hmm

, another major difference I noted coming from the wild west of the web is that experimenting with pricing is way harder to do within the app store world. Even the process of getting a price, whether it's in an app purchase or a subscription reviewed is a whole journey. And then if you want to test out a couple of different price points with an AB or an ABC test, if you wanna test out something like the freemium model, something where you say, Okay, you know, our current setup, you get a hundred cards in the free version and then you can buy the starter plan. What if we make it so that you can have a lower limit on the free version, but the entry price is a little lower? Or what if we make the free version a little more generous but make the entry price a little bit higher? What fits people better? And I think my past experience as a business owner is you've got to experiment. If you can't try different things, you're never gonna land on the right answer. And I think pricing is really important thing to get right, but trying to experiment with that, it's possible, but it really is an act of contortion.

Um, that's right. But I think when it comes to subscription, Apple tried to make this a little bit easier. For example, I think only with subscription you can set a price based on the region you are. Mm-hmm. , I think that's not possible within a purchases. And there is also some new features that Apple added to store kit and the App store itself, for example, you can now finally provide offer codes for your customers to unlock a certain mm-hmm. promotional offer, which weren't available until, I think they only added it three years ago. So this is always, when I think of business model, I look at what is Apple currently doing? And they're doing a lot of things when it comes to subscription, making things easier for developers to experiment with pricing in this area. And also adding new features that haven't added new features to other parts of the store kit framework. I think in like forever and all the new features always land on the subscription side, which has also have to be honest, some disadvantages because actually implementing subscription in an app really takes a lot of time. So we at least spent four months just trying to find a good implementation of subscription, finding a good way to sync our subscription, our platforms, which is only possible since two years now. But that was before we made the switch. So store kit is not the easiest framework to work with to be honest.

Mm-hmm. , which is surprising because it's so, you know, indispensable to both Apple and every developer . You'd think that there would be a nicer environment to work in there.

That's true. But subscriptions are also not easy. They add a lot of things to consider. A lot of edge cases, a lot of things when it comes to churning or does the customer need some approval from somebody else, from a parent, for example, to get their subscription running and stuff like that. So we have a lot of states in our app in which a subscriber can be. And covering all of those correctly definitely takes some time and it's not easy.

Yeah. I feel like even understanding what the options are isn't easy, let alone then implementing those options in the app .

Yeah. And also the UI and Abstract Connect is really complicated when it comes to managing subscription. Have you ever tried to increase the subscription price and to how many screens you have to go through and how many little dials you can turn? That's really not the easiest ui.

Yeah, that's right. And you also end up with a lot of canonical information only in this web interface, which Apple is great at building many things, but web interfaces are not one of them. You know, it's slow, there's lots of unreliability and in general it's just kind of confusing to navigate things move around all the time and yeah, for those screens, it's just very often, Oh, I thought it was on features subscription manage, but it's actually under app store payments thing and you're looking for the exact right check box and going through these flows. I did a lot of the setup for the last time we did a major revision to our pricing last year. I did a lot of the just kind of grunt work of essentially typing it all in. And in addition to being really easy to do wrong, it's incredibly high stakes because once you type it in, you cannot change it. Mm-hmm. . And in fact, even the identifiers, the unique identifiers which have to be unique to the entire app store, not just your own app for each subscription code, once you type it in, you cannot change it and you cannot delete it and you can never use it again. So if you don't type it in right the first time, , you know, so yeah, very harrowing. I think I messed one up one time and we had to basically change our naming scheme for the subscription codes.

I'm embarrassed to say on a very old app of mine, I made a misspelling in one of those identifiers. And so it just haunts me because it sits there mocking me in the app store connect of one letter wrong.

And then on the implementation side with store kit, it's also tricky because you got this concept of, I'm still struggling to route my head around the exact technical architecture. I'm sure you both understand it better than me, but there's something where there's an on device validation of this receipt, that's the kind of, Yeah, anti piracy stuff. You're talking about Marcus, and then there's the Apple servers for managing Yeah. Payments of subscriptions and things. And then you can optionally, but it's recommended have your own backend that does some of this. And so there's a three way data exchange between Apple servers, your servers, and the app on device app. And then as you mentioned, the user might have multiple devices and obviously the subscription can should be shared across them so it gets confusing quick.

Oh, that's true. Yeah. As I mentioned before, uh, store is definitely not the easiest framework and web and Apple is also a topic. So you have this backend call that you can do to the app store service where you can validate a receipt. And in the past we had several times where this kind of failed and we had issues with that. So not really fun if your payment flow is not really working the way it should be, but I can always have to come back to this one comment. It's getting actually better. So Apple is improving things and also when it comes to services and running services. So I always try to be more on the positive side and try to forget how it happened previously and what mm-hmm. was in the past

Is really striking to me how much of app development has nothing to do with the app's development sometimes where the features are certainly an important part of building an app, but you know, there's all the payment flow, which we just talked about, but then even meant.

In that a lot of your traffic comes from, a lot of your customers come from app store search. Have you done a lot with the app store product page and experimenting with screenshots or with descriptions or with the tags or anything like that? Or is it just a one and done? We put it up there and Apple take the wheel.

We did a lot of optimizing the descriptions. Also the title of the app itself and also the tax because in app store search, those are the free more important parts on how an app is listed in a search ranking. Um, there we did a lot of changes and I hopefully we landed on something that's working quite well at the moment. But what we recently tried to use search ads on the app store and there we, when looking really at everything, we kind of realized that our sales page inside the app is probably not the best performing sales page. So we are currently focusing on improving that and that's also a lot of work to be honest. Just having to think about, mm-hmm , what dials you have to do there and how you present a sales page.

By sales page, you probably are referring to what on our team we usually call paywall. So this is some kind of dialogue that pops up and basically says, you know, hey, if you buy this thing or you upgrade, then you can get these features.

Exactly. Yeah. I just called say's pitch. I'm not sure if there's an official name for that.

,

You're the business person, right?

Yeah. Fair enough. Well, I'm also reminded of in addition to this idea that so much of building an app is not what you think of as building the app, building features and creating value for the end user and solving their problems, but is all these meta things that go around it that are necessary in in fact critical, like getting that paywall right? Making sure your app presents well in the app store. All those things are so important if your business is gonna survive and ultimately if, yeah, people are gonna find the app and use it and want it and pay for it in the first place in order to get actual value from it. But so much of that is outside the realm of maybe what we got into do this for. And there's a parallel on I think the company side as well. You know, at some point after I started my entrepreneurial journey, found myself my day absorbed with employment contracts and filing taxes and you know, twiddling admin interfaces in some SAS tool that I use and I said, Was this my dream? This is the thing I wanted to do . But yeah, that's just part of it. It's the reality.

It really takes me back to the beginning of the conversation when we were talking about how important it is for a coder turned manager to stay coding and to stay, you know, involved in the product somehow, even if you might not be writing features every day, but to still find that thing that brought you there in the first place and to still find that original motivation and that original excitement in the product. I think for me it's certainly the code, it's certainly some of the elegance around that or the data structures. It's the piece that I enjoy. But for others I think it's the team or the cohort of people that you've built that are going on this journey with you. What is that for you, Marcus, that you know, you've been doing this now for, gosh, at least 14 years, maybe longer than that. What's been that thread for you that's really tied this together? That's been exciting.

There were always those ups and downs where I wasn't sure what my job really is. Should I do more coding? Should I be more involved with the vision of the company? And I think one or two years ago I kind of realized I had lost the vision on why I actually wanted to do this app. And then I took a little break and I came back really strong thinking that I want, my vision is not that I code every feature that I know every part of the app, but my vision is that I really want to create a great app for the platform. I want to enable our customers, our users, to find their own excitement inside the app, to enable them to use the app in a way that brings their creativity to the front and always thinking that helps me really to stay motivated and find the real vision behind what we are doing.

Well, let's wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter, Add meuse app HQ or via email hello muse app.com. And Marcus, thanks for becoming one of those indie developers that inspired you and now hopefully you can inspire that next generation of developers who can build productivity tools that are made with love and intention.

Thanks again for having me and being able to tell my story, which is hopefully inspiring to some of your listeners.