On Founding a Software House

By Keith Blount

scrivener-blog.jpgFolk wisdom has it that everyone has a novel in them, and I sometimes wonder if the same isn't also true of software ideas. As a result of the About page on our site explaining that I taught myself how to code in order to create Scrivener, I frequently receive e-mails from users who have their own ideas for software, and who want to know more about what is involved in going from knowing very little about creating software to running a small software house. It comes up often enough that I've been meaning to write something about it on my own blog for a couple of years now, but in the hope that it might be of some general interest, here goes: a very broad overview of how a software idea can become a business. I hasten to add that this is entirely based on my own experience of setting up Literature & Latte, and we are hardly Adobe or Apple -- I'm sure there are many Atlantic readers who are more experienced and may shake their heads in despair at the way we've stumbled into being a software company; I share it only in the hope that it is of some passing interest to anyone who would like to know a little more about how software can transition from concept to computer.


Before pencil is put to paper or fingertips to keyboard, the most crucial element of software design is the initial idea. It might be something that has never been done before (assuming that, unlike plots, all the basic ideas haven't already been taken); it might be a way of combining several aspects of different programs into a more integrated user experience; or it might just be an idea for a very simple utility that will save you time, or a refinement to an existing type of software. The idea may arise from a frustrating series of tasks that you find yourself doing frequently, at which you suddenly slap your forehead and think to yourself, "There must be a (better) software solution to this," only to find that there isn't.

Whatever the idea is, I think you have to be passionate about it; it has to be something that you feel is missing from your own daily workflow, or at least from the workflow of something or someone you care about. Perhaps "passionate" seems an odd choice of adjective in discussing software, but I do think that for a DIY software house, the software you're working on has to be first and foremost its own reward. While Adobe, Apple and Microsoft pull in millions of dollars from their various software suites, they are the exception: an independent software house peddling a single application, or even several applications, is unlikely to make you obscenely rich.

That said, many of the big name software applications started life with someone pursuing their own interests, too. Photoshop is a good case in point: the first version was coded and designed by a single developer, Thomas Knoll, a Ph.D. student at the time who was urged on by his brother to turn it into something more commercial. Both had inherited an enthusiasm for computers and photo manipulation from their father, who kept a darkroom in the family basement, and their interests coalesced into a piece of software that is now so ubiquitous as to have been "verbed." (So we can all dream.)


Unsurprisingly, this is the hard part, and is what stops most good ideas from becoming good software. Regardless of whether or not you will code it yourself, you need to come up with a comprehensive design plan by thinking out every aspect of the interface. For Scrivener 1.0 I started with a long design document that included scanned-in, hand-drawn designs for each screen and interface element, a list of all menu and preference items, and a basic description of how the various aspects of the interface would work together. The document also included notes to myself on the different code components I thought I'd need, and on workflows and potential problems that had to be taken into consideration. (There was an even earlier version of the design document that I wrote before I had considered teaching myself to code -- an initial map of my ideal writing software when it was just a pipe dream.)

The design process involves not only working out the interface that will best facilitate the tasks you have in mind, but also trying to consider every possible combination of actions that could be made with that interface, because if you don't think about this your users will undoubtedly try things you had never anticipated and wonder why your program doesn't work as they expect. And if something is wrong at the design stage, it's not always the sort of thing you can fix with a simple patch later down the line. Studying other applications that are best-in-class is edifying here (assuming you aren't copying their core functionality of course): although Scrivener is a writing program, elements of its interface have been improved by my encounters with an e-Bay auction management program, file synchronization software, photo management software and much more. For every feature you consider incorporating there is a pay-off to consider, which often involves trying to balance sacrifices in simplicity against improvements in utility. (An adjunct to this is that you will never get this right for everyone and so have to rely mainly on your own vision: for every user that wants a feature expanded, there will be another who already finds it too complicated.)

Almost every single button, icon and menu item in Scrivener 2.0 was discussed laboriously in-house, and even so I am still making refinements in point updates in response to real-world use by our (ever-brilliant and perceptive) customers: no matter how much thought you put in, in practice refinements are always necessary.

As for the coding ... well, you either hire someone, which could cost you a small fortune, try to find someone excited enough about your idea that they are prepared to spend months or years of their lives coding in return for a commission at the end of it (which could prove difficult, although iPhone developer Ben Dodson has a good article on this approach here) or you have a go at coding it yourself. You don't have to be a computer science major to take the latter approach (although it undoubtedly helps) -- a good number of programmers have started with little or no programming experience and learned from books. Many Mac programmers, for instance (myself included), have learned their trade from two superb and complementary texts: Programming in Objective-C by Stephen Kochan and Cocoa Programming for Mac OS X by Aaron Hillegass. You can work through both in spare time after work in about three months, and from there start programming.

Most people will tell you that once you've learned the basics, you should move on to small programming projects to build your skills. It's sound advice, but I don't necessarily agree: starting in on the project you are passionate about is a great way to learn in itself -- just be prepared to start over a little down the line, when you've learned more (which is exactly what I did, although much of the code I'd created as I learned was reusable, and I also knew what areas of the interface needed reworking so the year was not wasted in the least). Kochan's book is equally useful if you want to develop for the iPhone or iPad. (I apologize for my Mac-centricity -- before I moved to a Mac I did try to learn programming on Windows but had less luck finding programming books that I could comprehend beyond a chapter.)


Once a program is in some sort of rough shape, before it is anywhere near ready for general release, you have to find a large group of people who are willing to test it -- to use it on a daily basis and put up with quirks, bugs and crashes. As much as you care about your program as its designer or developer, there are always certain minor details that you either miss or have no strong feelings about. This is why software improves vastly once it's in use by real people providing thoughtful feedback, just as a text is improved by a copy-editor or proofreader astute enough to catch mistakes, typos and non-sequiturs missed by a writer too close to the work. Oh, and no matter how thoroughly you think you've tested it yourself, you can guarantee that the first thing you will hear whenever you release a piece of software for testing is, "It crashed."

Asking for beta-testers in a hobbyist forum dedicated to the field related to your software is a great way of finding first users, as long as you don't come across as though you're trying to sell anything (which is usually bad "netiquette") and make it clear that there will be free copies for those that help you track down bugs. We found our first users by making a free beta of Scrivener available on a forum for writers (nanowrimo.org, the website for National Novel Writing Month), and when Scrivener was finally released for sale, I gave away around 100 free copies to the users who had provided the most useful feedback.

One of the many great (and, for me, unexpected) things about the Internet is that if your users like your program, they act as a sort of sales force -- they blog about your software, recommend it to friends, mention it on forums and, if you're lucky, this creates a snowball effect. So those first users not only provide you with invaluable feedback but can also end up spreading the word about your software long before you have an advertising budget. (Thank you to all those users, by the way!)


Gone are the days when you needed to find a distributor and worry about getting into stores. Now that most computer users are accustomed to downloading files, to sell software all you need is a website and a web store. Websites and domains cost very little these days (especially using providers such as Dreamhost), so the most difficult part is making the site look professional, especially if you're not a web designer. I used to hand-code all of our web pages using a very basic grasp of HTML that I had picked up from the tutorials at HTMLGoodies (an excellent resource) -- fortunately these days we have a talented web designer working for us (who doubles as a support guru and manual writer).

Web stores are fairly trivial to set up using a third-party service. We use eSellerate, but Kagi is another popular option among small software houses (if you've ever bought software from independent companies, the chances are that at some point you have used a web store run by eSellerate or Kagi). These services not only provide a virtual store front and handle all credit card payments (and so deal with concomitant concerns such as fraud and refunds), but also provide serial number schemes for protection against piracy. The main thing is to ensure that the web store provider -- essentially your reseller -- handles the payment of sales tax in all countries into which you sell, because unless you happen to be an accountant, you don't want to deal with that yourself (which is why you shouldn't try to do it on your own via PayPal). On the Mac, the Mac App Store now provides an exciting sales channel (although for the privilege of appearing in a store that appears on every Mac desktop, Apple takes 30% as opposed to the 6-9% taken by eSellerate -- but you can sell through both), and if you are writing an iPad or iPhone app then where and how you sell isn't even an option, the App Store being the only channel. (It is worth noting here that Apple does not take responsibility for paying sales taxes in all countries into which your application can be sold -- there are 61 countries, including Norway, New Zealand, Japan, Korea, Russia and India -- for which Apple leaves paying sales taxes entirely to the developer.)

A note on piracy: In Slaughterhouse 5, Kurt Vonnegut had a character say that you may as well write an anti-glacier book as an anti-war book, and so it is with piracy: It's as easy to stop as glaciers. There's a lot of debate out there on how to deal with piracy, but the general consensus it that you should do just enough to dissuade casual pirates without going so far as to annoy genuine customers. I think Wil Shipley, founder of the OmniGroup and creator of Delicious Library, said it best:

Don't spend any time fighting piracy. If people want to steal your app, they're going to steal your app. You just put in the most basic thing so that honest people go, "Oh, that's right, I have to pay." That's all that you want to do -- you want to make it so that they have to cross over that line consciously to pirating; they have to go to that site and look up the code.

(All independent software developers should go watch the video of Wil Shipley on Viddler talking about how to get your software out there more -- it's stuffed chock-full of great advice.)


There's lots more, of course -- advertising (we do very little -- print advertising has usually resulted in a loss and can't compete with word-of-mouth; whether that will change when we have a Windows version I don't know), updates, finding people to work with you as you expand (our support guru started as an enthusiastic user who I met through our user forums), and so on - but I've gone on too long as it is. Here are a few of the general resources we find invaluable in running L&L on a day-to-day basis, though:

Dropbox: Dropbox allows you to share files between computers and between users, and many of our company files are stored in a shared Dropbox folder so that all team members have access to them no matter where they are in the world.

Google Alerts: Google Alerts can e-mail you links to all mentions of particular keywords on Google every day - incredibly useful if you want to know what people on the web are saying about your software. It also means that if there's a user out there who is having a problem and hasn't thought to use your support channels, you know about it and can provide proactive support by contacting them with a solution.

Twitter, Facebook: Having company profiles on Twitter and Facebook provides a great way of keeping in touch with customers who don't sign up to the user forum, and Twitter and its culture of "re-tweeting" is an especially powerful tool for creating buzz, spreading news and reaching users who might otherwise never have heard of you.

XKCD: Okay, this won't directly help in running a software house -- but it does put me in a good mood for answering tech support queries every Monday, Wednesday, and Friday morning.

Keith Blount is the designer and lead developer of Scrivener writing software.