Tag Archives: download

Is desktop software dead?

desktop vs webIt’s rare that I chat to other software developers without someone asking me when I am going to do a web version of my seating planner software. Because the market for desktop is dead, right? SAAS apps is where all the action is!

I think the web is a great platform for some products, not so much for others. Let’s look at the advantages of web apps over desktop apps.

Web advantage 1: No installation

You can access a web app from any device that has a browser. No need to install. There is no doubt this is a major convenience. However most desktop utilities can be downloaded and installed in 1-2 minutes with a decent broadband connection. Also you don’t have to keep logging in to most desktop apps, once they are installed.

Web advantage 2: No upgrades

End-users are always using the latest version. This is definitely an advantage for technical support. But it does take away some choice from the user. Perhaps they weren’t ready to upgrade or preferred the old version?

Web advantage 3: Better user insights

You can analyse how users are using your software. This allows you to improve usability and send out tailored lifecycle emails. It is possible to gather similar information for desktop software, but it involves a lot of extra work.

Web advantage 4: Distributed architecture

If you are writing web apps, you get a distributed architecture for free. No need to do socket programming.

Web advantage 5: Less piracy

Cracks and keygens are a fact of life for desktop software vendors. It is easier to protect against piracy with a web app.

Web advantage 6: Cross platform

In theory web apps are cross-platform. Write them once and they can run on any device with a browser. But browser compatibility issues mean it isn’t that easy in practice, especially if you are still forced to support the dreaded IE6. Also there are solutions (such as Qt) that allow you to deploy to multiple desktop devices from a single code base.

Web advantage 7: Subscriptions

Web apps lend themselves to subscription based payment. This is great because you get a more predictable monthly income and potentially get more money from each customer over the lifetime of the product.

So what about the advantages of desktop apps over web apps?

Desktop advantage 1: Responsiveness

Native apps are more responsive than web apps, partly due to lower level access to the machine and partly due to not having to talk to a remote server. However this advantage is eroding as bandwidth and JavaScript performance improves and more work is carried out by the client in web apps (e.g. using Ajax).

Desktop advantage 2: Reduced hosting costs

The costs of hosting a website for a desktop app is minimal. Typically you just need to serve a few pages and a download file to each visitor. They then won’t need to come back until there is an upgrade. But hosting costs can be significant for a web app, particularly if the app requires large amounts of bandwidth or compute power.

Desktop advantage 3: Better access to hardware

Desktop apps can make better use of the hardware available. For example, you can generally do printing a lot better from a desktop app.

Desktop advantage 4: Better development tools

The old joke is that JavaScript is to Java as the Taj Mahal curry restaurant is to the Taj Mahal. As a C++ developer I am used to working with a fully fledged IDE, debugger, profiler, static analyser and runtime coverage analyser. I tried some JavaScript development recently. Ugh. The development tools seemed very primitive and  JavaScript is a language so hideous that surely even it’s mother couldn’t love it. No classes, no strong typing, no templates and broken scoping. However frameworks such as jQuery have made JavaScript much more accessible over recent years.

Desktop advantage 5: Psychological

Many people feel that anything web-based should be free. Psychologically customers seem more ready to pay for desktop software. Perhaps they feel a greater sense of ownership. This perception is gradually changing for B2B, but I think it is still prevalent for B2C.

Desktop advantage 6: Privacy

Many customers don’t feel confident storing important and confidential information on third-party servers.

Desktop advantage 7: Availability

You can’t use a web app unless the server is up and you have an Internet connection. A desktop app installed on your local machine is always available. You can continue to use it, even if the vendor goes out of business.

Desktop advantage 8: Up-front payment

Desktop apps lend themselves to a single, up-front payment. This is great because you get all the money straight away, improving your cash flow.

So I have come up with similar number of advantages for web apps and for desktop apps. Which is better? It depends, of course. For my particular application, I think a desktop app still has significant advantages:

  • My software can render and zoom in and out of large floor plans better than my web based competitors.
  • I use a genetic algorithm to assign guests to seats. It makes more sense to use under-utilised desktop CPUs for this, rather than me having to pay for a beefy compute server. The thought of writing a genetic algorithm in JavaScript is too awful to contemplate (although Atwood’s law dictates that someone will, if they haven’t already).
  • I can do printing better than my web-based competitors.
  • Most of my web-based competitors seem very feature-poor. I am sure that is at least partly due to poor tooling for web development compared to desktop development.
  • Most of my web-based competitors give their product away for free in the hope of making some money back on ads. I charge for mine.
  • Seating plans can contain sensitive information, particularly for events with celebrities, royalty and heads of state. Some of my customers don’t want this information transmitted to and stored on third-party servers.
  • If my server goes down then I lose sales. But my customers can continue to use my software. Imagine if they were dependent on my server and it went down (or I went out of business) the day before their big event. It brings me out in a cold sweat to think about it.

But other products are a better fit for the web. If I was writing a collaborative CRUD app, I would almost certainly do it as a web app. I have recently been working on a couple of new products. One is a web app and the other is a desktop app. Horses for courses.

A lot of the money I have spent on software over the last few years has been for desktop software. When I had to choose bookkeeping software, I chose a desktop package because I didn’t want to:

  • pay every month
  • store sensitive financial information on a third-party server
  • risk losing all my data if the vendor went out of business

If I look through the list of useful tools and services on this site I see that 51 of them are web-based and 35 are desktop based. Peldi of Balsamiq reported in 2009 that 77% of their revenue comes from the desktop versions of their software. I asked him if that had changed much and he was kind enough to send me the following graph (myBalsamiq is the web version). You can see that it is still nearly 70% 4 years later.

desktop vs web

The line between desktop and web apps is also becoming more blurred. Many desktop apps now use web protocols and embed web browsers. For example, the Qt toolkit allows you to easily create applications that are hybrids of desktop and web. It is also possible to sell a web app that companies host on their own servers. This adds some of the advantages and disadvantages of a desktop app compared to a web app installed on the vendor’s server (SAAS). Perhaps desktop and web apps will converge to the point where there the whole desktop vs web debate becomes meaningless.

So I think reports of the death of desktop software have been greatly exaggerated. There is no doubt that long-term trends ( e.g. increasing bandwidth and attitude to paying for web apps, for B2B at least) have been changing the balance in favour of web apps for some types of product. Particular those where collaboration is more important than graphics or computer power. But I think there will continue to be plenty of markets where a desktop app is a better choice than a web app for the foreseeable future. In the final analysis, customers care a lot more about how well your software solves their problem, than how it happens to be deployed (if they even understand the difference).

Farewell to software on CD?

I currently offer a CD as an optional extra when customers buy my wedding table plan software. I have put stamps on so many CD envelopes that I might instinctively lick the Queen’s face if I ever met her. The graph below shows the % of sales that have included a CD over time.

% CD sales

The overall trend is hard to miss. Some factors have varied over that time:

  • I have stopped CD sales for periods of a few weeks at a time, e.g. near a new release.
  • I have emphasized CDs less over time on my purchase page.

But I don’t think these have had much effect on the general trend. Download speeds are always increasing and customers are getting used to buying downloads instead of physical media. Anyone with a broadband connection can now download PerfectTablePlan in a minute or two. The demise of CDs is hardly ground breaking  news, but I thought it might be worthwhile to show some real data.

I won’t really miss CDs. They are an extra hassle to organize and the profit margins are slim and decreasing. I didn’t want to use the ugly looking CDs in a cardboard mailer that print-on-demand CD companies offer. I didn’t really feel it reflected well on the quality of my software. Particularly in the wedding market, where aesthetics are important. Instead I send a full colour silk screen printed CD, in a DVD box with a professionally designed, full colour wrap and insert.

I order the CDs and packaging in batches of a thousand and burn and post them as required. I have managed to delegate quite a bit of this to a family member. But it is still a fair amount of hassle. CDs go missing in the post or get eaten by dogs. Also the UK post office recently hiked the cost of sending a CD + DVD case in a Jiffy bag by airmail from £2.10 to £3.86. A monstrous overnight price increase of 84%. But I don’t feel I can increase the CD price much above the current £7/$10 when you can buy game and film DVDs for less in the supermarket. The only plus side of CDs is that my data shows that customers that order a CD are 3 times less likely to ask for a refund (my terms stipulate that they have to return the CD). Given that refund requests are low, this isn’t a huge advantage. Also (repeat after me) correlation does not imply causation.

I might run an A/B test to see if removing CDs from the purchase page makes any difference. But, given that only around 3% of customers are now buying a CD, I can’t see it making much difference. If I was starting a new product now, I don’t think I would even bother to offer a CD option, unless the download size was huge.

Am I the only one still sending out CDs?

What type of free trial should I offer for my software?

Once upon a time, the idea that you would allow people to try your software before they bought it was revolutionary. But now, thanks to the shareware movement and the ease with which software can be downloaded from the Internet, free trials are the norm for most types of off-the-shelf software. Prospective customers no longer have to rely on reviews of questionable independence or reading the packaging in a shop. They can try the software for themselves before making any commitment. This has been overwhelmingly a good thing for software users. It has also been a boon for vendors of good software.

When I surveyed 92 small software product vendors in 2009, 100% of them offered a free trial.

Eric Sink says:

Every small ISV today should give its customers an opportunity to try before they buy. It is officially now absurd to do otherwise. Customers will come to your Web site and expect to find a demo download.

And that was in 2004.

So, for most software products, the question isn’t – should I have a free trial? The questions is – what sort of free trial should I have? As with everything related to marketing, it depends. There are many different approaches. Below I describe some of the more common ones.


Typically this takes the form of a fixed number of contiguous days of free and unrestricted use. The software then stops working  and you need to buy a licence to continue using it. The time period is often 30 days. As you can see in the pie chart above, this was the most common type of trial in my survey.

The advantage of this approach is that it allows the user to try the full functionality of the software. But it does have a number of issues:

  • The trial might expire before they have finished their evaluation.
  • It isn’t suitable for software that might only be needed for a limited time. For example, a 30 day time-limited trial wouldn’t be a good idea for my wedding seating arrangement software as a wedding is a one-off event (we hope), and people could just start the trial 30 days before their wedding.
  • You have to find some way to hide the data about the date the trial starts.
  • It is relatively easy to circumvent. Even if you hide the install date well and check for changes to the system clock a potential customer can just keep reinstalling the software inside a new virtual machine each time the trial expires.
  • Cookie expiration is an problem. For example, Google Adwords conversion tracking cookies only last a maximum of 30 days. So Adwords conversion tracking won’t count a sale on day 31, which is probably where most of your sales will happen with a 30 day trial.
  • As most sales will only happen after your trial expires, you will have to wait longer to get your money.

I have sometimes downloaded software, started to evaluate it, got distracted and then returned only to find the trial has timed out. Very frustrating and unlikely to result in a sale. So I am generally not a fan of fixed duration trials. There are a couple of ways you can try to work around this issue:

  • Only limit the amount of time they are actually actively using the software. For example, allow them 8 hours of total active usage. This shouldn’t be too hard to program. For example, stop the timer if there hasn’t been a key press or mouse click event in 2 minutes.
  • Allow them to request an extension. Then at least you have got their email address and can follow them up.


In this approach you limit the number of times a certain action can be performed. For example the number of pages they can print or the number of times they can start the software. This avoids the issue of a time-limited trial which expires before the user has finished their evaluation.


In this approach the trial disables an important function of the software, for example printing or saving.  The problem is that a user won’t know if this feature works properly until they buy the full version. This may put some people off.

It has the advantage that you can ship a separate trial version with features missing completely from the executable, which makes life a little harder for crackers (note that they can still get hold of the non-trial version to crack if they want to, e.g. with a stolen credit card number). But it also makes life harder for customers, as they have to install the software a second time after purchase. Personally I care more about making life easy for my paying customers.


A capacity-limited trial restricts the amount of data that can be entered. For example, a password manager might only allow you to enter 50 passwords into the trial version. This approach can be problematic when performance is important. For example, if you limit a database trial to one thousand records, how can the user test whether the search performance is adequate for a database with a million records?


Many products exist purely to produce some form of physical or electronic output, for example image editors and label printers. Adding a watermark, or altering the output in some other way, can be an effective way to limit a trial. But you need to make sure that the modification to the output can’t easily be removed or worked around (e.g. using screen capture). You also need to be sure the user doesn’t think the modifications in the output are due to a bug in the software.


Nagware allows you to use the software without restrictions, but ‘nags’ you periodically to pay for it. Usually this takes the form of a window that pops up when you start or exit the software. But I once used some software that also nagged you in audio. A woman’s voice with a heavy Scottish accent no less. It got uninstalled very quickly! Nagware isn’t very effective in my experience. I never did buy WinZip. Did you? After a while you just click the ‘continue’ button without thinking about it. Little tricks, like moving the ‘continue’ button or greying out for a few seconds are just annoying. And annoying people doesn’t seem like a great start to a business relationship.

No trial

Some software has no trial, just a money back guarantee. If your software is an enterprise system that takes significant effort to configure, then this is entirely understandable. But if it is off-the-shelf, downloadable software, what are you trying to hide? On the plus side it avoids the issue of people downloading software and then never getting around to trying it. My own stats show that only some 40% of people who start a download of my software actually install and run it. Also many people won’t ask for their money back even if they don’t like your product. So you might get sales to people who wouldn’t have purchased with a trial. But do you really want these people as customers? Personally I am unlikely to buy a software with no trial, unless there is no real alternative. I assume you won’t let me try your software because it isn’t very good. I’m sure many other people feel the same way.

Hybrid trial

Hybrids of the above approaches are also possible. For example, the trial of my wedding seating arrangement software doesn’t allow you to save, print or export plans with more than 30 guests – a hybrid of the capacity-limited and feature-limited approaches. I figure that 30 guests is enough to show what the product does, but not enough to be useful for most events. Also no-one is likely to pay for event planning software for an event with 30 or fewer guests.


A good trial is a balancing act. You need to give prospective customers enough to show them your software could solve their problem, but not enough to actually solve their problem. But if you are too restrictive they might go to a competitor with a more relaxed trial policy. It can be tough to get the balance right or to know whether a different approach would get better results.

Obviously, the best type of trial depends very much on your product. If it is a product that is likely to be used a lot and  is going to increase in value as it is used, then you might be best offering a generous time-limited or usage-limited trial. But if it is a product that is only needed for a one-off task or a limited period of time, then a feature-limited, capacity-limited or output-limited trial probably makes more sense.

For example, most consumers will (unless they are very unlucky) only want to use disk recovery software once. So it wouldn’t make sense to offer a 30 day free trial. It would probably make more sense to offer a feature-limited trial that allows them to see what data could be recovered, but not actually allow them to do the recovery until they pay up. But if you are selling to professional disk recoverers, then a time or usage-limited trial might be appropriate.

I asked  Craig Peterson of the Beyond Compare file comparison tool about their very generous trial policy (30 non-contiguous days of use) in an interview and he said:

That goes back to competing with all the other products out there.  If someone installs two programs to evaluate, and then doesn’t have a chance to really try them out until a month later, the one that works is more likely to get the sale.  It also makes it more likely that potential customers will learn the application and start relying on it, so when it does come time to pay they’re less likely to throw out that investment and switch to another tool.

Data comparing different types of trial is hard to come by:

  • My 2009 survey didn’t show any clear difference in mean conversion rate between time and feature-limited trials (there wasn’t enough data for usage-limited trials to be worth counting):

The nagware vs feature-limited result is fairly conclusive. But, apart from that, there doesn’t seem to be much hard data to go on. Even if there was more data, it wouldn’t necessarily apply for different products in different markets. So, unless you want to program multiple types of trial and run lots of split tests (trial and error?),  you are going to have to ‘go with your gut’. It is tempting to pick the same trial model as your competitors. But remember that part of successful marketing is being different.

So there are no easy answers. But don’t just choose a 30 day time-limited trial because that is what everyone else is doing. Have a think about what fits best with your product, market and customers. Be creative.

The truth about conversion ratios for downloadable software

conversion funnel?Overview

An anonymous survey of software vendors shows that the average sale to visit ratio is very close to the much quoted “industry average” of 1%. However the data shows large variations between products and across different sectors (e.g. Windows vs Mac OS X).

The data

The data set comprises 92 valid survey responses to an 8 question survey in April 2009. The survey was advertised through a request on this blog, posts on  BOS, ASP, MACSB, OISV and BOSnetwork forums and emails to the author’s contacts. The results are inevitably biased towards small software vendors, due to the places where the survey was advertised. As the survey was anonymous it is impossible to verify the accuracy of the data. However it is unlikely that many vendors would have completed a survey that wasn’t anonymous.

The survey consisted of 3 compulsory questions (unique visits, downloads and sales over a given timeframe) and 5 optional questions (the time frame of the data, primary market, primary OS, licence price and trial type). One record had 0 visits (an iPod app), another had 0 downloads (presumably a web app) and a few had numbers that I didn’t consider statistically valid for some purposes (e.g. <500 visits per month or <3 sales transactions per month).  I did the best I could with the data available, ignoring obvious outliers in some cases.

The data set comprises a total of:

  • 8.1 million unique website visits
  • 2.2 million downloads
  • 110 thousand sales transactions

Where a time frame for the results was given it is possible to work out the range of visitors, downloads and sales per month.




Interestingly the distribution of monthly visits, downloads and sales across the different products all follow the Pareto 80:20 power law quite closely:

  • 22% of the products account for 80% of the visits
  • 21% of the products account for 80% of the downloads
  • 19% of the products account for 80% of the sales

This gives me some faith that the data is reasonably accurate and representative of the industry as a whole.

The data is broken down by OS, market, price and trial type as follows:






The average (mean) ratio of downloads:visits across all products is 28%. 50% of products are in the range 12.1% to 35.3%.


I am surprised at how high the average ratio is. This could partly be due to products that receive a high percentage of downloads from download sites, without the downloader ever visiting the product site. Conversely sites where visitors make frequent returns after purchase (e.g. to read forums) will have a lower downloads:visits ratio.

The average ratio of sales:downloads across all products is 4.5%. 50% of products are in the range 1.3% to 6.4%.


The average sales:downloads ratio is noticeably lower than the average downloads:visits ratio. The sales:downloads ratio is noticeably skewed on the right of the graph – a sales:downloads ratio >20% seems very high.

The (logarithmic) scatter plots below show that the downloads:sales ratio varies a lot more than visits:downloads ratio.


metrics_downloads_vs_salesThe average (mean) sales:visits ratio of all products is 1.16%[1]. However one of the product ratios is an obvious outlier at 13.94% (see below). With this outlier removed the average sales:visits conversion ratio across all the products is 0.99%. 50% of products are in the range 0.28% to 1.39%.


0.99% is suspiciously close to the mythical ‘industry average’ of 1%. But I haven’t (consciously) massaged the results to get this figure.

You can work out how you compare to this data set using the red (cumulative) graph in the histogram below. For example, if your product sales:visits ratio is 1.5%, then it is higher than approximately 80% of the products in the data set.


We can also look at how the ratios vary across sectors. Surprisingly the average Mac product conversion ratio is more than 4 times the Windows product conversion ratio.

metrics_sale_visit_ratio_by_os1Even if we try to compare like for like, and only compare consumer products selling for <= $50, the ratios are still 2.27% for Mac and 0.51% for Windows. Possible reasons for this large disparity include:

  • Mac owners more ready to spend money.
  • There is less competition in the Mac software market.
  • Mac vendors have a higher percentage of purchasers  who never visit their site due to higher quality of Mac download sites.
  • It is a statistical blip (there are a lot less Mac products in the survey).

My own experience with selling a cross-platform product (Perfect Table Plan) on Windows and Mac OS X is that the Mac sales:visits ratio is approximately double that for Windows.

The sales:visits ratio is similar for business and consumer products, with developer products lagging behind. However there are too few developer products in the data set to draw any real conclusions.

metrics_sale_visit_ratio_by_market1The sales:visits ratio does vary across the price range. However there are too few products with price >$50 in the data set to draw any real conclusions.

metrics_sale_visit_ratio_by_price2The sales:visits ratio does not seem to vary significantly by trial type. There were insufficient ‘number of use’ trial products to include them.



One has to be careful about drawing conclusions from a relatively small and unverifiable data set. However the results certainly seem to support the much-quoted “industry standard” sales:visits conversion ratio of 1%. But there are huge variations between products.

The fact that the sales:downloads ratio is both lower on average and more variable than the downloads:visitors ratio implies that getting people to download is the easy bit and converting the download to a sale is a tougher challenge.

The average sales:visits conversion ratio is noticeably higher for Mac OS X products than Windows products. This is supported by anecdotal evidence and the author’s own experience with a cross-platform product. However the number of Mac respondents to the survey is too small for the result to be stated with any great confidence. Also remember that the Mac market is still a lot smaller than the Windows market before you rush off to start learning Cocoa and Objective-C.

These ratios can be useful for a number of purposes, including: identifying a bottleneck in your conversion funnel (is your downloads:visitors ratio low compared to other products?); estimating how much traffic you might need for a viable business; or estimating how much you can afford to bid on Google Adwords. And it is useful to track how these ratios change over time (I track mine on a monthly basis). But make sure you compare like with like if you are comparing your ratios with other products. For example, a 10% sales:downloads ratio might be achievable for a niche business product, but unrealistic for a casual game. And remember that these ratios are only one part of a bigger picture. There are other, more important, metrics. Profitability for a start.

The data set is available here:

Raw data (some invalid records deleted), CSV format

Processed data, Excel XLSX format

Feel free to publish your own analysis. Thank you to everyone that took part in the survey.

[1] Calculating the mean of all the ratios probably isn’t the way a proper statistician would do it. But anything more seems overkill given the limited size and unverifiable nature of the data set.

Is the average visitor conversion ratio really 1%?

We have probably all heard that the industry standard conversion rate is 1%. But where did this data come from? Is that the visitor to sale ratio or download to sale ratio (I have seen it quoted for both) and just how standard is it across the industry? I have put together a survey in an attempt to find out.

There are 8 questions in the survey, but only 3 are compulsory. It should only take you a few minutes to complete and it is completely anonymous. The results will be posted on this blog, assuming I get enough responses to make it worthwhile. If you are selling downloadable commercial software on the web then please spare a few minutes to do the survey.

Click here to go to the survey

** Update : the survey is now closed **