It's getting harder and harder for developers to find jobs and as explained in my last video, I want to cover more about how to make applications and how you could potentially monetize them rather than the skills that you might need to get a job as a software developer.
So in this video I want to cover the different types of applications that you could start making and how complex they're going to be to make. Now when I say complexity, I'm not talking about difficulty here. Obviously something that is very complex is likely to be very difficult but complexity I'm talking about the number of moving parts. So we're going to have a look starting from the lowest complexity moving up to the highest complexity and hopefully by the end of this video you'll have an idea of what sort of apps you could start making.
Offline Mobile Applications #
So let's start with the least complex first which would be offline mobile applications. So by offline I mean anything that will work on your phone without the internet. So that covers things like note taking applications, habit trackers, journaling apps and even things like photo applications where you're applying filters.
And the main reason that these are least complex is because everything is self-contained in the application. You don't need an external server, you don't need to worry about hosting it's all just in one app. You just build the app and then sell it.
Why Start with Mobile Apps #
If you've never tried selling software before, I would recommend going down the app development route mainly because there's a lot of things that are done for you. You don't need to worry about hosting. In some cases you don't need to worry about marketing because the App Store will drive some traffic to your app through search results if you set it up correctly. Monetization is also built in. Obviously there's some things you have to do but you don't have to worry about setting up your own payment platform with Stripe or paddle or something like that.
Now I'm talking here about the Apple App Store. There's also the Google App Store. I've only tried making applications for Apple. I haven't released anything properly yet so that's going to be one of my first attempts trying to make some money on the side. But from what I've read and looked at from other indie developers, generally about 80% of their revenue comes from their Apple version and only 20% from Google.
The Development Process #
At the moment I'm trying to see if I can make a mobile application. Mainly so I can learn what the process is and maybe do a video about it in the future. But I do find if you've never made a mobile application before and you've only been doing web development, the process is a bit different compared to the sort of instant gratification you get from web development.
Generally when I'm doing web development, I'll have a browser window on one side and I'll have my code editor on the other and I can instantly see what the results are as I type in my editor. With app development, it's a little bit different because generally you have to put everything on a simulator first. So it's code it, build it and then run it on the simulator, open it up, see if everything works, doesn't then go back and it's just a bit of a longer feedback loop compared to doing web development.
Tools and Requirements #
If you want to develop native iPhone applications with something like Swift, then you will need to get yourself a Mac. There might be ways to do it without a Mac, but this is how I convinced myself to buy a Mac and now about eight years later I'm finally getting around to building something.
Most of the time I'm actually coding in Z or VS code and then I'm running in Xcode. I don't particularly like Xcode as an editor, but you will need it if you want to be able to run the app in a simulator.
The Approval Process #
The other thing that's a little bit different when it comes to app development is everything has to be approved by Apple. You can run and test the applications on your phone. You just have to plug your phone into the computer and you can transfer the app across, but if you want to get some beta users testing your application then you have to still go through the Apple approval process even if it's just for the beta version and it's not public yet.
That is a bit annoying. It takes a few days, especially over the weekend to get your application approved. If it's during the week then it's maybe about 12 hours to get your application approved and sent out to the beta users but sometimes it does take longer. So there is that delay, you can't just do an update quickly and everyone gets it like you can web development. You have to wait for this approval process before the beta users can get access to the application.
So you do need to be a bit careful about what you release to your beta users because if you release a bug that means they can't use the application, then chances are you're going to have to wait 12 hours before they can actually start using it.
Alternative Frameworks #
Of course there are other frameworks you can use to create mobile apps, the things like Flutter and React Native. I haven't got any experience with those. I will have a go at doing that so I can see what the difference is and see whether the developer experience is a bit better. But either way if you want to release on the App Store or get people to test your application and you're going to have to go through some sort of approval process, you're going to have to upload your application with Xcode which probably means you need a Mac.
Monetization for Mobile Apps #
When it comes to monetization, this is one of the main benefits of actually selling an application on the App Store. You don't have to set up Stripe or Paddle or anything else. You just upload your application, set what your prices are going to be and wait for the money to come in.
The downside is I believe it does take a couple of months before you'll start seeing any money coming through. Basically Apple withhold it maybe to count for refunds and things like that. Whereas if you're selling with Stripe, then you can set up daily payouts and just get paid every day, provide you with your balances high enough.
The other downside is that Apple charge a lot for the privilege to host your application on their App Store and handle all the payments. They charge 30%, which compared to Stripe 3%, it's pretty high. Even Paddle I think charges about 5%, so 30% is huge. You can reduce that apparently by applying to the Apple Small Business Program, which will bring it down to about 15%, but you need to see if you're eligible for that in your country.
Pricing Options #
So with mobile apps, you have quite a few monetization options. You can do an upfront fee where they have to pay $199 or $399 to be able to use your app. I don't generally recommend that because people like to try an app first before they buy it, which they can't do if they have to pay up front.
The next option is to do that one-off fee, but allow them to use the application a bit first, either limit what they can do or time it or something. And at least that way they get to try the application, see where they like it, and then upgrade to the premium version, whatever that might be.
For offline mobile applications like this, I generally prefer a one-time fixed cost, especially if there is no ongoing cost for you. I have seen applications on the app store that have a monthly cost or yearly subscription, and they quite clearly have no ongoing server backend that they're having to pay for. But obviously on the other end of the scale, if you're planning on continuously improving this application, then it might make sense to have a bit of a subscription, and of course everyone loves recurring revenue.
My Own Mobile App Journey #
So as I have mentioned, I have started making my own offline mobile application, which I'll share some details in a future video. It's actually an application I made for my wife and we couldn't find anything that we particularly liked, and they all were charging a monthly subscription for something that isn't really worth it. So I'm going to have a go at selling that on the app store, and I will share my progress on here and see if it does well or not.
Offline Desktop Applications #
So next on the complexity scale is offline desktop applications. So again, these don't have a server that's going to be no running costs for you, but generally they're going to be a little bit harder to make because people expect more out of a desktop application than they do for my mobile app.
There's quite a big range of what you could build for desktop applications. If you think of everything from your text editors to your code editors, you've got video editors, but editing anything is generally going to be done offline. There's things like FTP clients or file transfer tools, anything where you don't have to provide the infrastructure and they can run it on their computer.
Cross-Platform Options #
Like mobile applications, desktop applications can be made cross-platform. You can do things like obviously electron.js or if you're using Rust, there's an iced UI package you can use as well to build applications.
Monetization for Desktop Apps #
When it comes to monetization with desktop applications, it's going to be a little harder. You can of course go down the Mac app store route and sell your application there, but generally I find that most people will set up a website and sell the application and provide a download.
Of course, that means you now have to pay for hosting your website, hosting your application for them to be able to download it and setting up your payment providers, whether it be Stripe or Paddle or Gumroad. Most people I've seen tend to go with Stripe.
The downside of Stripe is that you have to handle all of the attacks yourself, particularly the VAT if you're selling to Europe or the sales tax in America. I myself being in the UK, selling to someone in Europe means that I have to charge VAT and then I have to pay that VAT to their country. It's all a bit of a mess. Stripe do handle some of the tax collection and I think they have another paid product that will handle the remittance of the tax, but generally you have to set it all up yourself.
If you go with a payment provider like Paddle, then you don't have to worry about VAT. They will handle all of the VAT charging and remitting it to the correct countries.
Pricing Strategies #
As with mobile applications, you need to consider how you want to charge. With desktop applications, a one time fee makes sense. You could do a one time fee for a particular version and then when version two comes out, you can charge new users that fee and charge a discounted upgrade fee for existing users. I've seen quite a few people do that.
The other option I've seen is people charge a one time fee, which includes one year worth of updates. If the application updates in that time, then you get that one for free. But then after that year runs out, you then have to pay an upgrade fee if you want to get the next version.
And of course, if you wanted, you could charge a monthly subscription. Some people might prefer that if they know that they're always going to get the latest version when it comes out and you're actively developing it. So this is the route that companies like Adobe or Microsoft take to Adobe charge a monthly fee to use Photoshop, but they generally include some sort of cloud storage in that as well. Again, Microsoft 365, they charge a monthly fee to use Word and Excel even though they're completely offline applications, but they do bundle it into their one drive and give you a terabyte storage to justify the cost of charging you that much.
Updates and Distribution #
One thing you do need to consider with desktop applications, which you don't have to worry about with mobile apps, is how are users going to get updates. Unless you're selling your application via the Mac App Store, you need to provide some mechanism in your application to tell users that there's an update available.
This could just be a JSON file that sits on your website that your application calls to find out what the current version is. And then when a version is available, you point them to a download site that only they can access. Of course, then you need to worry about how do you stop people that haven't bought your application from downloading it from the update site.
Obviously, there's quite a few things to consider there, but generally offline desktop application is the next least complex thing that you could build and sell.
Applications with a Backend #
So the next up on the complexity level is applications with a backend. Now, the majority of applications that you use on your desktop or on your mobile have some form of backend that they're calling.
Now, this might just be an API that is providing information that you don't want to store in the application, but if your API is just storing some static information, if one, it could just be on a website, doesn't need to be an API. Generally, an API will be doing something that is specific to the user. So any application that you find that you have to log into, that will be logging in via an API, that API will have a database to it that's storing all the user credentials. The database will have information that is relevant to particular users in which case you need to think about authentication and authorization.
Authentication and Authorization #
When it comes to authentication and authorization in your applications, there's a lot of different options. You can do hosted routes like Auth0 and Octa. There's also things like BetterOrth or what's it Amazon, Cognito. There's one called Cloak or you could go down the route or something like Firebase or Superbase.
Database Options #
For databases, there's so many different options you could be using. There's things like Dynamo or Cosmos if you want to go down the NoSQL route or for SQL. Generally, most people use Postgres, some people use MySQL.
Hosting Considerations #
Obviously if you've got an API in a database, you need to worry about where you're going to host it. So you need to think about infrastructure. Now there's so many different options and it's a bit of a mind field and I will be covering in a future video how to host these different things.
You could go down the cloud route, host it on AWS, Azure or Google Cloud. You could go the more managed route and use something like Superbase or Versel, in which case they're still using AWS or Azure under the hood, but it hides some of that complexity so you don't need to worry about it. The other option is to go down like the Hetzner route and basically get a VM and then run all the applications yourself.
I would generally go with the more managed hosting route if you don't know what you're doing. So go with something like Versel or Superbase. They will handle all of your authentication, your database and actually hosting your application as well.
Why You Need an API #
Even if you're not planning on storing any data yourself, you likely still need an API of some sort. Say, for example, you're building some AI application, which is calling off to open AI or Claude. Unless the user is providing their own keys, you need a way of storing your key securely.
If you start via coding some AI app, you'll probably have your own AI key stored somewhere in the application, which if you release that, then everyone has access to your AI key and could start using AI for free. And you would rack up a massive massive bill. So by having an API, you have that abstraction where the user is only calling your API and they don't know what your keys are.
Web Applications #
Finally, on the most complex side of things, we've got web applications. Generally for those thinking of making an indie startup, they're going to be going down this sort of SAS web application route.
As with mobile and desktop applications, there's different levels complexity when it comes to SAS web applications. Generally, when it comes to web applications, a completely offline web application isn't a thing. The closest would probably be a static web application that just runs everything in the browser.
Static Web Applications #
So if you go back to my AI example, if you're going to build a wrapper for AI, if the user is providing their own keys, then you could potentially just have a react application that runs completely in the browser, stores everything in local storage, and then you wouldn't need to worry about users or anything else. It's everything just running locally. Obviously, you still need to work out how you're going to store these things securely for your users. You don't need to worry about anything beyond a static website that is hosting the front end.
Static applications like this are generally quite difficult to monetize. If you haven't got a way for users to log in, then you haven't got any sort of means to offer something that's worth paying for. At the end of the day, an application that just runs in the browser is basically just a static website, and the best you can do in that case is just put adverts on it.
There are some examples, though, that I've seen of applications that are mostly static, so there is an AI application that I've used before called Typing Mind. It has a login and it has some sort of storage features, but 90% of the application is all running in the browser. You provide your own AI keys, but they then cool the APIs from your browser, not from a backend service.
Full-Stack Web Applications #
In most cases, though, web applications like this are going to have a front end, they're going to have a back end and they're going to have a database. So you need all the things that I mentioned before that you need for an API, but you also need to host your front end as well.
Architecture Options #
There's a few different options for building web applications like this. You can have a static front end that's written in something like React, and then have your API like you did with the mobile app. If you've got a mobile app and a web application, then you can potentially just use the same API back end for both the mobile app and the front end, which is quite nice.
One benefit of doing it this way is that the static front end application is generally really cheap to host. You could stick it on GitHub pages or in an S3 bucket, and it will cost you pennies if anything.
Having a static front end and an API back end is quite a good option if you're mostly a back end developer. Your back end can be written in whatever language you like, whether it be .net or Ruby or something else, and then your front end can be written in something like React or Svelte, and it just calls your API back end. This way you've got this isolation, you could use something like Claude code or user template to get your front end working. Most of your focus would be on the back end.
The other option is to have a front end with a server side back end, in which case you can use something like NextJS. This is a really good option in terms of hosting again, because you can stick the front end of back end on versatile, and you don't need to worry about having that sort of separation of API and front end.
This is a good option if you want to keep your front end and back end in mostly the same language, so you can write the whole thing in JavaScript or TypeScript if you're using NextJS, or you can even go down the Blazer root if you want to use .net.
Choose the Right Stack #
The key here is to pick whichever framework or language that you're most comfortable with. I wouldn't go and pick a language that I've never used before and try and build the front end and back end with it. If you're mostly comfortable with the back end language, then do a back end API and a different language for the front end. If you can do front end in your chosen language, then do something where you can do front end and back end in both. The key is just to pick something that you know well. If you don't know it well, pick something popular so you can get AI to help you build it.
If I was going to build a new web application myself, I would probably go down the NextJS root as at least then you've got the front end and the back end in one place. This way you can stick the web application on versatile and have your Postgres database in something like SuperBase and then SuperBase will also handle all of the authentication part of it as well.
Start Simple #
The most important thing when it comes to building applications yourself is to get it built quickly and get people using it. This is why I would recommend using something like Versal or SuperBase first. At least that way you don't have to worry about infrastructure, you don't have to worry about which AWS components you're going to be using. It might cost a little more, like $25 or so and to start off with but you can always move some of your infrastructure over to these more complex things once you actually have people using your application.
Don't Over-Engineer #
Web applications vary quite a lot in complexity. I haven't covered things like messaging queues or recurring jobs. In most cases these things are scaling concerns and they're not needed when you're first starting out. Try and keep the complexity as low as possible. Worry about making something that's scalable later once you actually have customers using your product.
Obviously if what you're building requires long-winding tasks or recurring jobs you don't really have an option not to build it but if it's your first time building something like this then maybe pick something that doesn't require those things just so you can get used to building things and getting customers using them.
Monetization for SaaS #
When it comes to monetization for SaaS applications everyone's going to be looking at recurring revenue for SaaS applications because you have got that monthly hosting costs really it doesn't make sense to do anything other than a monthly cost. There's different ways of pricing your application it could be user-based or usage-based but generally you want something that is this monthly recurring revenue to cover your infrastructure costs.
For SaaS applications there's no such thing as an app store so you will have to set up payment processing yourself. Again you can use Stripe or Pad or one of the many other payment platforms to set up these sort of recurring subscriptions for you.
Additional Considerations for SaaS #
With SaaS there's a few other things you need to think about as well. If someone's going to be paying monthly for your product there's going to be some expectation that you're going to support them as well and so with every new user that joins your application there's going to be that support burden that you need to think about.
With SaaS there's also data processing regulations you need to consider so if you're storing people's data you need to conform with GDPR you also need to worry about how long you keep that data for and making sure you're always compliant.
My Recommendation: Start with Offline Apps #
This is why I generally recommend if you're going to be building something to start with you should look at offline applications first at least that way you're not storing anyone's data you don't have to worry about hosting costs and you can just work on making something and selling it and if your mobile application does well then it might continue selling obviously you'll still need to do updates to it but there's no ongoing costs for you to worry about so you can just leave it there in the background and it's effectively passive income.
If you are going to go down the SaaS route then there's obviously quite a lot of different components that you need to worry about that don't directly affect the functionality of your application you'll need to build authentication you need to worry about databases you need to worry about infrastructure and they're all going to have ongoing costs even if people aren't using your application.
Learning from Experience #
A few years ago I tried building my first SaaS application it was a recruitment application to help recruiters manage all of the different candidates for job vacancies. I had a handful of people using it but no one was willing to pay for it and in the meantime it was costing me between 50 and 100 pounds a month to host the database and all the infrastructure that went with it.
This was about seven years ago now so there we didn't have things like serverless databases that we could use so you just had to spin up a database and pay for the ongoing costs even if there weren't any people using it.
If I was to build something now I think I would just go down the route of managed infrastructure all the way. I do know AWS and Azure and I know how to write everything in Terraform doesn't mean I like doing it and it's a lot of fat that I'd rather just be spending that time building the application and getting it in front of people.
My Current Project #
As I mentioned earlier I am making my own mobile app it's something I've always wanted to do so even though I know how to make SaaS applications for me working mostly full time and building applications in my spare time I'm trying to build something that will be quick and easy and I won't have to worry about the ongoing infrastructure costs.
Once I've got the application on the App Store I will do a video about what I've built and the process of how I built it and what it was like to get it approved on the App Store and hopefully that will help any of you that are wanting to build your own mobile apps as well.
Let me know in the comments if this video is useful and if you're building anything yourself I'd love to take a look at it. Thanks, I'll see you in the next video.
Top comments (0)