Kalzumeus Software

[Editor’s note: now available in Belorussian translation.]

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:

1. Start your web session on Google, like everyone does these days.
2. Google your pain point.
3. Click on the search result to the shareware site.
4. Read a little, realize they have software that solves your problem.
5. Mentally evaluate whether the software works on your system.
6. Click on the download button.
7. Wait while it downloads.
8. Close your browser.
9. Try to find the file on your hard disk.
10. Execute the installer.
11. Click through six screens that no one in the history of man has ever read.
12. Execute the program.
13. Get dumped at the main screen.
14. Play around, fall in love.
15. Potentially weeks pass.
16. Find your way back to the shareware site.  Check out price.
17. 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.]

Thanks to the Ruby on Rails site, Rails Inside, and everyone else who has so generously written about A/Bingo, the Ruby on Rails split testing framework.  Memo to self: next time, incorporating a pun into the name is fine, but incorporating a pun more limiting than the actual feature set is perhaps not a good idea.

If you have any requests or questions about A/Bingo, you can either leave a comment or drop me an email.  patrick@ either of my domains should work fine.

[Edited to add: Thanks for your interest!  The position has been filled.  If you’re interested in hearing from me the next time I need somebody and/or know of an opportunity, my email is always open.]

I’m again in the market for some freelance talent, and before I go to one of the body shopping sites and get inundated with proposals by folks offering to clone eBay for $25, I thought I would put the word out here.

The Project

Bingo Card Creator, my small software business, is intensely seasonal.  Many of my customers want to play, for example, Halloween bingo or Christmas bingo with the software.  It is in my interest to make it obvious to customers that that is possible, so I am developing a total of 13 mini-sites which pitch various holiday bingo activities.  The sites generally include bingo cards for the particular lesson, instructions for how to play bingo, suggestions on how to incorporate them into the lesson plan, and what have you.

What I Have

• Two reference implementations for the type of writing I am going for.  (See above.)
• The pictures, PDFs, and other resources you’ll need to include on the sites.
• WordPress installed and an administration account configured on all sites.
• Designs for the sites — this is not a coding project.
• A brief one-page style guide.

What I Need The Freelancer To Do

• Five pages per site describing how to play <pick the holiday> bingo and how Bingo Card Creator fits into that.  This is on the order of 500 to 800 words per page, plus associated formatting.  I will provide the 5 topics per each site.
• Basic WordPress configuration: turn comments off, configure sidebar, copy/paste a line into Google Analytics plugin, set a particular page as the front page, etc.
• Most importantly: the writing needs to be warm, inviting, and grammatically flawless.  I sell to teachers.  They notice these things.

Business Considerations

• I am willing to pay $100 per site completed, via either Paypal or (if you live within the United States) check.  I have been known in the past to award bonuses for exceptional work.
• I have previously paid in excess of $2,000 to freelancers without incident.  If you wish, I can provide references that I am a very no-nonsense client who provides clear direction, does not micromanage, and pays scarily promptly.
• I am flexible on the timeframe for the project, but my sense of things is that each site is a few hours work, and that someone working very part-time on the project would complete it in about two months.

I would prefer working with a single person for this project but am willing to split it up if I have multiple qualified applicants.  The ideal applicant would have substantial experience with expectations in American elementary schools, as either a parent or teacher, but I’m willing to consider anyone.

If this sounds like something you’d be interested in, please mail me at (my first name) @bingocardcreator.com  , and include a short one-paragraph explanation why you think you’d be a good fit.  If you aren’t personally interested in this, but know somebody who it would be a good fit for, please feel free to tell them about it.

I look forward to working with you on a fairly fun and mutually rewarding project.  Thanks!

I finally got serious about putting a blog on the Bingo Card Creator site today.  Since Bingo Card Creator is powered by Rails, ideally I’d be using a Rails blog platform, but frankly, they’re all vastly inferior to WordPress.  I could have slapped up a WordPress blog on a subdomain and called it a day, but I always advise people to put blogs on subdirectories for SEO reasons, so I thought I’d do it properly.

It is easy to bork this setup if you don’t understand WordPress and Nginx configuration files.  Make backups of all server config before you start modifying them.

Extracting a WordPress Theme from your Rails App

If you’re not a PHP-speaking web designer, this step can take a lot of time.  Or, alternatively, you can just pay $10 and use ThemesPress.  They have a web-app where you copy/paste in some HTML and CSS and they spit out a widget-enabled WordPress theme for you for $10.  This is well worth your time.

1. Look at your main CSS file.  Identify any images which have relative URLs.  Replace them with absolute URLs.  This will save you from having to upload the images to ThemesPress to see the preview, and besides, you should be doing this anyhow for static assets so that you can serve them from images{1,2,3}.example.com and speed up page loading.
2. Load the main page for your site.  Click view source.  Strip out the place where Rails loads your CSS.  Replace your sidebar contents with {SIDEBAR}.  Replace your main body contents with {CONTENT}.  Replace any relative URLs to images with absolute URLs as in step #1.  Save this file for a second.
3. Go over to ThemePress, skip the image uploading step, and follow the onscreen directions.
4. Pay them their $10.  Bwahaha, you now have a WordPress theme for your Rails app.

Set WordPress Up At A Private URL

1. I find the easiest way to do this is to create a new subdomain (blog.example.com, for example) and have Apache listen to requests on a non-standard port.  If you’re not paranoid about other people seeing your work in progress, you can put it on port 80 like usual.  I suggest not using a private IP at this stage, as you’ll find it difficult to diagnose problems in your browser until you get to the Nginx config step.
2. Install WordPress like you normally would.
3. Verify that the theme you created works well, make a post, etc.
4. Go to WordPress Settings and change the Blog URL to be your final blog URL.  For example, http://www.example.com/blog rather than blog.example.com.  That URL won’t work right now.  Don’t worry, we’ll fix it.

Tweak Nginx Settings So That It Reverse Proxies Your Blog

1. I could discuss the rationale for these settings a bit more, but they are a bit quirky.  If you copy/paste them, they should mostly work.  Good enough, right?
2. Restart Nginx.
3. Verify that you can access your main blog page and your admin page.  Do not proceed without doing this.

Change Your WordPress Settings

• WordPress has two URLs listed in settings, one WordPress URL and one Blog URL.  Your WordPress URL still reads something like blog.example.com.  Since Nginx is now set up properly, go ahead and change that to http://www.example.com/blog/ , like your blog URL.
• You now have NO need to publicly access the WordPress server, since the only user who will ever see it is Nginx, while proxying for you.  You can go ahead and move it to a private IP.  This will mean Google doesn’t come along and access blog.example.com by accident, then think “Hey, he is stealing content from himself.

There you have it, one blog on your Rails app!  Now start writing.

P.S. Don’t forget to tweak your Rails templates to, you know, link to the blog like a first class citizen of your website.

… you have to phone Chase in the middle of the night to say the $600 charge to GoDaddy was authorized and it was a very good deal, too, thank you very much.

A few dozen domains times two year renewal adds up really, really quickly…  (I actually paid GoDaddy $160 to become a member of their buyer’s club for two years, which knocks some money off the cost of domains.  In particular, for whatever reason, .net domains get a 53% discount off the list price.  Considering I own over a dozen of the suckers and they’re normally fairly expensive, that was enough to justify the membership by itself.)

Which reminds me — I really need to get some freelancers to help me fill these things out.

I passed a bit of a milestone yesterday: I’ve sold $50,000 of Bingo Card Creator.

It is an arbitrary and meaningless milestone, but it put a smile on my face nonetheless.  I’m cautiously optimistic that the next $50,000 won’t take 3 years.  (Profits before taxes are somewhere in the $27,000 range if I’ve managed to tally all my receipts correctly — always unlikely until tax time rolls around.)

Wish me luck — the school year sales started this week and it appears that I will be moving out of the summer doldrums in style.  The online version is converting very well (1.7% of all trials, including a large portion of trials that wouldn’t reasonably have converted yet because it is too early).  My new ad campaigns are posting my highest conversion rates ever, courtesy of the online version being easy to sign up for.  My first newsletter, sent yesterday via Mailchimp, resulted in 2 sales ($60) for about $2 worth of email postage.

All in all, things are going pretty well business-wise.  More updates as they happen.

Recently I blogged about how I was redesigning my landing page to increase conversions from AdWords.  I am almost embarassed how well this is working.

That picture pretty much tells the story: for the last 1,000 visitors, the One True Goal button got over 180 clicks, and the (equivalent) sign up free link above it picked up another 40.  When you add in the (not pictured) ways to convert lower on the page, plus ad back in the folks who went off to the home page but ended up converting to the trial later, the conversion rate is about 28%.  Yowza!  For comparison, I generally do well to get 21 to 22% on AdWords.

This means that the same number of impressions results in a third more trial downloads for me, and hopefully thus a third more sales.  Or, to phrase it another way, the cost of customer acquisition for me just declined by about 25%, which is good because AdWords is my largest expense by far.

Because of how Conversion Optimizer works (Google automatically adjusts your CPC bid to target your proposed CPA target), this likely means that over the next few weeks Google will increase the CPC bid I give for placement on sites like About.com and whatnot.  That should increase the number of impressions (and hence, clicks and conversions) that I get.  Cross your fingers for me.

Photo credit to CrazyEgg, obviously.

I wrote up a fairly lengthy article on how to use Mixpanel with Ruby on Rails.  Mixpanel is a new analytics service I’ve been playing around with for the last week or so.  It is probably slightly more technically involved than most uISVs would care for, but the funnel tracking is solid gold.  You can see some changes that lead me to making for BCC, too.

As always, I’d love to hear your comments.  (I am on a bit of an optimization kick lately, aren’t I.  Got to get ready for the school year!  Three more weeks or so and I won’t be able to break the website NEARLY so often.)