Kalzumeus Software

I was convinced when I woke up this morning that it was Wednesday, because yesterday was The Big Presentation and I had thought that was a Tuesday.  Turns out today is Friday, because TBP was on Thursday.  It went pretty well, incidentally, and my month of 12 to 16 hour days is now over.  There is now a functional spam filter where there wasn’t before, and within the month it will be OSS for all the world to enjoy.

You know what I really like about the prospect of self-employment?  No months of 12 to 16 hour days, and no forgetting what day it is.  (I still like my day job, incidentally.)

Ben Yoskovitz of StartupSpark has posted his interview with me.  “Bingo!  Patrick McKenzie lays his cards on the table.”  What can I say, that title warms me to the core of my bad-pun-loving soul.  (You may not know this, but 37  states and the District of Columbia require loving bad puns as a prerequisite for getting a teaching certification.)  This interview is largely focused on my experience as a uISV and thoughts on the field in general.

My personal favorite quote:

If I wanted to make a splash, I would say that it is more important that your ordering pathway be flawless than your application be the best in its class. Do you have a design document for your ordering pathway? Why not?

I could certainly do a better job of that myself, incidentally.  Getting better, bit by bit and month by month.

There has been a wave of interviewing going around in the uISV community, at least from my distorted perception of it. The recently relaunched MicroISV Show at Microsoft has an interview with Joel Spolsky, of Joel on Software fame. It is worth a listen and even more worth a read (transcript available, thank goodness), since you can probably process the information much faster when reading than while listening. I love oral communication as much as the next guy (in fact, probably more than the next guy, since I did forensics activities for about a decade) but for technically dense material its sub-optimal.

Separate from that interview, no less than three people have interviewed me in the last two weeks. I imagine it will be a couple more years before I get over being flabbergasted that people apparently think I have something valuable to say. One word of caution when you’re reading/watching any interviews: remember that everyone speaks on the basis of their own experience. Joel Spolsky, for example, runs a company with millions of dollars a year in sales, has multiple employees, transparently enjoys his situation, and is of the opinion that it is impossible for a uISV to succeed with less than two employees. I am a sole proprietor with thousands a year in sales (and not many thousands at that!), neither have nor particularly desire employees at this point in my life, transparently enjoy my own situation, and am of the opinion that you can be successful under almost any configuration for the appropriate definition of “successful”. Even if that definition of successful is “go to sleep on a mattress packed solid with dollar bills you’ve made”, I know a number of one-man shops who qualify.

(Other things I diverge on: the reports of desktop applications being dead are greatly exaggerated, “80% of your business is non-code” vastly overestimates the importance of the code, and a few minor niggles.)

Similarly, you should keep in mind when reading any interviews with me that I have more experience being a paperboy than being an entrepeneur, and that I was a total failure as a paperboy.

Anyhow, the first interview to go up was here. The interviewer was very interested in my experiences in Japan, so if the prospect of working in IT in Japan interests you and you’d like to see one take on it, you may find those answers interesting. If you are a regular reader of this blog, or have read the about page, the bits about my uISV will probably not contain much new information for you.

The other two interviews were more focused on my uISV experience and thoughts on the field in general.  These interviews are not publicly accessible yet.  When they are I will update this post with links to them.

(Note: I don’t normally describe my software as shareware, but it appears someone on a rather large European shareware developer board has linked to me in a discussion of refund policies. I’m using this post to answer the question asked, and using the title to make sure anyone can find the same information from Google. Why I don’t call myself a shareware author is a good discussion for another day.)

Anyhow, the story in a nutshell. I sell a program which creates bingo cards for US$24.95. My primary customers are teachers or parents of elementary school aged children in the United States. My typical customer is female, in her thirties and is not very technically proficient or very trusting of the Internet. Since the day my business opened on July 1st, 2006, I have had a 100%, no questions asked, moneyback guarantee. I publicly make the guarantee for a period of 30 days past purchase — between you and me, if any customer were to ask for their money back after that period, I would go to any length of effort up to and including mailing them a personal check to get them their money back. I have previously commented on my reasoning for a moneyback guarantee here and am additionally strongly supportive of Steve Pavlina’s rationale.

OK, the part of the post you’ve all been waiting for: in the last six months, roughly 5% of my customers have requested a money-back guarantee. I consider this figure to be abnormally high, as it counts rough patches in my program’s development (version 1.0, the first rollout of the Mac version, and two after-upgrade shakeout periods) which do not happen on a regular basis. For the most mature version of my software (v1.04, which was sold constantly for a period of approximately 4 months without any significant change to the codebase), my refund rate was under 2%. The most common reason cited for people excercising their right to a refund is a variation of “I tried it out and it doesn’t quite do what I want” (I don’t ask but many people tell me anyhow).

Note that that reason is an excellent empirical demonstration of another mechanism by which the guarantee can make you money: it means that at least some of your customers are buying your product when they are not yet convinced that it will meet their needs. The guarantee thus provides a safety net, allowing the customer to externalize the risk of their extended trial period to you, the developer. They think “Well, if it doesn’t work out, I can always return it”. You should be happy to bear this “risk”, as a return costs you little or nothing to process, meaning that this is pure upside from your point of view. (I have never paid a penny as a result of processing a return. Paypal refunds my transaction fees when I initiate a refund.)

I have been using CD Fulfillment’s default CD image since I started issuing the CDs.  While its utilitarian, it doesn’t exactly present a great image of my software or help my technically-disinclined customers through the process of getting the software to work.  I have just gotten done creating an image which will be hopefully slightly more helpful in this regard.  This won’t be the final edition, as I’m concerned that there is too much text and that it will cause folks’ eyes to glaze over.  (If you have suggestions for alternate wording, please, fire away).

Note this image is not the uncompressed BMP that CD Fulfillment will actually use to burn the CDs.  You can click it to see it in its 927×927 several megabyte full-sized glory.)

 Incidentally, I have been thinking of moving my CD fulfillment away from  cd-fulfillment.com to SwiftCD.  I have resisted doing it so far because the reason is inherently selfish — SwiftCD integrates with e-junkie, which means I would no longer have to type order information into cd-fulfillment.com’s interface.  The downsides are that the CDs would not look quite as nice, the price to me would go up from $4.50 (with shipping) to $4.99 (without), and I rather prefer cd-fulfillment.com’s ability to put customized instructions on their invoices to SwiftCD’s inability to do so (at least when going through e-junkie). 

I suppose I *could* go ahead and create a Perl script accepting information from e-junkie, then firing off an email to cd-fulfillment to get them to create and mail the CD…  But that will have to wait for another weekend when I have some time to kill…

Have some light need for graphics editing?  Download Paint.NET.  Now.  Its about as easy to use as MSPaint, with many, many more features (layers!  Full undo capability!  Competent resizing algorithms!), and its perfect for the sort of “I have an app icon but need to make it a CD logo” type chores that you’re probably spending too much time on right now.  Did I mention its totally free?  Yeah, thats a bonus, too.  (Artistic ability still not included, unfortunately.)

I finally put my money where my mouth is, by the way, and donated them $25.  I remember that I had long-ago promised to donate “in the indefinite future, when I have the money to spend” and, hey, I just had my most profitable month ever.  If you get as much use out of them as I have, consider dropping 2-3% or so of the cost of a Photoshop license in their tipjar.

Often in this space and elsewhere I’ve talked about the importance of measuring the effect of changes which you make to your website and product, and interatively changing based on the measurements. This is a critical skill. One thing that is even more critical is that you understand what the data would have looked like had you not made the change, because otherwise you could be changing for a spurious reason. As an example, I’m going to show you a real graph of my organic Google hits for 3 months:

You might conclude from this that my performance on Google is wildly erratic or that Google’s recently announced algorithm change in January has helped me greatly. Bzz, wrong answer. What is actually happening here is that you are seeing the combination of natural cycles in my market (low traffic over the Christmas break, low traffic on MLK Day and other long weekends, low traffic on every weekend) combined with a sustained massive sustained increase in overall traffic since early December. The cause of that increase is almost certainly related to me ranking higher for my core queries and getting on the first page for some very high traffic peripheral queries, such as bingo cards.

When you are making inferences based on the data for your own uISV , its easy to get caught in the trap of saying that any momentary spike is either a reflection of your own action or of some outside force (“The Google dance” is a favorite target for suspicion, as Google’s search results are capricious, poorly understood, and could potentially wreck you if you got on the wrong side of them). Resist the temptation — first, understand what the underlying pattern of your data (hits, conversions, sales, whatever) should be absent any influence from you or the suspected outside source. THEN compare what you are seeing to what you expected. For example, within the last week I changed the meta description on my index page to read more like my ad copy. I expect that this will eventually cause my click through rate in the organic search results to increase, resulting in more organic visitors. As of yet, focusing on just the last week of results, I do not have sufficient data to conclude that this change has produced a meaningful push in either direction.

I have been using Paypal and Google Checkout together for half a month now. Here are some observations:

Paypal gives you faster access to your money. Money from Paypal is spendable instantly if you have a Paypal ATM card (if you live in the US get one of these, as you get a 1% cash back from using the card, which is the easiest way to cut your effective Paypal fee). If you use an ACH transfer to your bank account, you will typically have the money credited on the third or fourth business day. I typically initiate a weekly ACH transfer every Monday morning (US time) and the money is spendable on Thursday (US time), with the payment actually clearing Friday.

Google, on the other hand, holds all transactions for two business days, then wraps them up together and sends them in a single ACH transfer to your bank account. Depending on timing issues, this can work out to be significantly slower than Paypal. For example, I had 2 purchases on the 22nd. They are still wending their way through my bank’s authorization system, although the bank has floated me the equivalent amount. In fairness, compared to the typical “We’ll pay you once a month” policy at a lot of the “real” shareware payment processors either of these policies are quite speedy.

Customer acceptance of both forms of payment is high. Google currently has a promotion going on to get people to open Google checking accounts (open an account, get $10 off a participating retailer — a pity I’m not participating! While I haven’t seen that many accounts which were signed up prior to making a purchase from me, customers in my (non-technical, B2C) niche do not seem to have much reluctance to filling out a form on Google’s site. The process is fairly painless compared to some purchasing processes I have been through. Paypal acceptance remains high, and the portion of my customers using Paypal who have a verified Paypal account has increased (I am assuming folks not having an account either prefer Google or, more likely, are agnostic and they just hit the button on the interface which is more convenient to them).

Free payment processing is nice. I have had customers from a couple of countries (including Ireland, a first for me) purchase through Google. If you’ve used Paypal before you know their rates are higher for cross-border transactions. Google is still free currently, and based on my reading of their current pricing policy it will still be free in 2008 so long as you’re spending enough on AdWords. Given that payment processing is my #2 expense every month after AdWords (#3 if you count taxes, I suppose) I’m quite happy seeing it get slashed.

Both have associated customer service headaches. For Google, you won’t see the customer’s real email address — they get a forwarding email address at Google, and can turn off delivery after completing the transaction with you (if, for example, they don’t want to get your newsletter). I don’t have a newsletter, but I do have to contact customers every once in a while, principally when they’ve done something that is about to cost them money (such as ordering Bingo Card Creator once on a CD and once without, which in my experience is generally a mistake so I always check). If they have Google set up to reject my “Pardon me, are you SURE you want to pay $55 for this program?” inquiry then I end up with customer service woes. On the other hand, many casual eBay/Paypal users have long since stopped using the mail address that they use to log into Paypal, which can result in their Registration Key being delivered into the ether.

Google Checkout interface is not great. I get the feeling it was designed by an engineer, not someone who has ever run a small business. It is difficult to ask fairly trivial questions like “How much did I sell in January?” without exporting your sales records to CSV. Exporting records to CSV doesn’t appear to actually work. Ahem, whoops? The biggest head-scratcher is that the search interface for transactions is terrible. You can’t search by customer name, you can’t search by a portion of their email address (which means you might end up typing something like, oh, Patrick-mvwerklgsgac@checkout.l.google.com to find a transaction, if your customer has chosen to get the email forwarded), and you can’t search by internally generated invoice numbers. As a result, if Bob of the obfuscated email address comes to you in a month to ask for a refund, and he doesn’t know his Google transaction number, you get to browse for it by hand. On Google, of all places.

Three things to not do the next time you release Java software on a Mac:

1. Use ./ to refer to the current directory. On Windows, this will refer to the current directory the JAR is on. On Mac, it will refer to a directory internal to the JAR. Since you can’t actually access that, it appears to default to system root. (!?) If, on the other hand, you refer to the directory as . you introduce other problems which I can’t quite recall at the moment (memo to self: “//don’t use . here, causes problems” is not a maximally useful comment).
2. Exercise caution with using javax.print.PrintServiceLookup. On a Windows machine, you are guaranteed that the default printer will be equivalent (.equals) to one of the printers returned on that list. This might lead you to write code which, for example, pre-selected the default printer from a drop-down list of printers. On a Mac, you are not guaranteed that the default printer will be equivalent to one of the printers on the available printer list. Which means, if you were careless like me and assumed that the default printer was on that list if the default printer wasn’t null, you will have your GUI thread choke and die with an index out of bounds error thrown by the list component. I’m going to recode my default printer selection logic to use least-distance string comparison to get around this little feature.
3. Fail to test code known to be good. This burned me badly. In a Java application, as opposed to a trivial Hello World program or CS assignment, you’re going to be heavily reliant on the Java libraries working as advertised. As you can see from above, sometimes they have quirks in them. Seemingly innocuous changes to one part of your code can have a ripple effect causing the libraries to break assumptions you have made in other parts of your code, resulting in potential showstoppers. Example: I changed *nothing* about the internal printing logic in 1.05, and just changed the printer used from hardcoding it as the default printer to giving users a choice of other printers as well. Swing is a known good component, the default printer is a known good component, and the printer enumeration methods are known good… but the combination of the three introduced a showstopper on the Mac.

Just when I think its safe to push out a new version I find that the Mac code has been severely compromised somehow and minor features like saving, printing, and displaying no longer work.  Gaaaaaaaaaaaaaaaaarglefraster.  To make matters worse it resulted in a customer needing a refund (annoying a day’s worth of prospects is bad enough — annoying people who pay money for software they haven’t even downloaded yet, thats like kicking yourself firmly in the teeth).  I’ve reverted the Mac version and PAD file on my website and hope to work soon, hopefully by tomorrow.  A big thanks to Andrey for the help in chasing down this problem.