267: Don't Run Servers
29:27 Share

Welcome to Under the Radar, a show about independent iOS app development. I'm Marco Arment. And I'm David Smith. Under the Radar is usually not longer than 30 minutes, so let's get started.

So before we get into our actual main topic for today, I just wanted to have a brief public service announcement that as we are recording, we are but a handful of weeks away from WWDC. And as such, it is the time for my annual message to every developer out there who will listen that now is the time to start preparing for WWDC Labs. So in case you're

If you haven't been to a WGC before, or in terms of the way this is usually structured, typically Apple engineers are sort of sequestered behind a veil of secrecy and you aren't able to interact with them generally.

except for during labs, which Apple has started doing not just at WEDC, though I will say typically the largest and most wide-ranging labs are at WEDC. And these are an opportunity where, at least in the last few years, the way they structure it is you'll have a 30, I think 15 minutes or a 30-minute Zoom conversation with

an engineer, multiple engineers at Apple, where you can talk about issues you're running into, problems you're having, suggestions you'd like to make. And this is just an opportunity to actually connect to an engineer, to have them look at your code if you want, so you can do screen sharing and show them something. Or similarly, they also have design labs or accessibility labs, which are places where you can have some review of the accessibility of your app or

review your designs. And I would just encourage everyone to start thinking about whether and how you can take advantage of those lab opportunities now. The reason I say that is if WRC rolls around, you decide, hey, I'd like to go to a lab, you

But you don't actually have a list of questions. You don't have a list of topics. You don't have things that you actually want to deal with. It's very potentially hard to get a slot in terms of when you request a slot. They ask you to kind of describe why you want it. And so having a reasonable list is probably important in case it's an oversubscribed lab slot.

But also just to be better prepared, because the better prepared you are for your lab, the more you're able to get out of it. And I over the years have, you know, this is a method that I have used, you know, countless times, I think this will be my 15th WWDC. And so like, I've honed this process down, because it's so valuable. And because it's something that I find that, you know, I always around this time of year, a little bit before maybe, you

start a list in reminders that is just questions for WDC. And anytime I run into something or think something pops into my mind, I'll write it on that list. And so then the week of WDC, I can kind of, you know, take in the announcements on Monday, work out if there's any new things to it, and then use that as my roadmap going forward. And by being prepared, I've, you know, get a ton of value out of it. So this is just my little thought that now is the time to start thinking about that. And, you know, inevitably, over the next few weeks, things will come up, you'll have ideas, you'll

start capturing those in a way that will allow you to be prepared and ready to take maximal value of that when WBC gets underway. I personally have almost never come to the labs with real questions that are prepared ahead of time because I never follow this advice. And so every time WBC comes up

And I had the opportunity to possibly meet with engineers. I'm like, oh, man, I don't really have any questions today. Right at this second, I don't have anything because I didn't do my homework, of course, the story of my life. I didn't prepare for this. And so please, listeners, don't follow my example. Follow Dave's example. Be prepared. Start now. Recording things now. Make a list now. Because...

In the few times that I have actually taken advantage of the labs, they have been extremely valuable. I cannot understate how or I cannot overstate how valuable the labs have been. Really take advantage of them if you can. And the way to take advantage of them is to have some kind of question to bring to the labs. And so start start thinking about those and writing them down now.

All right. So on to our actual discussion for this week. And I think the thing that I thought would make sense to sort of bring up and sort of discuss is –

I guess a new or increasingly solidified rule for indie development that I have settled upon. And the rule for indie development that I'm settling is never make a server unless you absolutely have to. Don't do anything. Don't touch servers unless it is an absolute requirement. Just stay away from them because it's...

In the history of my indie life, every time I make a server, eventually I end up regretting it. It is just a rule for my history, and sometimes the impacts of those will have to carry for years and years, and it's complicated, and just don't do it. And I think...

The rest of this episode will be kind of walking you through the nuance of that. Sometimes it's important, sometimes you should, sometimes you shouldn't. But in general, start from the premise of never make a server for anything. Don't do it. It's a bad idea. Instead, look for opportunities that you can do

on your phone, on device, and start there. And if you view that as a constraint that you are starting with, I think you can end up with some very interesting and cool places. And specifically, like this last week, I launched a feature in Widgetsmith that kind of crystallized a lot of this for me, where...

Several years ago, I think maybe it was six to nine months after widgets were first added to iOS, there was a spat of trending apps, which were ways to show photos, to share photos with someone else using the widgets on their home screen. And so essentially, it's a method by which

You could take a picture, add it into a particular place, and then it would sort of automatically appear on someone else's phone. The most popular, I think, apps of these was called Locket.

which does this and, you know, a variety of other features, but functionally it's that sense of you want to be able to take a picture and it should have it appear on someone else's block screen, which is a great idea. It's kind of cool. It's kind of a fun way to have this kind of ambient social network situation. But when this, when these, these sort of started to come, obviously I thought to myself, huh, that's interesting. Should I do this? You know, I'm,

Mr. Widget, if there's a hot new thing in widgets, I feel like I should be pursuing it and going after this. Right? That's my thing. And so I thought about it for like 10 minutes. I was like, no, I'm not going anywhere near this because in order for me to do it, it would have involved some amount of server communication involving people's personal photos. And that just immediately sounded like just a complete non-starter and something I never wanted to touch in a million years, like no matter how many

things I did to that in terms of if I tried to end-to-end encrypt it or whatever it is. At some point, if I'm managing a server that is having people's personal and private photos move through it, that just sounds like a disaster waiting to happen. And so I just wrote this feature off and said, no, it's never going to happen. And I just went on to the other widget features I could think of. But then recently I had someone who reached out to me and said, hey,

I want to have a way to ambiently share photos with my wife. And what I'd love to be able to do is if you could just make a widget that is the album's widget you already have, but rather than showing a random photo, could you just have it show the most recent photo that was added to that album? And then I can point it to a shared album on my wife's phone and I could share photos with her of things I'm seeing throughout the day that make me think of her and

you know, it was just like that only they'd ever heard of lock it or any of those kinds of apps. They were just like, this is something I'd like to do. And as soon as they said that it was like, wait, this is genius. Like this is exactly like the ideal scenario for me where I can build this feature and

but never have to ever see or touch these users' photos. This is entirely done on device. It is entirely leveraging iCloud photo sharing to do all of the heavy lifting and all of the privacy concerns and deal with all the issues that come along with that. And so I did it, and it's been very popular. It was just kind of a fun situation of this, of I think...

You know, I'm glad I waited. I'm glad I didn't build the servers. This, you know, obviously isn't the same. And I think that's something that certainly will be worth us unpacking that by going this route, I'm, you know, shoehorning a little bit or limiting what my feature can do in a way that if I had built my own servers, I could have done so much more. I could, you know, do all kinds of different sharing models or, you know, had different things going on with it. But,

By being patient and taking a different approach, I think it opens me up. It opens up this feature as a possibility, but while foreclosing huge swaths of problems or issues and headaches that I now don't have to deal with because they're not my servers. Yeah, I cannot...

echo this advice enough again in continuing the theme in another way in which I did not follow your advice and regretted it constantly. I currently run a bunch of servers and I hate running servers. I can't tell you how much I hate it. And I'm lucky in the sense that the servers I run now

are way, way lower needs than what I used to have to deal with. Like, Overcast is lower needs than Instapaper. Instapaper was way lower needs than Tumblr. And so I really... I have a pretty good situation going here as far as servers go. But it's such a pain. And it's so much... It...

It's tempting when you're a nerd like us and you think of some new opportunity or some new opportunity to present itself. And you're like, wait a minute. If I quote just, and this is the biggest just in the world, if I just bounce this off a server or use a server to sync this thing over here, then I can enable this cool feature or deliver this great value to my users or have this amazing capability. And

When you're in that mode, when you're in the new idea promise mode, where you're looking at something that could be really promising,

In that mode, your mind, I think, I'm not a psychologist, but it would not be surprising to me if there was some actual chemical in your brain that at that moment made you totally minimize or just block out or forget all of the downsides of what you think you need to do to get there. So in the sense of, oh, I need to bounce off a server?

That word just, I'll just put a simple server up here, or I'll just put it on AWS and some kind of weird abstracted server product that they or Google or Microsoft or whoever have. So it'll just run some JavaScript. Maybe I'll just run it on Cloudflare's edge nodes or whatever. There's always a just.

And and the reality of that is always more complicated than that. But in that moment, your brain is not letting you see that reality. Your brain is totally tricked by man. That would be cool if I could get it to work and then I could do this cool thing.

And I think it's really useful to, I mean, you know, look, when, if you're like young and don't need sleep, go for it. You know, especially, especially if you're like working at a startup or you're spending someone else's money, like go for it. That's, that's the time to do it.

When you are a middle-aged indie developer like us, and you want to be able to do other things with your life ever, and you need to care about how much things cost over time and how things scale over time, really think about that carefully. Because usually, this is one of the cases where

you know, look, oftentimes there are certain problems that you really just kind of can't solve without running servers. For instance, if you need to have some kind of cross platform thing, you know, you want to want something to work on windows and Android and Mac and, and iOS and, you know, Kindles, whatever, like whatever you need to do, like if you need something like that, it's going to be pretty hard to do that without running services of some sort on the, in the web. But, uh, there's a lot, if you're just an indie iOS developer for the most part, you know, like us, um,

There's a whole lot you can do just on device or just using the stuff Apple gives us for, okay, I was going to say free. I know free here is similar to just earlier, but, you know, we'll just go with it. But what Apple gives us for quote free, there's so much we can do there. And a lot of times the idea that you have or the problem you want to solve

A lot of times, you can get like 80% of the way there with just doing on-device stuff and CloudKit or whatever else. You can get away with a lot of what you want for zero downside on the server side. Now, that's not to say these solutions don't have challenges. Certainly, if you start doing things like with CloudKit, there are challenges there. There are limitations there. There are edge cases and problems that you'll have to deal with. But...

There also are all those challenges and edge cases and problems to deal with when running servers. The difference is once you figure out CloudKit, it tends to basically work and you don't really have to do anything ongoing for the most part. I know there's a lot of asterisks here, but bear with me. The difference between that and running your own servers is extraordinarily different. Running servers, and again, I run really low needs servers. I usually don't have to do anything for my servers. But

But I still have to maintain them all. I still have to set them up. I still have to adjust them as my needs go over time. I have to manage their costs. And by the way, server costs are going up now for the first time like ever because energy costs are going up like crazy. So all of a sudden my costs are like 20% higher than they were a few months ago. And I didn't get anything extra for it. It's just higher cost. I just have to eat that.

If you were based on local device stuff or CloudKit, you wouldn't have to know about that. As the server world changes, your knowledge has to change. The way things are done changes with servers. Different tools come in and out of favor. Different security needs come up that you have to deal with. Different infrastructure things like IPv6 you have to deal with now, which I didn't have to deal with when I first set up my servers a million years ago. There's stuff like that that comes up and

Every single time I have to deal with one of these things, I'm like, you know, do I really want to be running servers? Like, this is not what I do best. This is not what I like doing.

All it's doing is a supporting role to my app that most people, while they rely on it, they don't know they rely on it, and they don't care, and they don't appreciate it, and they don't necessarily need to have the app that relies on that. Most people who use my app use it on one device, and I don't really... They don't need to know what's on the back end powering all this stuff. They don't care. And so...

Running the servers is almost entirely just a burden to me. It's not really providing tons of customer value that they can see and know about. And it isn't the only way to do it. If I really wanted to totally remake the app to not use servers...

I could, and I wouldn't lose much except a ton of time. And that's kind of why I don't do this, because it would take a ton of time, and it wouldn't be as good in certain ways at the result. But I could actually achieve 80% of what people want totally serverless. It would be fine. And so I look at, as I'm developing features over time now,

I'm looking at reducing my server usage, not increasing it. Like I'm doing this giant sync engine rewrite and data layer rewrite using my Blackboard engine and Swift and Swift UI and async and all this stuff. And part of that is reducing

designing the sync protocol to be extremely efficient from the bottom up. Try to reduce the server needs as much as I can with that. Moving certain things to the devices too. For most of the last decade I've been doing Overcast, I have generated my own image thumbnails for when you search for a podcast and it shows the search list and everything because podcast feeds, they only include one size image in the feed and it's the full size one and that could be a couple of megs.

and 3,000 pixels wide. And so if you're showing a list of search results that you just need something that's like 100 pixels wide to show a little thumbnail, you don't need the three megabyte, 3,000 pixel one. And that would take a long time to load. And so that list would load slowly. So there's a huge advantage in generating your own thumbnails server side. So I do that. And that's something that it's somewhat difficult to not do if you're running a podcast app.

But there are simpler ways to do that. You can outsource that to a CDN with built-in image resizing functionality. You can have very simple services that do that or it costs a little bit more usually, but you can have that kind of be like an isolated box you don't have to think about. Also,

I used to download those thumbnails to the phone because the phone has to display small thumbnails a lot. And so does the Apple Watch and everything else. And a lot of these, like the Apple Watch, has memory constraints. And so for a long time, I would download multiple sizes of those images when you would like, you know, add a podcast. I would download those to the phone and to the watch and instead of having it resize them locally.

Well, now the hardware is so good, even on the watch, that I don't need to resize them server side except for search results. Now, for your regular podcast subscriptions, like when they change their artwork, when you add an inscription, it just downloads one. It just downloads the regular one and it doesn't even touch my servers. It goes directly to the publisher, downloads the one master artwork file, and then generates thumbnails from that, even on the watch.

And the hardware is now fast enough and good enough. I can do that. And it doesn't like run out of memory or crash or give me like high CPU usage terminations or anything like that. And there's so many things like that. You know, now I could even do things like recommendations on the, on the phone. I don't yet, but I'm moving towards being able to do that. And I think this is an important kind of balance to consider as we move towards this, this new world of having a lot of really complex AI models and, and model model powered features. Um,

The iPhone is really good at running certain types of AI models and ML, you know, I don't know many of the terminologies, but you know what I mean. All the different AI, ML kind of models. And if you can make something run locally, it might not be quite as powerful as something running server side.

But it's free. It takes nothing from you. It just takes Apple enabling certain functionality or it takes you shipping a model. And there's various methods Apple has to encrypt and protect those models if you want to ship it with your app without having people steal it. There's all sorts of stuff like that. And I think this is really underused in apps because most apps currently that are using AI models are big company apps. Or they're stuff that is capturing the value in

let's just make something that's a front end to open AI's web interface and put an interface on that and ship it. And there is value in that, but...

Ultimately, the significantly better business for most people to be in, if you can, is to do stuff on device where you're not running any servers. You're not running any API keys for anybody. You are just running stuff on device and you don't have to deal with throttling or well, not server side throttling. You don't have to deal with the massive scaling costs of that. And I think moving into this world of AI stuff,

It is going to be really tempting. It already is for lots of people. Really tempting to look at what is now capable and what will become capable in the near future and say, oh my God, I have to rush to build an app against that right now.

and set up servers and and bounce stuff through an api or whatever or run your own models on your own expensive rented hardware or whatever it is it's so tempting to see that opportunity there to say oh my god if i just set up a farm of high gpu servers with this like you know four gig model that you know if i just do that i'll have this amazing powerful app feature that i can that i can ship and

You can, and that's an option, but you can also probably do quite a lot, probably more than you think, with the hardware in people's phones locally for free and not having to run any of that stuff.

And I think there's opportunity on both sides of that. And the opportunity on the side of the phone is going to be the one that is dramatically underused because most people don't know about it, don't see it, or underestimate the downsides and costs of running servers. Whereas if you are out there taking advantage of stuff you can do on the phone, not only will Apple like you a lot, and I think that'll add...

it'll increase your chances of being featured and stuff, which is nice. But also you'll be saving yourself all that time. And you'll, in many, in many cases, you'll be providing a better experience because there won't be network latency or it'll work offline or, or things like that. So there's a lot of value in doing stuff locally and whether it's the cool new AI stuff that, that is cutting edge now, or whether it's really old stuff like imagery sizing, like there's so much you can do locally on, on devices. Now the devices are so, so,

vastly powerful. You have no idea. If you haven't really pushed these devices to do something computationally that you think will be really slow, you don't know how fast these things are. Because everything I try to make the iPhone do that I think is going to be really slow ends up flying by. And I'm like, well, that was stupid to worry about. Why did I ever think this would be a problem? So anyway, do things locally when you can. It is really, really powerful. It is really nice. And

You can usually achieve at least 80% of what you want and then not have to run servers. And believe me, running servers is so much more than a just. Anyway, we are brought to you by Indeed. When it comes to hiring, trust your gut. But what if you can give your gut some help? When you want to find quality talent fast, you need Indeed, the hiring platform where you can attract, interview, and hire all in one place.

Don't spend hours on multiple job sites looking for candidates with just the right skills when you can do it all with Indeed. Find top talent fast with Indeed's suite of powerful hiring tools like matching, assessments, virtual interviews, and more. And if you hate waiting, Indeed's US data shows over 80% of Indeed employers find quality candidates whose resumes on Indeed match their job description the moment they sponsor a job. Instant match really is incredible.

Sponsor a job, and Indeed will match you with quality candidates whose resumes on Indeed fit your job description right when you post. With Indeed, you can start hiring fast. Join over 3 million businesses worldwide using Indeed to hire great talent fast. Indeed knows when you're growing your own business, you have to make every dollar count. So that's why with Indeed, you only pay for quality applications that match your must-have job requirements.

Visit Indeed.com slash undertheradar to start hiring now. That's Indeed, I-N-D-E-E-D dot com slash undertheradar. Indeed.com slash undertheradar. Terms and conditions apply. Cost per application price not available for everyone. Need to hire? You need Indeed. Our thanks to Indeed for sponsoring this show and all of RelayFM.

Yeah. And I think something that you said there that I think is just, it's in general, one of those things that I think was very important for me to understand early on in my career is the difference between free and any other, any other price.

which applies when we're talking about like on the marketing side, that the difference between being free and a 49 cent app is transformative and radically so. But it's like, there's just in general, that same pattern happens time and time again, that if as soon as you can get something to go to zero, it's fundamentally different than if it is any, you know, any non-zero number.

And I think this is an example of where that comes into play that is just so different. Anytime you have a situation that there is a per user cost to you,

Suddenly your business model and your scaling and what success looks like is radically different than if you have no per user cost, that the actual marginal cost of your product goes to zero. Suddenly lots of different things are open and possibilities that you just couldn't be otherwise. In addition to all the other reasons of being able to sleep at night and not having to have infrastructure that you worry about and have to maintain and deal with and compliance with all kinds of rules. Just in general, there is just all these different things happening.

that are sort of transformatively different as soon as you can get that slide of things to go to zero. So I think that's just important to keep in mind, you know, sort of of anything that any time you can make a choice to move the marginal cost of your user to zero, always sort of if you're on the fence between two, always choose that, I think would be the advice I would give. And I think also it's one of these challenging places where

I think it's important to the other lesson I've learned to me, if I'm like putting together my, like, you know, Dave's rules for indie development is to spend, you spend your time on things that uniquely differentiate your product rather than things that your user will take for granted. Um, and because like, it is so easy, I think sometimes for me to say, it's like, Oh,

It's like multi-device syncing as a great example of this. It's like as soon as you build it, its value just disappears and becomes just like a given. It becomes table stakes. But if you don't have it,

it isn't a problem in the degree that you would think it would be. Like, I mean, Widgetsmith, for example, like you would think in some ways it's like, it's like, I've never done syncing for it. Like if you have widgets, you can't really, you can't really move them from device to device. Okay.

That's fine. People work around it or they rebuild them if they want to. The reality is most people just have one device. I just saw on the news the other day that WhatsApp, one of the most popular messaging apps in the world, just finally allowed you to install it on two phones concurrently for the same account. This is one of the most popular apps in the world, used all over the place, super successful. They didn't have syncing.

And you don't need it because it becomes this, it's not a point of differentiation to the degree that the effort required to maintain and manage it is. And so whenever I think of these features or when I think of if I'm going to build something and then it's just a wrapper around an OpenAI API call or something, it's like that's not a strong point of differentiation. There may be a app there, there may be a market there, but the part that you're building is in that same way of

You're just competing against everyone else who's building a wrapper. And maybe you can find a point of differentiation that is compelling there by building in a super amazing wrapper with super awesome features, but you're not differentiating based on your content. And trying to go down the road of differentiating on content, if you're trying to build your own

Well, I'm going to build my own image generation model. It's like, great, good luck. You're competing against OpenAI, who has hundreds of millions of dollars and the backing of all of Microsoft's cloud infrastructure. Good luck. You're building this thing that isn't actually going to be a point of differentiation to the degree, unless you are wildly successful with it.

in which case you have all kinds of other problems and you're not an indie anymore. And like, you know, congratulations, you're now like a fully fledged VC funded startup with lots of other problems and issues, but you're not going to end up, the end result of that path is not like the happy indie lifestyle of making software that you enjoy making, that is, you know, you're excited about and you can, you know, sort of,

to turn off your computer at the end of the day, walk away from your computer happy and smiling. That just isn't where I think that path goes. So it's like, hey, my two rules are never touch servers and then only build features that actually differentiate you. Don't build things that become table stakes as soon as they exist.

Yeah, that's incredibly good advice. Because I was saying earlier, like you were saying with sync, no one cares about sync once they have it. It's just taken for granted instantly, right? And there's so many features like that. Any kind of account backup system, all that, logins and password resets, there's so much stuff like that. People just expect that to be there.

and that's that's not an area where it's worth spending a ton of time to make yours like extra special or or good or anything like that like it's just just you know something people always expect to be there make it just make it work

and move on to the things that matter to you and to your users in more concrete ways. Features they can actually see, things that will differentiate your app from competitors, that kind of stuff. That's so much more important. And running backend servers really well, trust me, I can tell you from experience, I run backend servers pretty well. No one cares. I don't even care. No one cares. It's just something that is not worth your time if you can help it. Yeah.

Anyway, good luck, everybody, trying to avoid servers in this era of OpenAI API stuff. And good luck preparing all your questions for WWDC Labs. And we will talk to you in two weeks. Bye.