That’s not a typo. The paid version of the HttpWatch app really costs $ 99.99. We’ve had some great feedback about the app but there’s been a fair amount of surprise and disbelief that we would attempt to sell an app for 100x more than Angry Birds:
“I like this app and what it offers; providing waterfalls charts and webpage testing tools on iOS but £70 for the professional version is way out most people’s budget. Even my company won’t pay for it at that price even though we’re Sales Engineers all about CDN & website acceleration”
“Its a perfect app, BUTTTT the profissional version is outrageously expensive! I always buy the apps that I like, but this value is prohibitively expensive! Unfeasible!”
“$100+ for pro is stupidly expensive though. I would have dropped maybe $10 on it but not $100…”
So why don’t we just drop the price to a few dollars and make everyone happy? Here are some of the reasons why.
We stay in business by developing software and selling it at a profit. We’re not looking to sell advertising, get venture capital, build market share or sell the company. Revenue from the software we sell has to pay for salaries, equipment, software, web site hosting and all the other expenses that are incurred when developing and selling software.
Ultimately, everything we do has to pay for itself one way or another. Our app is priced to allow us to recoup our original app development costs and cover future upgrades and bug fixes.
Apple takes a hefty 30% margin on every app store transaction. It doesn’t matter who you are - every app developer has the 30% deducted from their revenue.
Therefore each sale of our app yields about $ 70 or £ 40 depending on slight pricing variations in each country’s app store.
It’s unreasonable to expect narrow market apps to receive the development attention they deserve if they sell for just a few dollars. The app store is littered with great apps that have never been updated for the iPhone 5 screen size or iOS 7 because they don’t generate enough revenue to make it worthwhile.
In the past few years there’s been a race to the bottom with even low price paid apps pushed out by free apps that have in-app purchases. There’s a general expectation that apps should always be just a few dollars or free. We often hear that if we dropped the price of the app to under $ 10 there would be a massive increase in sales leading to an increase in revenue.
To test this out we ran some pricing experiments. First dropping the price to $ 9.99 and then $ 19.99 to compare the sales volume and revenues to pricing it at $ 99.99. There was a significant increase in sales volume of nearly 500% with the $ 9.99 price:
Interestingly, dropping the price to $ 19.99 seemed to make no difference to the number of sales.
However, the 90% price drop led to revenues dropping over 50% at $ 9.99 compared to the $ 99.99 pricing.
For software developers the major downside of the app store is that there is no mechanism for offering upgrades or maintenance to existing app users at a reduced rate compared to the price of a new app.
For paid apps you really only get one chance to get revenue from a customer unless you create a whole new app (e.g. like Rovio did with Angry Birds Star Wars and Angry Seasons). Creating a whole new technical app at regular intervals doesn’t make sense as so much of the functionality would be similar and it would alienate existing users who would have to pay the full app price to ‘upgrade’.
Charging a relatively high initial price for the app means that we can justify its continued maintenance in the face of OS and device changes as well as adding new features.
Talking to customers to get feedback, provide support and discuss ideas for new features has a cost.
A good programmer in the UK costs about $ 40 an hour. If an app sells for $ 10 that only pays for about ten minutes of a programmer’s time. Therefore, spending more than ten minutes interacting with a customer who bought a $ 10 app effectively results in a loss on that app sale.
HttpWatch can now be used in 64-bit versions of IE and fully supports Enhanced Protected Mode (EPM) on Windows 8 and 8.1:
The automation interface is now available in 64-bit, as well as 32-bit, providing improved performance in 64-bit automation clients.
HttpWatch also includes a 64-bit version of the HttpWatch Studio log file viewer that can load larger files and filter data more quickly.
The Properties pane now displays the browser mode (e.g. EPM), user name and Windows architecture (e.g. x86 or x64):
New Page ID, Device Name and User Name fields are available in the CSV output:
SSL handshake timings are now displayed in Firefox:
and in-depth information about the SSL protocol used by each connection:
We’ve also made some other SSL related improvements that are available in the Firefox/IE plugins and the HttpWatch Studio log file viewer. The first is that SSL information can now be added as columns in the main request grid:
There’s also a new warning that can be used to highlight HTTPS connections that have potential vulnerabilities: