What did I learn after publishing my own mobile app?
This post doesn’t contain a solution to some programming problem, but describes my experience with developing my own mobile app. It doesn’t contain overly technical terms, just loose thoughts on some of the challenges an independent app developer must face.
Idea
Two years ago, the idea of creating my own serious mobile application and publishing it under my own name was born in my head. While I had a lot of previous experience publishing apps for the then still (somewhat) popular Windows Phone and Windows Mobile, at the time I thought of creating a product that would eventually start earning for itself.
As I am a man who likes order, for some time I was looking for a tool that would allow me to manage my personal budget. For a long time I used Microsoft Access, various mobile applications, first on Android and later on iOS, but I could not find such a tool that would meet all my expectations. Hence came the idea to create such an application on my own. From the idea to implementation, from the first simple version to an extensive tool, my application was created, and in this post I would like to share my path, problems and ways to solve them that I encountered while working on my own product.
All of my thoughts may be obvious to someone, but looking from the perspective of a programmer who relied mainly on the development of technical and soft skills while working for clients, these are very relevant and important discoveries 😃.
Requirements
At the very beginning, before starting the implementation, I made some assumptions that I would like to see included in the project. Here they are:
- The application was to be developed for iOS, but in the perspective of further development I would also like to add support for Android.
- The app should be convenient to use, aesthetically pleasing and standards-compliant.
- And most importantly: the app data would be owned by the user. Full privacy, no data trackers.
As I am a developer of cross-platform solutions in React Native, my choice fell on this particular technology. Since, according to the last of the above, the data should be owned by the user, the need for a backend page and a server-side database was dropped. Instead, it was necessary to keep the data on the application side.
Business model and its verification
An important point in the development of the application became the preparation of a monetization solution. We all know how annoying ads or pop-up modals with an incentive to buy the premium version can be. Learning from these experiences, I wanted to make the app work in a form where any user can try to use its features, without constant reminders to buy a subscription, but at the same time, in case the app is right for them, get access to more features and skip the limitations in the already existing ones.
The first idea was to introduce subscriptions. And while business-wise this is quite a good solution (the App Store, after a year of continuous subscription, charges a lower fees on subsequent ones, i.e. instead of 30% “only” 15%), I was concerned that it would not be a good solution for promoting the app in its initial stages after publication. After thinking about it, however, I came to the conclusion that a better solution with my small scale project (at least to start with) would be to add a one-time payment for additional features of the app. A small amount that allows you to use the app forever within a single AppStore account.
What did I learn?
So far I think this is a better solution, more fair to users. Without adding a subscription test period (which the user may forget to turn off), users can get to know the application, and when it is satisfactory to them, then they can buy access to the rest of the features for a small price, but in a one-time way, without a subscription.
Publication and first feedback
After its initial publication in the AppStore, I had mixed feelings. Although the app met my objectives, and I used it on a daily basis to run my own household budget, for the first users it contained many significant problems.
In my professional work, where I was in charge of developing applications for clients, the perspective of contacting the user, collecting feedback looks completely different. In a situation where we ourselves are the person responsible for the implementation of the application, contact with users, marketing, we realize that our vision of the product is so different from the needs of the users. With the assumptions, I told myself that I would create a tool that I myself would enjoy using (it would be customized under me), but at the same time under other users. As you can read below, this was not a good approach 😊.
What did I learn?
I have adopted the assumption that “The application is to be such that it me is comfortable to use it”. When developing a product to be used by others, verification of one’s own assumptions and ideas should be the core. I have experienced this many times, that something that seemed intuitive and noteworthy to me, for other users was no longer so.
Verification of ideas and evolution
After the first feedback, there was a time of project development. Working on the application, but also on my own beliefs. The development of functionality, went forward together with the adjustment of the interface and its readability. I tried to make the whole thing look more professional.
Let’s see it in the example of the app’s logo. On the left is the logo created in the first phase of the project, and on the right is how it looks now:
You can see the difference — the first one done quickly in Gimp (xD), and the second more professionally in Illustrator.
The app itself has undergone a significant interface change:
For functionality, the approach has also been changed. After reviewing ideas, previously implemented functionalities were changed and new ones were added.
What did I learn?
When working on an application, you need to listen to the feedback of others, learn, observe and revise ideas.
Information is important
Describing functionality was also an important change. There were a lot of problems related to the lack of clear messages after or before a certain action was performed. The purpose of some functions remained a mystery. It became necessary to customise the interface and add messages in such a way that the user would intuitively perceive certain functionalities, and if they didn’t, then they would be able to read an explanation of them.
What did I learn?
Something that for some will be understandable, for others it will not be, and they will need a more detailed explanation.
Necessary investments
When promoting apps, App Store ads are important. They allow you to significantly increase app downloads and allow you to reach more users. Everything actually depends on the budget. Myself, due to the lack of revenue in the initial post-publication phase, I decided rather little support with ads, relying mainly on other media (such as posts on social groups), and the publication of apps on a site that allows you to show your own app for free.
While this is probably not a good approach, since in the first stages after publishing my own app there is a lack of revenue for this type of marketing action, and my skills in this area are small at best, I opted for slow development, however geared more towards establishing communication with users and developing based on their suggestions and feedback.
What did I learn?
Here definitely, life verified my approach to the product. I think if there had been a person I could rely on for marketing, its development would have looked very different. For me as a programmer, with no skills in marketing or direct customer service, it was a new, interesting and challenging experience. I also appreciated much more the people who deal with this on a daily basis in their work.
Summary
In working on my own application, I learned a lot. I also know that I made a lot of mistakes and probably still do. However, it seems to me that it is important to learn some lessons from them, to come to some conclusions. This article is just a collection of my own thoughts. Often, as programmers, we forget how important it is, after building an application, to direct it properly in terms of marketing, collecting user feedback, verifying ideas, etc.
The entire article is about my original app ConstCash — an app designed for personal budget management. The app is currently available for iOS in iPhone and iPad versions. More information about the app can be found at https://constcash.com/ or in the AppStore.
