Welcome to Under the Radar, a show about independent iOS app development. I'm Marco Arment. And I'm David Smith. Under the Radar, it's usually not longer than 30 minutes, so let's get started. So... Recently, as listeners of ATP might know, my family purchased our favorite restaurant to save it from possible worse fates.
And so we have been spending a lot of time basically getting that transferred over and getting it ready. And we are not day-to-day managers of it. Fortunately, the staff will do that. There has been a lot of work for us in kind of transition and setup. And so as a result of that, I have been doing almost no work on Overcast for maybe two months or so.
That has put me in kind of an interesting position of first of all like kind of every day kind of just crossing my fingers and hoping like I hope nothing breaks today. And I think there's also been a little bit of kind of guilt that I should be working on it. Maybe that's a topic for a different episode. And don't worry, everybody. I'm coming back to it. It's just a question of getting things, finishing up all the transfers and setup processes so the staff can do their jobs.
So in the meantime, it kind of got us thinking like designing or considering – self-sufficiency in our products and our apps and our services. So that right now, the reason I've been able to mostly not work on Overcast for a couple of months is the result of Having built a lot of headroom into things, having designed things to not need frequent or constant daily interaction, and for the very few things that do need regular interaction.
making those things as few and simple and fast as possible. I have spanned in my career lots of different roles and product roles from needing constant attention. Like at the peak of Tumblr, like most of my time at Tumblr, I was needed to be constantly on call because the growth of the service was so strong and we had so relatively limited resources and staff.
I was constantly on call to deal with servers that were exceeding capacities and breaking and falling over and failing and errors and things like that. Over the course of my career since then, Tumblr was kind of the peak of that kind of stress and high-stakes environment. And then Instapaper after that was like a little bit –
because it was just way less traffic. The servers were still a little bit needy, but way less traffic. And then I had to... often deal with with incident paper like the article parser is now broken on some popular website and i have to go make a you know make a definition or rule change to fix that on some other website
So there was constant need there. And Instapaper, I had a lot of support needs as well. And then Overcast, having learned from Tumblr and then Instapaper, I designed a lot of Overcast to not... nearly as much manual interaction from me. And so there's been different design decisions in place there, different feature designs, different expectations, and just a whole different kind of app. And I've kind of landed in a place now where...
I'm still running servers and a decent amount of them. I think I have 25 servers. I'm still running servers, but things are much more stable now than they used to be. So I'm wondering, Dave, like how have you found your journey through that and what have you found to be helpful there? Yeah, because I think this is certainly something that I have learned the hard way. I think in some ways the same as you where you if you don't think about.
This kind of self-sufficiency or the degree to which you are putting yourself or some person specifically. into an essential role of your app, eventually that is going to come back and bite you because they will inevitably... And in some ways, it makes me think of how it is so easy in the early days of designing and building something to not think about the downsides of success.
where it is, you know, you start to think about like, oh, well, I just wanted to succeed or exist in the first place. I don't think about, well, what if it exists and exists 10 years into the future? and is going to be something that is going to you know is what i'm doing sustainable like maybe it will be in the short term but it won't be in the long term like i think the most the biggest place i ran into this was when i launched feed wrangler gosh this is probably like
I don't even know, that was 10, 15 years ago, a long time, which was an RSS syncing service. And it's like I launched it and didn't necessarily... It was initially built just in a very basic, simple way, and it was more successful than I thought it would be, which was a great problem to have, but it meant that I had architected a lot of the back end of that system to not, you know, to...
be running close to its thresholds and to be using things in such a way that eventually, like as you screw, the whole thing would just start to fall apart. And I was just constantly in there getting notifications, you know, oh, this service is down, this service is down or this.
aspect of something is above you know the cpu load that i had an alert for and like it was just constantly i was involved i was the linchpin i was the thing that was holding like i was the duct tape holding the whole system together and that was a terrible place to be. That was not a great situation because it was not sustainable. Because if it meant that I took a couple of days away from the system and something went wrong...
very bad things happen. And in the case of Reed Wrangler is a sort of, I guess now a famous story where I went, you know, spent a couple of days in a cabin in the woods and, you know, 10 minutes after I left cell phone.
reception it fell over and for two or three days it was completely down and it started off people were grumpy and then people were worried about my safety and like it was it was a whole situation right because i had built this thing that didn't have margin, didn't have headroom, didn't have...
This was able to be sustained by my effort, and that put me in a bad position. In the case of Feed Wrangler, eventually I just solved it with money, where I went from shared hosting to dedicated hosting that was... substantially more expensive, but gave me so much headroom that I didn't have to be, you know, it's like my, the servers could deal with my lousy code in that way that made it sustainable. But I think in the same time on. ios and on the apps that i've built there's an element where i
intentionally now try my best to build and structure my apps so that they don't rely on me for anything. And this has been very, it was very, you know, there's situations where like, When Widgetsmith had its moment and had this massive explosive growth in users, I was incredibly glad that no part of that app...
had a server component at that point. There was nothing it did that required something other than locally on the user's device. And if you can push and maintain the user's device as the extent of largely what you're doing... There's a lot less things that can go wrong. There's a lot of fewer things that are going to come back to bite you. But subsequently, as I've been building out features or building things, you inevitably find yourself in this place where you're like, ooh, I could do this.
that but that would require me to build a server or to become responsible for something or to deal with user data in a way that is different and that is a tension that now I have this feeling of like, you know, I'm pushing as much logic, as much thoughtfulness I can into the client, into the iPhone app itself, do as little as I can otherwise.
Because otherwise I do become essential. I do have a role to play or I have a responsibility to play. And that is a dangerous thing to do because life is going to change. Life is going to come and you'll be seasonal. Like right now you're in a season where... you are running a restaurant and setting that up. And as you say, like, that's not going to be probably forever, but it's going to be for some amount of time.
I've definitely had periods for health or personal or family reasons where I have to step back from work for extended periods, for weeks or a couple of months at the longest I think I've run into. And in those periods... it's really awkward if you can't go on leave because you're an indie like you don't have this big staff or team who could just step in and you know pull up the slack in theory maybe you could hire someone to be you but like
that's really awkward and complicated and difficult to do, especially if the reason you're taking this break is unplanned and awkward and you're not in a great, you know, physical and health, emotional, whatever state, like there's reasons why. planning for this ahead of time can be really helpful and so yeah it's like it is the self-sufficiency aspect is something that i am so grateful
that past me has transitioned into this mindset that I want to not be the linchpin or have any person really be involved in the day-to-day core functions of an app. And as a result, when things come up, when I have to take a step back.
It's usually totally fine. And there's nothing that I need to worry about. I can go off, you know, go to the cabin in the woods for a couple of days now and not be worried that something is going to horribly have, you know, blown up in the meantime, because that's just. fundamentally how things are engineered. And that took intentional choice to get to that place.
We are brought to you this episode by Things. If you want to achieve a goal, you've got to have a plan. When it comes to making a plan, there's no better tool than the award-winning to-do app, Things. The idea behind Things is simple.
Create a project for each of your goals, add the steps to reach those goals, then schedule when you want to work on them. Then each morning when you wake up, Things has already prepared your list of to-dos for the day. Just spend a few minutes reviewing the list, put your to-dos in the order you plan to do them, and then get on.
on with your day it doesn't matter which device you're on your to-dos sync through the cloud so they're always with you on your computer in your pocket even on your wrist you can also connect your calendars to see your events scheduled to-dos that automatically repeat you can write your notes and things
markdown on each item and so much more. But when it comes to things, what you'll love more than any single feature is the app's amazing design. It doesn't just look good. It feels good to use. This is a native app made to a very high standard. And it's a two-time winner of Apple Design Awards. So if you haven't tried Things, you've got to check out the latest version. And I've got to say, I fully agree. Things is by far the nicest.
to-do app I've seen on Apple's platforms. It's not even close. It's by far the best. Check out the latest version of Things if you haven't tried it or haven't tried it recently. You can download a free trial for your Mac just to go to the website at things.app. That's T-H-I-N-G-S dot app. Exactly what you think. Things.app. You can also find it in the App Store. Just search for Things.
Whatever it is you want to accomplish in life, things can help you get there. Try things today at things.app or click the link in our show notes. You will not regret it. Our thanks to things for their support of this show and all of Relay. So I'm kind of thinking like...
When talking about self-sufficiency in apps, I kind of categorize it into a few different types of considerations. So I think number one thing that you want to avoid if you want your app to be reasonably self-sufficient is... editorial roles for yourself so this and this obviously varies based on the type of app so like in my extreme case when i was running the magazine
The entire product was the editorial content that had to be put out on a fixed interval. So there was no way for me to run that myself. And have it be any kind of self-sufficient and have it tolerate any temporary losses of my time and resources because the whole thing was the editorial content that had to be put out every two weeks.
What that could look like would be things like featured podcasts in the directory or any kind of like this week we're featuring this or here's a news post that shows up in the app every two weeks or whatever. Anything like that, I have intentionally not implemented human editorial content in Overcast. Because if I did, that would require that I go and... make that or do that or process that and that isn't just typing some things into a text field necessarily like if it's if it's
podcast featuring, for instance, for the editorial directory content, that could require things like not only me finding the right podcast to feature, but also maybe like writing up a quick blurb or getting a certain size image or something like that. And all of those.
things would add up and it's better off if i don't rely on that kind of thing uh rely on myself for that kind of thing because then i would never be able to take a week off from that that's something i'd have to do all the time um kind of an offshoot to editorial is anything that is content in your app that is written by humans that becomes visible to other humans. And of course, that's not just writing. It could be photos or whatever. And you can think, if there's any...
venue for users of your app to write things visible to other users. Then you create the possibility for spam and abuse and copyright violation and all sorts of, you know, problems that you'd have to monitor and moderate and deal with and filter. And so again, in Overcast, there is no user review feature. I've intentionally left that out. So there is no way in Overcast for users to...
post or create or write things to other users. That way I don't have to deal with all of that. Because then there's all sorts of... of complexity there you have to deal with not only you know what's decent and right but you have to deal with what's legal and you have to deal with what's legal and decent and right all over the world in all different languages around the world that you don't speak so it's there's lots of potential mess there
You can design your app not to have the user-facing content made by other users. And then you start looking at other areas of... What can make an app sufficient or not? Infrastructure is a big one. And again, we're talking things like servers. Infrastructure can go into other areas too, like if your app shows content, where is that content coming from? Does that require some kind of maintenance or special casing ever? You have to deal with that.
Then there's business roles of your app. This is like, where does your money come from? Or do you have business relationships that you need to maintain? In my case... Overcast has ad banners for the free version, and I sell those ads on the website. So I have set that up so that every new ad I have to manually review and approve.
I have then created a job for myself that like when people buy an ad, it does not go live immediately. It goes into a queue and I have to go a couple of times a day and go refresh my admin page for that queue and see if there's any ads there and approve any that are there.
If I'm really busy, say I'm traveling with family or something and I'm really busy, I still have to do that. Like if I don't do that, those ads will just sit there and the advertisers might get mad if they're sitting there for more than, you know. 12 or 24 hours, like, they might start to get annoyed, like, why isn't my ad approved yet? And I don't get money until it's approved also. So there's, you know...
I have created a job for myself, but it's a fairly simple one. But that's still – if I was going to be so disconnected that I couldn't go do that at least once a day.
I would have to have somebody do it for me. That's how important that is. And then as you move up the ladder from that, I think the next up is support, like user technical or whatever support. This is... probably the biggest one of these but i think it's the easiest to deal with uh in the sense that like you will get the most support like if if you've designed your app to not have editorial
to not have human-to-human contact, to not have tricky or high-maintenance infrastructure, to not have high business development needs, support will then be the thing that you have to deal with the most. The good thing is that support is also usually the least pressing and the easiest to outsource. So if you fall behind in your support inbox by three or four days,
probably doesn't matter that much. Unless you have serious problems, you're probably okay with that. It's also the easiest thing if you want to hire a service or a person to cover your support for you. That is not... I wouldn't say it's easy in absolute terms. I've had very mixed success there myself, but it is the easiest to outsource of all these other things typically. So that's something you can cover, you know.
somewhat reasonably and you can also choose or design your app in such a way that it either doesn't need a lot of support hopefully or in in a slightly worse case you can do what i do and Set expectations to people that you don't really provide support and that most emails will not be answered. And then it becomes more of a kind of feedback or user request channel, which is very valuable in its own way.
far less engaging and far less demanding of your constant never-ending time than support. And then finally, after all of that, if you cover all those things, then you have actually the code of the app, the writing of the app. bug fixes, updates. And that is the best thing to be the thing that's falling on you because that's the part that you can do best and that you can often do on your own time.
in your own schedule and your own priorities. So that part, like we all have to deal with occasional bug fixes, you know, but for the most part... Until the OS changes under our feet, which does happen, but until the OS changes from under our feet, we can usually do that when we are good and ready. And so in my case with Overcast...
I did a whole lot of work on the app during all of last year and the year before. So last year was a massive overcast year. And because I did all that work, I'm able to take a breather now. Like the app is in a pretty good place now. A lot of the old problems with the old app are gone. Most of the problems with the new app are resolved. And so I'm able to take...
a brief time off now for a few months while I get all this stuff sorted. And then I'll be able to go back to the app on my own time, most likely this summer. and get back into the full bandwidth swing of things with the actual bug fixes and improvements and new features and new designs and stuff like that.
And I think in that, it's like you've made those choices as you work your way up that. And I think the interesting aspect is, A, that's a choice you have to make. And I think it's interesting. It's important probably to understand that. If at those, as you're working up that hierarchy, if you have a project or something in mind that requires you to not.
you know, to not decline a feature or to deal with something like if you need user generated content, if you need to deal with moderation or regular updates or business to business stuff, like if that is essential for your thing. He's like, most likely, it's good to keep in mind, you're likely going to need a staff. You're likely going to need people to, or maybe not necessarily a staff, but you are going to need outside help.
to accomplish those things if they become important. Because it is unlikely or unwise, perhaps moreover, to think that you would be able to just indefinitely manage that yourself. It's like, maybe you don't need the outside support. initially while you're until the thing actually happens. But as soon as it actually happens and you've suddenly created this sort of situation that you exist in, you may need that outside help. You may need that extra thing. And something like on the servers.
and servers and services side. It's like something I've gotten into a lot more recently is like a lot of my services, they rely on these small, dedicated, sort of one-stop. APIs that are necessary for something. So like in, you know, Pedometer++, there's a thing that does directions for hikes as you walk around. And that was, could have been as I was deciding, it's like, do I want to build something like this myself?
you know, sort of explored and it's like technically possible. I could have used open street map data and like this whole thing, infrastructure I could have built. Instead, I decided, you know, I'm going to get external help with that. And so I use Mapbox, which is a... like a dedicated API provider who that's what they specialize in. And it's now become, in some ways, their problem that if their service goes down or there's some data change or some...
aspect of this needs to be updated. It's like they have an expertise and a specialty. And a sort of an obligation to some degree to take care of that for me. And I think that has worked out really well for me in a lot of ways where in some of our things, I think both you and I, we tend.
The code at the bottom of our app, we tend to exert a fair amount of control on. We don't tend to use a lot of third-party libraries. We tend to roll a lot of things ourself. And I think that, for both of us, has kind of worked. well insofar as we have a deep understanding and control over that part and that works well because that part
isn't really ongoing in the same way. It's ongoing in the sense that we have to update our app and do bug fixes, but it doesn't have the day-to-day, hour-by-hour sense of that. But as soon as it gets outside of the iPhone itself, look for other ways that I can do this, that I can get external help.
Last year, I've subsequently hired someone who helps me with a lot of the other things that I can't do because some of these roles are essential and are inevitable and are just part of the deal. But it's important, I think, to understand that.
If where you're going to need external help, like that's going, that's going to happen. And if you don't think about it ahead of time, it's like the, eventually the situation will present itself where you will have to think about it, but sort of, you can decide how you're going to go. And it's like, for me, I spend money to avoid this. Maybe it's another way to the important aspect of this, that like one of the things that is easy for me to get stuff sucked into in the early days of.
being indie was that I was very adverse to spending money on anything. I would always think, well, I can do it myself. I should just do it myself. And. While there may have been a very narrow, brief window where that was actually necessary in terms of getting the business up and running, that window was probably a matter of a few months. And I probably held on to that mindset for a few years.
That I was holding on to this view that I needed to be involved in all aspects of things and didn't get the help I needed or tried to take on things that I probably shouldn't have. And I not treated it like... If I can exchange money for my time, that is usually a pretty good exchange. That is usually a thing that is going to come back to benefit me. And in terms of making my apps more sustainable, it's like as long as the app is generating enough income to do that thing, that to pull me out.
of the the critical path of something that's a great thing and if it doesn't if the app you know if the business doesn't generate that income to provide that um you know to externalize that need it's like the business isn't really a business. Like if it's only held together by me being the duct tape, it's not a business. It's not sustainable and it's not going to live up to the long-term turbulence of life, I suppose. Yeah. I mean, and that's, I think it's really important to recognize.
That like no matter what you think when you're designing something when you're in your 20s, no matter what you think. You will have times where you need to pull away from things. You need to not be available for various reasons. Maybe it's a health thing or a major family event or a loss.
just something something really important is pulling you away and even you know look every night you have to sleep at some point you know so every night like there's there's like there's small scale versions of this happening every day for you uh and then you know there's there's
possible big-scale versions of it happening when life throws you a curveball. And so you should plan for this whether you think you need it or not. And then it's a question of just how much. And on the other side of that, what I'm not saying... is that you can just set things in motion and then just never think about your business again. I'm definitely not saying that. The way I view a lot of these kind of life curveballs.
is more like you know you have like the short-term versions of sleeping every night and maybe you know having a weekend to yourself. But then you have longer-term versions, and those are kind of like sabbaticals or, you know, like parental or, you know, maternity leave. It's like, well, you know, you can take leaves from your work here and there.
If you are always on leave for many years, you're not really doing that job anymore. But you should build your job in such a way that you can take leave when you need to and the whole thing doesn't fall apart. And there's a lot of distance between those two extremes. And so if you are never taking time off, that's not healthy for you. And if you are always off.
That's not going to be healthy for your business, but a lot of things in the middle are just fine, and that's life, and you can make that work if you think about it. In a weird way, it reminds me of I had a friend who used to work in finance, like doing kind of stock trading and all kinds of things. And his company had a policy where every... He had to take two weeks consecutive leave where they completely shut him out of all of his work systems. That's awesome.
And for the company, it was this way for them to safeguard against someone who was doing dodgy trading or doing things. Doing this thing where they were wash trading or finding ways to hide a big loss or a big problem by continuously doing things that... you know, sort of hit it. But if after, you know, if most of those kinds of schemes or trades or things would unravel if they weren't sustained for...
You know, in this case, a two week period. And it was a way for them to safeguard against that. And in some ways, that makes me think of as a just a mental exercise for it's probably useful for us all to have. It's like if we had a two week period. where we were completely disconnected from our work.
what would suffer as a result of that? What problems would be revealed? You know, in this case, it's what are these, you know, what maybe in your case, like your ads wouldn't be sold. And like that has a certain cost and maybe that's okay. Maybe that isn't. But it's probably just a useful mental exercise to think about. If I completely logged out of all of my systems, never went, didn't check my email, didn't log into my servers, didn't look at my stats, all those kinds of things.
What would be the consequence for, you know, I think two weeks is a reasonable amount of time to think about where some, so many things, you know, we'll probably be fine for a couple of days, maybe a week. After two weeks, maybe you'd start to run into trouble. And if you have things in your app, in your business, in your situation that couldn't survive two weeks of you being away.
That's probably something that's worth looking at and understanding and making sure that you have at least a vague notion of what you could do to address that. Sometimes that's going to happen on a positive sense. You're going to buy a restaurant. You're going to want to set it up. It's going to be fun. There's going to be a great reason.
Sometimes life is going to cause you to have to do that. And so being ready for it is just a wise move to do when the sun is shining and things are straightforward is much better when you're in the middle of the hurricane and things aren't as great. I love the idea of that as like a safeguard against fraud in the financial industry, but also like showing you like, are you irreplaceable? And if you design something like that, you're also making sure.
In the case of your friend's business there, they're also making sure nobody's irreplaceable. If somebody got hit by a bus, no one is irreplaceable because if their job just doesn't get done for a while. The business can continue and the system will not fail. And that's a hard thing to design for when you are a one-person business. But it's not –
Totally impossible. So I like the idea of challenging yourself to start thinking about that. Like to say – start thinking like if I had to drop everything with no preparation, if I just got pulled away, maybe I was knocked unconscious for two weeks. So I had no time to set things up or change things. What would happen and how can I prevent the bad outcomes there? Hopefully it never happens. But if you're ready for it, then it won't matter if it does.
So, yeah, just one of these things to keep in the back of our mind, especially in perhaps the quieter time that we're in before, you know, the summer busyness. It's like maybe it's a good time to think about how we can make ourselves a bit less essential and a bit more replaceable in that way, I suppose. Thanks for listening, everybody. And we'll talk to you in two weeks. Bye.