[Edited to add: Hello, Redditors. You succeeded in melting my poor server to slag overnight. I appreciate you visiting, but am sort of glad I don't host the web app on the same server. If any of you have suggestions for how to configure pre-fork Apache such that it doesn't balloon past ~400 MB RAM usage, I'd love to hear them -- I'm much more familiar with Nginx.]
Breaking up has always been difficult for me. I tend to fall in love with being in love, and continue a relationship well past the point of futility. And so it is with my oldest love, writing desktop software.
I’m sorry, desktop apps. We just don’t have a future together anymore. Its not you, its me.
A bit of background: for the last three years I’ve sold Bingo Card Creator, a desktop app which pretty much does what it says on the tin. It has gone from being a passing fancy to a rather lucrative hobby to, well, a bit more than that over the years. As I gradually became more invested in the business of writing desktop software, I got more and more snippy about the periodic desktop versus webapp flamewars, and defended the ascendancy of desktop software.
What Changed My Mind
Over roughly the same period my day job has changed and transitioned me from writing thick clients in Swing to big freaking enterprise web apps. I’ve learned SQL, Rails, etc and used them to fairly decent effect in selling Bingo Card Creator, which is a Swing app (if all you have is a hammer…). This summer, I decided to try stepping my web programming skills up a notch, and released a web version of Bingo Card Creator. It has exceeded all my expectations: in ease of writing, in features, in sales, in support burden, in marketability, etc. In game theory terms, it strictly dominates the desktop version, when seen from the eyes of the developer at any rate.
If I were starting out today, I would, without a shadow of a doubt, write a web app instead of a desktop app, for these reasons:
The Shareware Funnel Is Lethal
I have never used the word “shareware” to describe Bingo Card Creator, because I think that it is an anacronism that my customers do not understand, but among fellow technically inclined people it describes the business model succinctly. Someone visits your website, downloads your trial, and hopefully purchases your program. That process is called a funnel, and if you break it down into concrete steps, the shareware funnel is long and arduous for the consumer:
- Start your web session on Google, like everyone does these days.
- Google your pain point.
- Click on the search result to the shareware site.
- Read a little, realize they have software that solves your problem.
- Mentally evaluate whether the software works on your system.
- Click on the download button.
- Wait while it downloads.
- Close your browser.
- Try to find the file on your hard disk.
- Execute the installer.
- Click through six screens that no one in the history of man has ever read.
- Execute the program.
- Get dumped at the main screen.
- Play around, fall in love.
- Potentially weeks pass.
- Find your way back to the shareware site. Check out price.
- Type in your credit card details. Hit Checkout.
I could go into more detail if I wanted, but that is seventeen different opportunities for the shareware developer to fail. If you don’t catch the download in the 30 seconds people give your website, no sale. If your customer can’t find the file after they download it, no sale. If it requires a JRE upgrade and after restarting their computer they’ve forgotten what they were working on, no sale. If they play around with it, close it, and can’t remember how to open it again, no sale. If they get to the sales page and can’t operate your shopping cart, no sale.
Is it any wonder why shareware has typical conversion ratios of 1% or less?
Web Applications Convert Better
A web application doesn’t have to be downloaded or installed, never requires a restart, and never requires a contextual change just to open up a purchasing page. As a result, the conversion ratio is higher. Much higher. Here are the actual stats from Bingo Card Creator. I’m looking at conversions from my best performing AdWords campaign only, because that minimizes sources of variation like, e.g., the different types of traffic I’ve gotten in the last 2 months (while the webapp was available) versus in the last three years.
Visitor to Free Trial:
- Downloaded: 18 ~ 22%
- Web App: 22% ~ 26%
Trial to Purchase:
- Downloaded: 1.35%
- Web App: 2.32%
This is essentially the same application. If anything, the online version has less features, and it has 2 months of development whereas the downloadable application has had 3 years of improvements made to it. Yet the online version outsells my desktop application almost two to one.
Your AdWords Strategy Is Very Sensitive To Conversion Rates
A portion the numerical disparity is because I have started to react to, e.g., the difference in conversion rates of advertising and promote accordingly. A sale of either nets me the same amount of money, about $28. However, if you break out the math on how much AdWords costs per sale (cost per click divided by conversion rate to trial divided by conversion rate to purchase):
- Downloadable version: $20 AdWords CPA
- Web App: $9 AdWords CPA
(You’re welcome, Google.)
This doesn’t just save me money, it helps me trounce my competitors. For example, if my competitors are selling downloadable software, and they are equally as skilled as I am about writing AdWords ads and optimizing their websites, then it should also cost them about $20 a sale to advertise on AdWords. (This explains why I never see ads for the competitors who try to gain volume by undercutting my price — if you’re going to price at $23.95, you’d better be a crackerjack SEO because you simply cannot afford to outbid me in AdWords.)
Decreasing my cost of customer acquisition by over half lets me bid more for my AdWords to gain additional volume. For example, for the longest time my AdWords strategy was more or less monetizing traffic other people couldn’t be bothered with, while larger brands producing e.g. printed bingo supplies went after the head terms like [bingo cards]. With vastly improved conversion rates, I might be able to advertise profitably on those terms, increasing my volume and making me very, very happy. As it is, I have walked up bids a bit and am getting 25% more inventory than I usually do.
Web Applications Are Easier To Support
Many desktop developers hate customer support with a burning passion in their soul. I actually enjoy it, but I enjoy making it unnecessary even more, as there is no customer support experience so good as avoiding the problem in the first place.
Support requests from last 50 customers:
- Desktop Application: 15
- Web Application: 3
I’ve had three years to streamline the website, purchasing process, and application for my desktop app, and that has helped me greatly reduce the number of inquiries I get. Even after all that work, the main culprits are pretty much the same as ever: installation issues, lost registration keys, and bugs present in old versions of the software that are still floating around download sites.
Web apps, by comparison:
- Have no installation issues, because there is no installation.
- Do not require registration keys. (Technically, because I allow users to use both the desktop and web application, I issue them one — but it is immediately applied to their account via creative abuse of e-junkie and cookies. Most customers get to use their software immediately without actually reading the bit in the email sent to them — or failing to read it, as happens quite often.)
- Never have an accessible version of the software older than the most recent one. By comparison, if you were to Google [bingo card creator version 1.04] (which hasn’t been distributed in, hmm, two years or so), you’d find it on hundreds of download sites.
The Age Of The Pirates Is Coming An End, Jack
I’m famously lackadaisical about software piracy, preferring to concentrate on satisfying paying customers rather than harming their experience with anti-piracy methods. However, the existence of pirates is a stitch in my craw, particularly when any schoolmarm typing the name of my software into Google is prompted to try stealing it instead:
You want to take a quick stab at how many pirates have circumvented the copy protection on the online version? Bwa. Hah. Hah.
I once remarked to Paul Graham that the future of software was with pervasive integration with the server simply because that means that downloading the client doesn’t let you pirate the software any more than downloading Firefox lets you pirate Basecamp. (Ironically, I made that point in a defense of desktop software as a business model. Mea maxima culpa! Theoretical utility of desktop software is one thing, but I can’t ignore what my numbers are telling me.)
Phone Home vs. Google Analytics
One of the curious traits among software developers is that, speaking as a group, we feel something like “I own what happens on my machine and nothing should happen without my say-so”. This generally leads to a severe reluctance to “phone home” from the application to the developer’s server — even reports on very innocuous data like “Did I steal this software or not?” is often tarred with the label spyware.
On the Internet, privacy expectations have evolved a bit in the last few years. The overwhelming majority of the public has been told that they’re being tracked via cookies and could not care less. If you write a privacy policy, they won’t even bother reading it. Which means that you can disclose in your privacy policy that you track non-personally identifying information, which is very valuable as a software developer.
- What features of your software are being used?
- What features of your software are being ignored?
- What features are used by people who go on to pay?
- What combination of settings is most common?
- What separates the power users from the one-try-and-quit users?
Tracking all of these is very possible with modern analytics software like, e.g., Mixpanel. You can even wrestle the information out of Google Analytics if you’re prepared to do some extra work. You can do it in a way which respects your users’ privacy while still maximizing your ability to give them what they want.
Some people may be under the impression that users will tell you what they want. Nope — most of them will assume you are like every other business they have ever dealt with, where their opinion doesn’t matter, and the software is offered take-it-or-leave-it. And they just left it!
Things I learned about Bingo Card Creator customers which I never knew before I had an online app:
- The most common word used in bingo cards is — ready for it — “baby”. I completely underestimated the demand for Baby Shower bingo cards, and avoided making an official set for years. As soon as I had the top ten word list (which was all baby shower words) I fixed that.
- The more features I add to the software, the worse it sells. (This is, needless to say, highly unintuitive to most software developers.)
- Most customers purchase within two hours of signup, so it is absolutely imperative that their first use of the software exceed all their expectations.
Web Apps Can Be Customized Per User
Downloadable software pretty much has to treat every user identically by default. There are very limited ways to segment users, and no way to report the results of experiments. For web apps, however, if you have a halfway decent A/B testing library (like, say, the free one I wrote for Rails developers), you can experiment with having multiple versions of the application available concurrently, and see which one performs best.
The data collected by A/B testing has helped me:
- simplify my options screens to avoid confusing users
- improve the first-run experience
- write instructions such that they’re easier to follow
In addition to changing program behavior randomly, you can segment your users. I have only scratched the surface of how powerful this is, and it is already producing solid results for me:
Don’t treat your newbies like you treat your power-users. You have a database. It records all their actions since the dawn of time. Use it. I have a couple very simple heuristics for “is probably still getting used to the software” and, if you are, the software treats you with kid gloves. For example, it hides complex, seldom used options by default. It gives you instructions to a degree that a power-user might find insulting. (I don’t have the artistic skills to draw a little animated paperclip but I would if I could! It looks like you’re trying to make a bingo card. Need help?)
Give your customers a “credit” score. I have a particular heuristic which segments users into four buckets. It isn’t exactly FICO, but it does successfully predict conversion rates: they range from 10% in bucket A to 0.01% in bucket D. Bucket C is interesting, though — they convert some of the time, but don’t seem to be getting quite the value out of Bingo Card Creator that Bucket A does.
I wonder if Bucket C would feel differently if they got a $5 coupon in the email.
Meanwhile, it looks like Bucket D isn’t very interested in paying me money under any circumstances, but if I had a scratch-my-back-to-get-it-free option, I could place it prominently on their dashboards.
Long Cycles Mean Low Innovation. Short Cycles Mean Fast Innovation.
This sort of thing is very difficult to do with desktop apps, because you can’t reliably collect data on what approaches work, and you have the build/test/deploy/distribute cycle to worry about. It takes months for a new version of the desktop application to hit more than half of my users, and I give out upgrades for free.
By comparison, I can literally have an A/B test coded, tested, and deployed globally in under a minute, for ones which are fairly low impact. Relocating a button, for example, requires two lines of code, a SVN commit, and a quick server restart. I start getting data immediately. By comparison, doing that on my desktop app would require 15 minutes of building, then waiting weeks while the new trials percolated from my website to the various download sites, and probably unforseen issues on Mac OS X 10.4 because apparently in a past life I must have stepped on Pharaoh Jobs’ cat.
Recently, a desktop developer’s mailing list that I’m on commented that a release weekly development cycle is unsustainable, bordering on suicide. As a desktop developer, I agree, it would break me. As a web application developer — I have released 67 updates to Bingo Card Creator in the past 7 weeks, and this isn’t even my day job. A button here, some textual edits there, seven A/B tests, etc etc, and pretty soon you’re looking at the magic of compounding 1% improvements.
Speaking of Magic
I love desktop applications. I prefer them to web apps almost any chance I get. You can keep your Google Docs, Excel is superior in almost every way.
As a developer, I love getting permanent presence right in front of the user (on their desktop, naturally).
My customers love desktop applications. They love the “physicality”. They love the perceived security (the number of people who purchased backup CDs and then proceeded to only use the webapp is downright distressing to me). They love that the application has first-class OS support, feels native, copies and pastes right, works with double clicking files, etc etc.
But at the end of the day, I’m an engineer. I follow the numbers where they lead me. The numbers say that sales in this August were 60% over those of last August, despite a major blowup with Google that should have cost me dearly. All of my attempts to distill wisdom from the statistics have lead to one conclusion: the cumulative advantages of the web application, in my advertising, in my on-site experience, within the application, within my development process, and within my purchase funnel are just stupendously superior to the desktop app.
I’m sorry, desktop apps. We had good times together, but we’re through.
[Edit to add: I'm going to continue supporting all customers of Bingo Card Creator, regardless of how they choose to get it. The next major release will almost certainly be its last. The webapp, and my future webapps, seem to be much better investments.]
Wow, Patrick!
Thanks for this major kick in the rear! I came to the same conclusions a while ago, but haven’t acted upon them until this moment. I hope now I can and will do that.
[...] http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-apps/ a few seconds ago from Gwibber [...]
i am looking forward to thoughtfully responding to this once i get out of a internet/cell services challenged area
I look forward to reading it, Nick. If you put it on your blog, drop me a line so that I can mention it. I’m patrick@ any of my domains or patio11 on Twitter.
I agree it’s way easier to make a web app.
Me too prefer desktops apps as a user.
So that means there is a place for easy to make easy, easy to deploy everywhere(multiplatform) desktop apps that could use the network. Maybe the adobe AIR APIs will make it. Just creating an installer (and compiling) on two Linux distros, MacOsX,and two windows is hell.mmmm interesting, I never thought about it, we need a standard way of doing that.
Thank you for sharing your story. Very tempting to follow in your footsteps because it’s really difficult to sell my desktop app. The apple app store concept has made the funnel much shorter, so it could be interesting to try code for iPhone.
What about pr and webapps. If you have a desktop app you can announce new versions of your software. With a webapp this oppertunity for pr doesn’t seem to be there. How do you tell the world about it?
Great post Patrick, really insightful.
I particularly like a web app’s ability to circumvent piracy without taking a single thing from the paying customers. This is something that is going to be very valuable to developers and consumers.
Um, I don’t really know how to say this, but wow, just wow and “thank you” too.
Great blog entry, one of the best entries I’ve seen in a while (and I read a lot of good ones).
[...] Why I’m Done Making Desktop Applications: MicroISV on a Shoestringkalzumeus.com [...]
Patrick, thanks, very insightful! I mean, I am doing webapps for a living for years, but I am preferring ‘physical’ desktop apps myself at the same time. Obviously it’s time to reconsider and act on what I knew already.
Thanks for the hard data btw!
No one gives a shit, seriously, except others who blog and look at other blogs just to comment so the others can get comments back on their blogs to feel like people actually *care* about their blogs.
In reality though, passer-bys just don’t give a shit why you’re done with A and switched to B.
1) I completely agree with you.
2) I wouldn’t count desktop apps out just yet.
Why not? Because the core problem you identify is _conversion rate_. It’s harder to convert someone visiting your website to a paying customer for downloaded software than for an online web-app.
There are other advantages, e.g. easy analytics.
But with new software delivery platforms such as Adobe Air, .Net Web Apps & ClickOnce (latter now integrated into Windows 7 natively) & Silverlight Out of Browser – > and no doubt things I don’t know about, the difficulty to installing a desktop app cuts SIX steps out of your list of 17. Click install link, app downloads and installs instantly.
And with these web-enabled frameworks (esp. Adobe Air and ClickOnce) you can have them report to the server on launch (check for updates) if the user is connected to the internet; making it somewhat more difficult to pirate.
But hey, we’re 3-5 years away from decent adoption for any of that stuff. Right now, web apps are the way to go.
[...] Why I’m Done Making Desktop Applications: MicroISV on a Shoestring [...]
The Google translation of the above pingback is beyond awesome.
Swedish:
Jag slåss med näbbar och klor för att allt ska flytta till webbläsaren. Och här får jag bra eldunderstöd, och andra kloka tankar, från en tidigare desktop-kramare.
Google:
I fight tooth and nail for everything to move to the browser. And here I get good fire support, and other clever ideas, from a previous desktop-hugger.
I think “previous desktop-hugger” is going on a T-shirt.
You make very good points. However I disagree with your conclusion that it is unwise to continue to make a desktop version of your program.
To someone with an infinite supply of great ideas, this is the correct conclusion. Why waste time on less profitable activity? However, if a developer wants to focus on a something (”I am going to offer the end-all be-all of Bingo Card creation”), would it not be better to make a full “family” of versions of the program? The work to issue the app on another platform is less than the first. A complete line-up is a good selling point: a customer sees that you are fully invested in this lineup, and it provides more value if their registration gives the purchase of the desktop app and the online version. The profit return doesn’t see the same margins, but it’s a profit nonetheless.
I think the proper conclusion is to take your situation’s information into consideration (as you obviously have, and have drawn excellent insight from), and prioritize accordingly.
Patrick, great article!
More than 6 years ago demand for web development pulled me from desktop development into web, and I’ve never looked back since then.
Web apps are much easier to scale, update, and track, and that seems to be much more important than better UI responsiveness in desktop apps.
Great post! Me, I prefer web apps 99% of the time. Especially for “vertical” enterprise apps — web apps give less way for the developers to foul up the user experience.
I would be very interested to learn what criteria you are using to divide your users/potential customers into the 4 different conversion rate buckets you mention.
One more benefit of Web Apps: People can try it without installing it. I suspect that for a lot of people, “Installing the software” is a relatively big commitment and means they have to un-install the software afterward, and many people have no idea how to do that.
However, I’m not prepared to give up on desktop apps (and especially not mine!). I wonder whether you can generalize from Bingo Card Creator to web apps in general. That is, an email client or blogging editor would get better conversion rate as a web app, but a photo editing program or database query tool would not…?
Also, the desktop version of Bingo Card Creator is missing a few tricks:
1. When the user clicks the ‘Download’ button, they are given the option (in IE) to ‘Save’ or ‘Run’ – some won’t know what to do so will just give up. They need big, clear instructions for what do do. For example: http://www.solaraccounts.co.uk/download.php
2. When they do run the setup.exe file, they get a big nasty box with a red cross saying ‘The publisher should not be verified’.
3. The UI of the desktop app is ugly. Sorry, but it has to be said – the default Java Swing UI looks like a 10-year-old’s homework project.
I think it is important to distinguish between web applications and vendor-hosted web applications (SaaS). The first scenario (the web application is installed in the client web server) already presents many of the benefits you describe but the second scenario is the one offering the full-benefits.
I thought that customers would be reluctant to have their data in an external server but it seems that even in more critical domains they are getting used to it. In our survey of online project management tools (http://modeling-languages.com/blog/content/tools-teams-survey-web-based-software-project-portals) we realized that first many (software) project management tools moved to the web and that now they are moving to a SaaS model and not many customers complain about that, even if this means that their source code is hosted in an external company
Well, I didn’t really like your list in “The Shareware Funnel Is Lethal” as I cannot count the number of times I’ve screamed obscenities at some web site that was just impossible to use or register at or that caused BSODs (yes — those sites exist… and they’re banking sites…), so I think it was a tad on the unfair side there. There are far too many web sites that are just insanely difficult to use. More than just a few times, I’ve screamed some profanity and clicked that little X in the upper right (or upper left) because I just couldn’t deal with the pain.
e.g. A great way to get me to not make a simple purchase is to make me register.
In any event, I enjoyed seeing those numbers and your commentary.
However…
@Dennis:
> Web apps are much easier to scale, update, and track, and that seems to be much more important than better UI responsiveness in desktop apps.
Well, kind of true. It depends on the application. Some software simply will not work on the web. I’ve seen it tried with some pretty complex stuff, and it was a brilliant failure. Not because the developers were stupid or anything, but because the nature of the application just didn’t work on the web.
CRUD works on the web, and it works brilliantly.
But, the web introduces its own problems as well. Network reliability? To be honest, there’s no way in Hades I will ever trust certain ISPs. If I were teaching in backwater China, you can bet that I’d want the desktop version of BCC and not the web version.
It’s an “it depends” thing. The nature of the software will determine where it can or should run.
I’ve got software that I could easily port to the web, and other software that would be impossible to port to the web (or just plain irresponsible to port there for various reasons).
I’ve got a new line in the works where the revenue model will be web based, but will also have desktop software to go with it.
I got out of doing much web development a number of years ago because I just wanted to do things that couldn’t be done on the web. That’s changed a lot now though, and from what I see, Silverlight is the answer for demanding applications.
It’s certainly possible to do a lot more now on the web than you could 10 years ago, but there are things that still cannot be done. There are things that should not be done on the web. There are things that should not be done on the desktop.
What I really got out of your article, and really appreciated, was the conversion rates. That was fantastic. I will be keeping that in my little treasure chest of knowledge for future reference!
I suppose that I just don’t care where the app is… I care about the $$$’s. :)
Cheers!
It’s funny you use the relationship analogy, because I’ve used one for a while to explain SEO to people.
Lots of people water down what they’re saying for fear of offending someone. They know that everyone has different tastes and they don’t want to scare anyone off. But if you think back to when you were single, trying to get a date (this is looking back farther for some of us than for others), think about the guy who always got the girl. More likely, he didn’t always get *the* girl, he always got *a* girl.
What I’m saying is, if there’s an approach that works even 30% of the time, just do it three or four times a night and you’ve got someone. You just have to be willing to move on to the next if it doesn’t work. If instead you pick *the one*, then you have to have the right approach for *her*. And that’s assuming you’ve even got the right “product” to pitch to her.
If you don’t care so much which girl you get, so long as you get one, then you go with the high-probability approach. But doesn’t that feel a little bit … icky? (By the way, if you said “yes” to that question, you were the guy wondering why all the girls went for that smooth talker.)
Now return to sales. You want their money. And all money is the same. So you’re after the high-percentage solution. By dropping the desktop app, you may be turning away 10% of your potential customers. But if that picks up 30% *new* customers, you come out ahead.
Does this mean abandoning a niche that someone else may exploit? Sure. Let them. You’ve got bigger — or rather, *more* — fish to fry.
Thanks for the great post. The example of identifying the most common use alone made this post worth reading.
First off, this is a great post, and I agree with all the points you make. However, I have a nit to pick…
You say that you can write an A/B test and have it deployed in “a couple minutes” after a “quick server restart.” That line destroyed any hope you have of selling your webapp to me, as it demonstrates that you don’t understand the repercussions of restarting your webserver.
What happens to any request in process at the time of restart? What happens to your (presumably ajax or ajax-like) webapp during the period after the server has stopped but before it has started again? You may think it’s not a big deal, or that you can restart fast enough that no one will notice, but the more customers you have the less true those ideas become.
Most customers don’t have the technical knowledge to know that’s a bad thing. However, when they experience a glitch or a problem due to your server restarts they’ll start to view the app as unreliable. When users view a web app as unreliable, they’ll share that feeling with potential users of your application.
You’re a small and nimble shop, and one of your advantages is that you can work fast and have changes out there so quickly your client’s heads will spin. Don’t give that up, but do find a way to deploy changes without interrupting client requests. (Hint: 2 servers and a load balancer make that very easy, and with free options like relayd on openbsd or lvs on linux you don’t even have to spend very much. If your traffic levels are low enough you could even do it on a single server with 3 VMs.)
>>
That line destroyed any hope you have of selling your webapp to me
>>
Well, technically speaking, that hope was dashed when you decided not to go into elementary teaching.
I could work out the math with you, but I’d need ten times as many customers as I have now to run any significant risk of interrupting customer requests with restarts. (Note: I live in Japan, whereas almost all customers live in America. When they’re on the site, I’m sleeping.)
I’ll cross that bridge when I come to it.
Patrick,
While I personally didn’t go into teaching, my mom was a teacher, and I know quite a few. Maybe I know the exceptions, but it’s not uncommon for them to be up late into the night working.
However, that’s neither here nor there. My only purpose was to raise awareness of the issue, which it seems you have. I’ve walked into too many environments where that’s not the case, and they thought server restarts were entirely harmless. One place was restarting as often as every 10 minutes during the workday!
Fantastic Article. Thanks for the stats and the detail.
Patrick, great article as always. I have been following you for years, simply because you are such a great writer. There are a lot of great sites on mISV and software development but you seem to a have a great touch as far as your ability to share your experiences (and growing expertise).
Now, being a “website software seller” myself, I agree 100%. The Web model is the way to go. But I would throw in a new wrinkle for you. I would now pigeon-hole yourself into thinking Web = SaaS. In fact, there are other models. I sell the actual web site scripts, and my business is growing fairly well. That smells a lot like the shareware model, but it isnt. Yes that raises the ugly head of piracy again, download issues and platform support. But it also brings to light the fact that not every customer needs or wants to access another SaaS site online to use a service. It also brings in focus a new customer base….and thats the small website business owner, who themselves (just like you and I) own a website business, and need software to help them manage their website, deliver value to their customers, and compete online. I realized that more and more people are feeling empowerd and starting to learn HTML and server-side scripting. Yes, there are a millions free scripts online. But there are just as many people who need to bypass that process and want to upload something to their site that delivers value. So, also consider the “non-SaaS” web software model. My sales are doubling and tripling and more every year now selling “websites” and scripts. So, think about that angle as well.
Keep up the great work. Will be following your comments online. – Mitchell
…forgot one item…
You need to think about what it requires to move to the web model (SaaS). It has its drawbacks (versus selling website software).
1. If your site or server or provider goes down, you have 10,000 angry pissed off customers at once. Not good. Your business, life and even time (ie 4 am phone calls) is now chained to your server. If anything good or bad changes there, the dependency of your whole business lives or dies with your hosted solution. That means there is no such thing as a “vacation” for you in that model. If you are at the beach and your phone says your the Feds raided your ISP and its shut down the servers, you are screwed!
3. With a subscription model, your ability to scale is there, but your cost for hosting and bandwidth follows that. You cant espace that expense.
4. Any bugs translate into 10,000 bugs for all your customers now instantly.
5. Your ability to leave this business model or solution is difficult as you created a direct dependenly with your subscription users.
6. You have created yet another Web 2.0 site that requires users to visit yet another URL for a service associated with them or their business. That again, leaves your business in some cases directly linked to other businesses or users. Wouldnt it be better, like in the desktop model if you were divorced from your customers, yet still delivered a soluton that they could use and run on their services, devices, sites, etc?
My point is not that Im against SaaS and the Web Model. 100% better than Desktop. Im just against the hosted platform model. It will eventually link you at the hip to your ISP and web product. Maybe a better model is a hybrid of solution whereby customers get your service from the site but have the option to run or install it on their servers. Justa thought.
You have proved with stats that there is no or little money that shareware authors can hope to make using desktop apps. Though I am a fan of web based apps, I am reluctant to store some of my oft used data on the web because I need high speed, instantenous searching of a large volume of data (which is possible only when using desktop app stores data locally). But I have to admit that the software I am using is a cracked version. I starrted using this software many years ago, and never paid for it. Had it been a web based application, I wouldnt be using it. Though I think if they had a donate button on their site, I would send in whatever I can now, but they dont have any way of accepting donations on their site. (And they stopped supporting or making that software) As much as people use software and webware, they also need to come forward to support the software authors financially so they can stay in business and feel motivated. And nothing motivates like money. Will (really useful) desktop apps survive? I would like to hope so.
That was one of the best blog posts I have ever read about this.
Congratulation man – I guess if we ever look back past history, you have immortalized yourself here.
But you killed desktop apps as well! ;-)
Google docs vs Excel
I know you meant this as a side comment, but soon you will learn of the awesome power of google docs, and you will never use excel again.
There are a ton of XML get-request (if not ReST) based services on the internet, and they are really easy to write. You can use Google Docs to pull those in and it will cache them.
Multiple people can be working on the document at the same time (and yes, I’ve used this and it is practical, but you will want some kind of voice communication connecting you).
You’re documents are available anywhere, even on your phone, and you never have to worry about the concept of a “File” anymore, you just add another email to the document if you want someone to be able to see it.
Even if you want to work offline on a document, Google Gears will let you do that just fine.
It’s hundreds cheaper than excel. :P
I know that sounds like marketing for google, but my point is almost nothing you can’t do in a browser these days, and you have MUCH more flexibility as a developer, which means you can build it better, faster, stronger, cheaper, etc.
I think instead of allowing desktop shareware demo downloads, authors can let them try the software online via a virtual machine hosted online (like how crossbrowsertesting.com does), that way, without allowing a real trial download, then the user can convince himself how the software works, and decide to buy or not. Like a demo PC fitted with logmein so you can login and play with the software online to see if you like it.
I have to say, man, this one of the best posts on web programming I *ever* read.
I have learned *so* much from you today!
Thanks a million!
“First class OS support”? I took a look and there’s ZERO support for my OS. Maybe you shouldn’t toot your horn quite so much, dude.
My biggest problem with web apps was perfectly illustrated when I loaded this blog page. It got hung up for a few minutes. I hit Refresh twice and it finally loaded. If your application server experiences such a problem and if you have a large user base (I once had a user base in the tens of thousands) everyone using your software at that moment is held hostage to your server’s problem. While I can see where the numbers make this choice the right one for you, you may find a point where your user base grows to the point where it becomes a real headache. Does your pricing model cover the extra hosting costs that will come if your user base grows to a large number?
Thanks for this post. It heartens me as a developer spending hundreds of hours of my life learning Javascript, jQuery, et al…
Having worked on both, I agree about how much easier it is to get leads to start using a webapp than a desktop app. Another advantage of the webapp I didn’t see you mention is data security: you don’t have to worry about user’s hard drives going belly-up and losing all their precious data. This is a real concern with desktop apps.
Developing for the web is still a bit of a mess even when you use the best tools, but I’m hoping that over the next 10 years developing a web UI becomes as easy as developing a GUI app with Windows Forms or Swing. I think it will, we just need some time to get there.
Good piece. I wish my conversations were as conversational as your writing style.
Two questions:
1. Do a lot of teachers have locked down systems, making a web app a better fit for this market?
2. If you had to do it all over again, would you still use RoR?
>>
Does your pricing model cover the extra hosting costs that will come if your user base grows to a large number?
>>
Considering I can put about $300,000 or so worth of accounts onto a server which costs $100 a month without breaking a sweat… yeah. ;)