How I Decide My Apps' Versions and Prices

Testing an app usually takes me much longer than writing it. I can get a concept working quickly, then spend a lot of time changing things that seemed fine while I was coding. Even after all that, the first users often find something I missed.

I'm a solo developer. I write my apps, and before release I do all the testing myself, without paid help. I'm good at finding bugs. I find them in other people's software too, sometimes everywhere I look. Some turn out to be security vulnerabilities, and reporting them through HackerOne has occasionally earned me money.

I type fast and often make several concepts while working on an idea. Once I have something working, I start testing it properly. That's usually when I decide to change a lot of it.

Something can work exactly as I intended and still feel wrong when I use it. It might be too slow, or I might dislike how the interface works. I'm a good coder, but I'm not a designer, so I'm still learning how to make a nice UI.

I change things, test again, and often change them again. I keep doing that until I'm happy with how fast the app is, how it feels, and how it looks. The version people finally get may be quite different from the first concept I made.

When I release it, I've tested it as well as I can. But other people use it differently. They find bugs I didn't find and things I could improve that I hadn't noticed. From then on, their reports become part of the testing too.

Version 1.0

I usually keep my 1.0.* apps cheap. If someone pays a high price, I think they have every reason to expect a well-polished app. I don't want them to buy mine, find a problem, and feel they paid too much for something that wasn't good enough.

I'm not choosing a low price to get more testers. I've already spent a lot of time testing before release. I just know that there may still be problems, and a small price feels fairer while I'm finding and fixing them. Of course, a bug is still frustrating even if the app was cheap.

Sometimes someone finds a bug, leaves one star, refunds the app, and is gone forever. I'm lucky if they explain why. At least then I have a chance to understand what happened and fix it. A rating alone doesn't give me much to work with.

It can feel unfair after all the time I spent testing, especially when I could have fixed the problem if they'd contacted me. Still, when a review tells me what went wrong, it helps improve the app. Sometimes it feels like I'm paying for those fixes with one-star reviews.

More often, people contact me and describe the issue. Those reports are a high priority for me, and I usually fix the problem over the next few days. I want to understand what broke and make sure it's fixed. During this period, I may release updates every day.

Sometimes the person reporting a bug spends a lot of time helping me figure it out. They answer my questions, send screenshots or videos, and try things I ask them to try. Some have even let me control their computer through TeamViewer, or joined me on a video call so we could look at the problem together.

I really enjoy meeting new people this way. I also have huge respect for the time they spend helping me. I'm always happy to share free licenses for my other apps with them.

While 1.0.* still has some bugs, I usually get a lot of useful feedback about the app itself. People explain what they would like it to do and how they think it could be improved. I add a lot of features from those conversations, even while I'm still fixing the early bugs.

App Trust Preview is a good example. I originally made it for my own needs because there were a few things I wanted that I couldn't get from Apparency. Then people in the community requested lots of improvements, and I implemented all of them. The app ended up doing much more than I originally planned.

To me, those additions made it the most powerful static app analysis tool. It provides human readable signals that help you understand what an app can do before you launch it. A project I started to solve a few of my own problems became much more useful because people took the time to tell me what they wanted.

Version 1.1 and later

Once I've fixed the reported bugs and neither I nor the users are finding more, I can spend more time on new features. That doesn't mean another bug can never appear. It means the problems I know about have been dealt with, and bug fixes no longer take up so much of my time.

This is when I move to 1.1.*, and I may increase the price. By then, the app has had more testing from actual use, and I'm adding more things it can do.

For a bug fix, I increase the last number, such as 1.0.0 to 1.0.1. For a small feature, I increase the middle number, such as 1.0.3 to 1.1.0. A redesign or a major feature gets a new first number, such as 1.4.2 to 2.0.0.

I still release updates when bugs are reported. I also make them when I have a feature idea I'm excited about. Usually, updates at this stage come every few weeks or once a month.

Version 2

By 2.*.*, the app is usually stable enough that I've settled on its final price. I've had time to see how people use it, fix what they found, and make bigger improvements.

I keep updating it when someone finds a bug or I have a new idea. Sometimes a new OS release means I need to make adjustments too. Updates may now be one to six months apart, depending on what needs doing.

I still care just as much about fixing bugs. There are simply fewer reports coming in, so I don't need to release fixes every day. I feel more comfortable with the price because I've seen the app work for people besides myself.

If I sell an app as a one-time purchase, it stays yours forever. You don't have to buy it again when I release a new major version. A higher price only applies to new purchases.

I hate it when an app is sold as a one-time purchase, then re-released as a separate paid app that existing users have to buy again to get the improvements. To me, those re-releases are hidden subscriptions.

PCalc is a good example of how this can work. In my interview with its developer James Thomson, he said he had been maintaining it for 34 years and that it had provided a good income and helped pay the bills. He also pointed out that someone could have bought a copy on the first day of the App Store in 2008 and paid nothing more for nearly twenty years.

To me, that's proof that a developer can earn enough to keep maintaining an app for many years through one-time purchases. James dislikes subscriptions for utilities like PCalc and wants to keep this model as long as new users keep buying copies.

Even if you bought my app at 1.0 for a very small price, you still own it when it becomes a much more stable 2.0 with lots of new features. You paid for the app, and you get the improvements as I make them.