This year I wrote and released Still, a mobile app for iOS and Android. Still is an app designed to help people with Anxiety and OCD relax. I thought of the idea for during the first COVID-19 lockdown of 2020, as I found myself struggling with Anxiety and figured I could make the tools I needed to help manage it, and maybe I could help others too. I built it out in late August 2020, and released it onto stores in mid-September.
Now before I get into the details of what exactly I learned, I think it’s important to preface this article with a little note:
I’m an indie developer. I work on my projects solo, with a personal budget for everything. As a company with, say, investment capital, or a large budget for your app’s release, you may find some of these things won’t line up with your experience.
On with the article! Here are 5 things I learned building Still.
1. It Takes Courage
In my spare time, I make music. Whenever you’re showing anyone anything remotely creative, it’s always possible to feel a little insecure about what you’ve done, especially if you you’ve invested emotional energy in the project. It’s never easy to share one’s intimate thoughts and feelings, no matter the medium.
I did all the design for Still, and the subject matter (Anxiety) is close to home for me. Building this mobile app after a while started to feel like I was announcing that to the world, and that’s daunting. It’s not a guarantee that people will like what you’ve done — one always fears the ‘I think it’s good, so it must be good’ delusion.
“I think it’s good, so it must be good”
It’s important to make the distinction with software, however. What you’re building isn’t a pure expression of creativity ( although in some cases, it may be much closer to that than otherwise), but a product that people are going to use.
You must be prepared to distance yourself from self-doubt, and an emotional attachment to what you create. This is extremely important —otherwise it’s all too easy to start correlating the success of your product with your notions of self-worth. On top of this, as we’ll cover later, release day isn’t your only shot at perfection & success.
2. There Are Hidden Costs Everywhere
There are obvious up-front costs associated with releasing a mobile app.
First of all, there is your development cost. Depending on whether you’re outsourcing your design or development (or both), you’re looking at a serious chunk of money to create anything non-trivial, and add a bit more if you want it done well.
I like to build stuff myself, but I’m a freelancer. In order to understand how much the project is costing me, I track my hours and calculate the total based on my usual hourly rate for clients. Now obviously this is not always 100% meaningful — thus far, I have worked on Still around my client projects and thus it doesn’t translate to missed freelancing revenue. This may not be the case for everyone, and I think it’s a worthwhile exercise to understand how much your time costs, especially for freelancers. Agency owners branching into home-grown products may find this helpful too, as it’s key to understand where you’re spending your money.
So now that you’ve built your app and you’re ready to get it onto stores, here come the hidden costs. For an individual, these are non-negligible! Here are a few of them (in USD):
- Apple Developer membership $99/year (for non-enterprise clients)
- Google Play Store account $25 (one time)
- Hosting costs for app website (depends on your use case & scale): likely ~$0–10/ month
- Total (first year): $184–1604!
And that’s ignoring any costs you may incur for a backend, this is just for the app! For apps with a backend, you can easily stray into the hundreds or thousands if you’re operating at large scale — and remember, if you’re not the one building it, you probably won’t get it for free!
3. It Can Be Tedious
Once you’ve cut your release version and built your binaries, it’s not just ‘ship it’ from there, no matter how excited you are. There are many more steps that go into releasing an app for the first time. Here are a few:
- Screenshots (for every language your app supports!)
- App Store listing metadata (also for every language)
- Legal Data / Compliance
- Getting ready for app review
- Payment info etc.
It’s long-winded, easy to get wrong (if you submit for review with incorrect metadata, the binary could be permanently rejected and you’ll have to submit another) and daunting to newcomers.
That said, there are mechanisms to improve some of this. Fastlane is collection of open-source app automation tools designed to remove a lot of the manual work associated with shipping a new mobile app for both iOS and Android. You can, for example, use it to automate screenshots for every language, for a bunch of devices, removing a long and painful part of shipping a new binary.
Still — factor in a considerable few hours-days from building your first binary to being ready even to submit for review.
On top of that, app review can take a while. Apple aim to review 90% of submissions within 48 hours, and they were very quick for me. Google Play, on the other hand, took a considerable amount longer, nearly a week. One can chalk this up to the fact that one is paying more for Apple developer membership, thus should expect higher quality service, coupled with the Google Play store receiving more submissions than Apple.
4. Timing Isn’t Everything
Back in the dotcom days, people used to rave about First Mover Advantage. Being the first to get your shiny new product (that used sleek, modern acronyms like HTTP and HTML!) in the hands of users was considered a huge advantage over competitors, and was a staple of any investment prospectus of the time.
“We’ve got a serious FMA, and we’re generating loooads of buzz.”
Not so anymore. These days, most new products are likely to have competitors already, and are looking either to innovate or just grab some market share. This changes the game completely. You don’t have to be first anymore, instead you need have the best product over the long term. Either that, or have the best marketing, see VHS vs BetaMax!
I like to think about software with the following analogy. Writing software is a bit like building a house you’ll never finish. There’ll always be an extra window you can put in, some nicer tiles for the roof, new kitchen counters, a patio, an extension, etc. In short, software is never “finished”.
While this sounds initially a little depressing, it does actually imply something amazing! My principal conclusion is: Things can always improve.
Just because your product is missing something now, it doesn’t mean that it can’t be there in a day, a week, a month or more. Consider splitting out your book of features over time, and get something out early. Better to set the bar lower, and ship great updates, frequently. The more you focus on this strategy, the sooner you can get your product out in the hands of users, and growing.
On top of that, it makes you much more reactive if something goes wrong, as it’ll be easier to ship a fix if you’re used to doing it (and you’ve set up great CI/CD tools). Just make sure whatever you ship remains high quality, and you never ship anything obviously unfinished.
Writing software is a bit like building a house you’ll never finish.
The tl;dr here is that you don’t only have one shot. You can get your product out and ship extra features, improvements and fixes incrementally. What I call “pre-release fatigue” is a real thing, and can be costly even in the short term.
5. Users (Probably) Don’t Come for Free
It’s not 2009 anymore. You can’t just drop your app on the App Store or Play Store for 99 cents and overnight become a huge success. Leading app stores, according to statista.com, have millions of available apps. Every one of these is something you’re fighting with for mobile users’ attention. You’ve got to be creative, or a marketing genius to stand out against the competition.
Indeed, there are “cost-free” ways of spreading the news about your app. Content aggregation sites like Reddit, social media marketing, even word of mouth can be extremely effective. But the reality is that they aren’t cost-free. Remember earlier, when we talked about time investment as an implied cost? Guess what — all of those strategies demand a large amount of effort, or at the very least a considerable time investment in order to produce results. Sure, if you have that time, great. But if you’re like me, that’s harder to accomplish if you’re only just finding time for development of the product itself.
Alternatively, if you’re unable or unwilling to try the above strategies, there’s always traditional advertising. It’s expensive, but it works. Nothing gets people engaged like your app appearing at the top of their searches on app stores, in ads in other apps and in their Instagram feed. But rather than incurring an implied cost, you’ll directly be forking over those $$.
It was a long and interesting journey releasing my first mobile app. I’m continuously working to improve Still and provide great tools to help anxious people. If you’re interested in learning more about Still, here’s a link.
In any case, I hope this article helps you to avoid the pitfalls, understand the cost implications of your release goals, and have an easier time understanding how to get some users!
Thanks for reading!