Earlier this evening, I attended the CocoaHeads presentation in the San Francisco Apple Store, which was hosted by Scott Stevenson and included segments from Wil Shipley, Daniel Jalkut and Gus Mueller, as well as a Q&A session which also included Brent Simmons.

So, aside from complementing Scott and the CocoaHeads people on having organised the event, and the speakers for their interesting remarks (and especially the highly charismatic Wil Shipley), I wanted to make a few points of my own. In retrospect I wish I had talked to Scott beforehand by e-mail, because I think it might have been interesting to hear my perspective as a European indie Mac developer (I guess I must be indie, since my company only has three employees, one of them me, and most of what they were talking about seemed familiar), and also as a developer crazy enough to choose a high-support, high-maintenance (and high risk) sector like disk utility apps.

I’ll divide things up by topic, as there were a few things that I think might have been worth saying (and one thing that I did say, but that I think I can elaborate on a bit).

How I started out as an indie developer

Well I think it happened more like Brent Simmons’ description than the other guys, by which I mean that I saw what I thought was a gap in the market and resolved to plug it. I was fairly sure there would be enough money in it to support me, though like Brent I had quite a bit stashed away for a rainy day.

Because I chose something difficult to do, I found that I wasn’t able to make enough headway while working for someone else, so I decided to quit my job to develop our first application, iPartition. For what it’s worth, I don’t recommend this approach, though it seems to have worked out OK for me. I think I’d agree with what the guys being interviewed had to say about picking something simple to start with. There’s an awful lot of code in iPartition (in the current versions, a lot of that is thanks to my friend and colleague Chris Suter, but even in the original release there was a lot of complicated code) and sometimes during the year or so it took me to write the application initially, all of which was unpaid, it was a hard slog. (Worse, some of our customers see the simple UI and think that the app must be simple underneath too; we even had one guy tell us that it was implemented using Disk Utility, which just isn’t true.)

Of course, me being me, I’m probably not taking my own advice here, as what I’m doing next also consists of a number of difficult problems. But hey, I like a challenge, and when it’s finished it will be really cool.

(BTW, if you heard Daniel Jalkut’s remarks about the temptations of writing “we” and trying to seem a bit bigger than we really are, we do do that, but it’s deliberate—we think people are more likely to buy a disk utility from a company they don’t know than from an individual they don’t know. There are obviously downsides to doing this.)

How are things different in Europe?

Well, for one thing, the law is different (in fact, in typical European style, it is different in every member state in many respects). So, for instance, in the U.K., we don’t need a business licence, but we do have to worry about VAT and about the Data Protection Act, and (if you start a company, like I did) you’ll find that company law is different over here.

Some things are basically the same though. You need to keep track of your income and expenditure, you need to pay your taxes, and you need to file the right returns with the right government agencies at the right times. The consequences of not getting this right can be serious (in the worst case, you can land yourself in jail), so either take professional advice or make certain you know what you’re doing.

One big difference though is that doing this kind of (frankly crazy) thing is relatively unusual in Europe by comparison to the U.S.. So you can expect your bank manager to be a bit confused and not really to understand until you explain things carefully. Likewise, many things, the legal system included, just aren’t set up to deal with indie developers. It’s often assumed (for example) that if you’re trading overseas, you must be a huge corporation. This was always true in the past, but the Internet has really changed that and unfortunately many things have yet to catch up with this reality. I remember finding it tricky to obtain business insurance (a legal requirement in the U.K.; if you’re in the United Kingdom, you might try Icon, who I found myself after a number of very silly suggestions from our bank). Also, you’re likely to find that whilst your bank has products that sound helpful, if you ask about them you’ll discover that you’re too small for them to sell those to you, so be ready for that.

Another thing to remember is that, if you’re writing Mac applications, the United States will be your biggest market. That’s convenient for people based in the U.S., but if you aren’t, then you need to realise up front that you are going to be doing a lot of trade outside of your own country, and a lot of that will be in a different currency to the one you use, so you’re going to be exposed to currency fluctuations. There are ways to limit that exposure, for instance by billing in different currencies, but that can cause you other problems.

One other consequence of the fact that indie development is much more common in the United States, together with the tighter regulations imposed by the European Union and inconveniences such as VAT, is that you can’t really use many of the useful services offered by U.S. companies like eSellerate or Kagi. Well, you can, but it will cost you quite a bit, especially if you’re just starting out, because (for instance) they charge large fixed fees for wiring money to your accounts. I think there may be some European equivalents that will be cheaper, though when I started Coriolis Systems, the only one I knew of had just shut down because its operator was having trouble with his local VAT administration.

You will also have problems doing business through one or two U.S. companies who choose not to comply with the European Union regulations on VAT. Let me give an example by way of explanation. MacUpdate run an offer every so often where you get a discount off a particular Mac application, and to do this, they handle the payments themselves, take some off the top and then send the rest on to the developers. This is great for U.S. developers, but if you’re in the European Union, then because MacUpdate doesn’t charge VAT, you will be breaking the law if you let them sell your application. (For those that are interested, it’s the rules on “triangular trading” that you will be falling foul of; these are designed to prevent situations where you avoid paying VAT by selling to European customers via a third party outside the E.U.)

You’ll also find that employment laws are typically more onerous in E.U. member states. The U.K. isn’t too bad, as it happens, but France in particular is notorious for this kind of problem. If you’re in France, and want to go indie, you should probably consider moving to some other member state.

My guess is that the Republic of Ireland is possibly the best place to be in the E.U. right now from a tax and regulation standpoint (though to give another hint for U.K.-based people, if you start a limited company and pay yourself primarily through share dividends, you’ll find that you pay a lot less tax on your income; your accountant should explain all this to you).

Support

You need to keep track of your support. If there’s one thing that drives customers potty, it’s when they have to ask you for the fourth time if you’re actually ever going to do anything about that support query that they sent in last month.

Don’t try to do support via Mail.app. It will work for very small support loads, but guess what? As your app sells, you’ll have more and more customers, and just one bug could cause a substantial proportion of them to send you e-mail all at once. Plus, inevitably, particularly for a more complex application like the ones we write, you’re likely to have one or two customers with ongoing support issues that take time to solve.

Anyway, after a few particularly unpleasant moments where bugs in the early versions of iPartition resulted in more than one hundred support e-mails in a single day (with replies to replies coming in at a pretty steady rate, the result being that the support queue didn’t really shrink significantly for nearly three days), and one or two incidents where a support query ended up being dropped on the floor, I learned the hard way that you need a ticket system.

We use OTRS. It isn’t perfect, and in particular its handling of MIME flowed messages (which are sometimes sent by Apple Mail) sucks. I’ve been meaning to do something about that for a while now, but I haven’t been able to find the time.

Make sure your support system sends replies to people to let them know that you’ve received their e-mails. That will greatly cut down on the number of “did you get this” questions, and also gives you an excellent opportunity to point your customers at an FAQ or similar resources while still allowing you to know that they needed help.

Oh yes, and in case you’re wondering, I don’t recommend that you choose a disk utility for your application. Put another way, even if you have no bugs at all, disk utility software is going to create all sorts of headaches for you, especially in terms of the amount of support required.

Distribution

My take on this is pretty simple. The number of people with fast ’Net access is growing rapidly, particularly in the main markets for Mac applications. Distributors (and “resellers”, if you let them) will rapidly eat into the amount of money that you get paid when someone buys your application, and often there is no real advantage to be had from using them. Generally I think it’s best to offer downloads and sell direct to customers.

As I said at the CocoaHeads session, and as Wil Shipley mentioned in response, they can be useful in some situations, particularly if they are providing a whole range of services rather than just boxing and distributing your app. The company we use in Japan, NetJapan, do localisation, testing, Japanese support (including technical support), advertising (Japanese customers may have seen our ads on the covers of various Mac magazines in Japan), boxing, shipping, dealing with retailers, etcetera. Of course, they don’t do this for free, but without them we probably wouldn’t be able to address the Japanese market and, as Wil said about Act2, we don’t really have to do that much in order to get a monthly payment from them.

One interesting problem that we have with our apps is that because we need to let customers have some sort of bootable CD, our web server is a fairly high-traffic business for such a small operation. I don’t have the exact figures to hand, but we burn through getting on for half a terabyte(!) of bandwidth a month at the moment, and that grows over time. Yes, you did read that right, I really did say half a terabyte.

It also spikes somewhat alarmingly when we do a major release (indeed, the first time this happened, our ISP actually contacted us to let us know that something unusual seemed to be going on with our server :-)).

Obviously if you’re burning bandwidth like we do, you’re going to need your own dedicate server. Another good reason to avoid disk utility software if you’re thinking of going indie.

Graphics

I actually do all the graphics for our products, at the moment. I think I broadly agree with the remarks of the guys this evening that this might not be the best use of my time, but on the other hand I quite enjoy doing it. It’s a relaxing change from writing software, and I don’t need to explain to someone else how I want things to look.

One thing that may well change that, however, is the new resolution independence. My talents in this area are sadly not unlimited and whilst I can do a decent enough job of most things given enough time, the new 512x512 sized icons are pretty hard. 128x128 was difficult enough, but with sixteen times the number of pixels, it takes a lot of detail to really look good. I doubt I could do as good a job as whoever drew the icon for Panic’s latest app, Coda.

Similarly, I noticed recently that some of the other Mac developers’ sites look really good now. Ours is currently a bit dated (though we’re working on a replacement, which will make it easier to change the appearance, amongst other things) and I think maybe the time is approaching where we need to talk to some professional graphic designers to really get it looking and feeling good. Recommendations would be appreciated, if anyone knows anyone :-)